Mailman 3 September 2022 - Python-ideas

PEP 671 (late-bound arg defaults), next round of discussion!
by Chris Angelico July 23, 2023

July 23, 2023

I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ with some additional information about the reference implementation, and some clarifications elsewhere. *PEP 671: Syntax for late-bound function argument defaults* Questions, for you all: 1) If this feature existed in Python 3.11 exactly as described, would you use it? 2) Independently: Is the syntactic distinction between "=" and "=>" a cognitive burden? (It's absolutely valid to say "yes" and "yes", and feel free to say which of those pulls is the stronger one.) 3) If "yes" to question 1, would you use it for any/all of (a) mutable defaults, (b) referencing things that might have changed, (c) referencing other arguments, (d) something else? 4) If "no" to question 1, is there some other spelling or other small change that WOULD mean you would use it? (Some examples in the PEP.) 5) Do you know how to compile CPython from source, and would you be willing to try this out? Please? :) I'd love to hear, also, from anyone's friends/family who know a bit of Python but haven't been involved in this discussion. If late-bound defaults "just make sense" to people, that would be highly informative. Any and all comments welcomed. I mean, this is python-ideas after all... bikeshedding is what we do best! The reference implementation currently has some test failures, which I'm looking into. I'm probably going to make this my personal default Python interpreter for a while, to see how things go. ChrisA

43 364

zip(x, y, z, strict=True)
by Ram Rachum Dec. 1, 2022

Dec. 1, 2022

Here's something that would have saved me some debugging yesterday: >>> zipped = zip(x, y, z, strict=True) I suggest that `strict=True` would ensure that all the iterables have been exhausted, raising an exception otherwise. This is useful in cases where you're assuming that the iterables all have the same lengths. When your assumption is wrong, you currently just get a shorter result, and it could take you a while to figure out why it's happening. What do you think?

27 179

Variadic patterns
by Matt del Valle Sept. 19, 2022

Sept. 19, 2022

I couldn't find any information on whether this was considered and rejected during the pattern matching PEP, so apologies if this is already settled. I've just encountered this use-case repeatedly so I figured it was time to make a thread on this. Basically, I'd like to be able to designate a pattern like this: match val: case [*str()]: ... Where 'val' will match an iterable containing zero or more strings. This should also work with more complex sub-patterns, like: match humans: case [ *{ 'name': str(), 'age': int(), } ]: ... Where 'humans' should match an iterable of zero or more mappings where each mapping contains the keys 'name' and 'age' (and where the value for name is a string and the value for age is an int). Sure, you can use the sentinel clause to do it, but imagine you've got a case statement where you're using 10 different variadic sub-patterns. You'd have an unbearably long string of: case {PATTERN_GOES_HERE} if ( all(isinstance(val1, some_type1) for val1 in sub_pattern1) and all(isinstance(val2, some_type2) for val2 in sub_pattern2) and ... ) And that's assuming simple variadics like my first example above, and not my second example! This incidentally destroys the gain in legibility of using a pattern in the first place. Is anyone aware of a reason variadic patterns weren't included in the PEP? Was it an oversight, or was it deemed too niche to include in the original spec? Or were there implementation-related reasons? Something else? It just seems like it would make match statements way more powerful for data shape validation, which is one of the primary use-cases that the tutorial PEP showed off. Cheers

4 6

Re: Feedback before submission of PEP 661: Sentinel Values
by Laurent Lyaudet Sept. 11, 2022

Sept. 11, 2022

Hello, Thanks for this nice PEP, I have just read it. I think it is a good thing to add to Python and will enable cleaner code. I support the idea to have common sentinels suggested by Christopher Barker. For example, a common confusion is to identify None with NULL in DB, but then when you are filtering rows in a SQL query generated by a framework function, you have to do convoluted things because most frameworks do not distinguish "Do not filter" and "Keep only rows where value is NULL", because the vocabulary of sentinels is too limited. Some sentinels could be created also for some constants of R language for example. Anyway, extending the language with common sentinels can be done later. But it would be nice to really think about it. Regarding the type of Sentinels, the proposition in the PEP is not perfect. Recently, I used MY_SENTINEL = object() TypeMySentinel = Literal(MY_SENTINEL) in my code. But what I would have like to be able to do is just : TypeMySentinel = MY_SENTINEL exactly like None "is" its own type. However, it was rejected on import of the corresponding file, when using it in function signature. It would be really nice if all sentinel values could have this feature to be their own type. Last, I spotted a typo in the PEP : "Most common exiting idioms" -> "existing' Thanks, best regards, Laurent Lyaudet, PhD

4 3

Feedback before submission of PEP 661: Sentinel Values
by Tal Einat Sept. 11, 2022

Sept. 11, 2022

Hello, I've been working on this PEP [1] on and off for over a year. I think it is now nearly ready for submission to the steering council. If anyone would like to review the proposal and provide feedback, that would be most welcome! The current reference implementation, and latest version of the PEP, are in this GitHub repo [2]. References to previous discussion are found in the PEP. - Tal Einat [1] https://peps.python.org/pep-0661/ [2] https://github.com/taleinat/python-stdlib-sentinels

5 8

Add InvalidStateError to the standard exception hierarchy
by Steve Jorgensen Sept. 3, 2022

Sept. 3, 2022

I frequently find that I want to raise an exception when the target of a call is not in an appropriate state to perform the requested operation. Rather than choosing between `Exception` or defining a custom exception, it would be nice if there were a built-in `InvalidStateError` exception that my code could raise. In cases where I want to define a custom exception anyway, I think it would be nice if it could have a generic `InvalidStateError` exception class for it to inherit from. Of course, I would be open to other ideas for what the name of this exception should be. Other possibilities off the top of my head are `BadStateError` or `StateError`.

10 20