Mailman 3 June 2023 - Python-ideas

len(Enum) should raise TypeError
by Richard Hajek 14 Aug '23

14 Aug '23

# Feature or enhancement `len(Enum)` has no useful meaning and should therefore raise the appropriate error # Pitch I cannot figure out any scenario, in which len(Enum) should not raise. Enum is a type and as any other types, such as `len(list)` or `len(dict)`, and should not give any meaningful result on len. Thoughts?

9 15

else without except
by Daniel Walker 07 Aug '23

07 Aug '23

As most of you probably know, you can use else with try blocks: try: do_stuff() except SomeExceptionClass: handle_error() else: no_error_occurred() Here, no_error_occurred will only be called if do_stuff() didn't raise an exception. However, the following is invalid syntax: try: do_stuff() else: no_error_occurred() Now you might say that this isn't needed as you can achieve the same result with do_stuff() no_error_occurred() However, what if I want to use finally as well: try: do_stuff() else: no_error_occurred() finally: cleanup() and I need no_error_occurred to be called before cleanup? For my actual use case, I've done try: do_stuff() except Exception: raise else: no_error_occurred() finally: cleanup() This seems very non-Pythonic. Is there a reason why else without except has to be invalid syntax?

6 13

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

23 Jul '23

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

dict method to retrieve a key from a value
by Andre Delfino 04 Jul '23

04 Jul '23

A dict method to retrieve the key of a value from a bijective dict would have come in handy to me in several occasions: >>> names = {'one': 1} >>> names.inverse()[1] 'one' >>> names = {'one': 1, 'uno': 1} >>> names.inverse()[1] ValueError: dict is not bijective My usual use case is when both keys and values have simple types like int/str, like: { 'account-a': 123, 'account-b': 456, } Users may enter the account name, or the ID. The system works with the account ID (translating from the account name if needed), but when it needs to mention the account to the user, it shows the account name instead. I do understand that retrieval wouldn't be O(1).

8 33

Re: [dataclasses] add a NON_FIELDS sentinel after which all attributes are ignored.
by Eric V. Smith 23 Jun '23

23 Jun '23

2 2

Julia envy
by Neal Becker 23 Jun '23

23 Jun '23

One item I admire from Julia and miss in python/numpy, I often use the power of python list comprehension to process data. This data often needs to be converted to numpy for other operations, for example fancy indexing. The fact that operations using comprehensions (which produce lists) and operations on numpy arrays use different incompatible data structures requires conversions between lists and numpy arrays. Comprehensions in Julia produce arrays directly (I believe), removing the need for conversions. I don't see any easy way to improve this. Any ideas? Thanks, Neal -- *Those who don't understand recursion are doomed to repeat it*

2 2

[dataclasses] add a NON_FIELDS sentinel after which all attributes are ignored.
by Randolf Scholz 23 Jun '23

23 Jun '23

Dataclasses should provide a way to ignore a type hinted attributes, and not consider them as fields. For example, some attributes might be derived during `__post_init__` from the values of the fields or other variables. If one wants to still type hint these attributes, one has to awkward workarounds to avoid having dataclass interpret them as fields. (https://stackoverflow.com/questions/76532816) I propose `NON_FIELDS` sentinel, analogous to `KW_ONLY`. (alternative name suggestions welcome). when writing a dataclass, all attributes after this sentinel are ignored and not considered fields. ``` @dataclass class Foo: field0: int field1: int _: KW_ONLY fieldN: int _: NON_FIELDS attr0: int # @dataclass will ignore this type hint. ``` Additionally one could consider adding an `attribute` typing construct, such that `attr0: attribute[int]` would mark it as a non-field attribute.

5 4

List get/pop
by Dom Grigonis 17 Jun '23

17 Jun '23

Very simple proposal. E.g. ``` >>> l = [‘a’, ‘b’] >>> l.get(0) ‘a’ >>> l.get(2) None >>> l.pop(1, default=‘c’) ‘b’ >>> l.pop(1, default=‘c’) ‘c' ``` Essentially to match them to those of a dict. Current workarounds: ``` try: a = b[n] except IndexError: a = default # and l[index] if -len(l) <= index < len(l) else default ``` Benefits: 1. Convenience 2. Easy to remember API methods for anyone used to a dict 3. Speed improvements given it’s implemented in C 4. Time saving! It took me around 7seconds to type 2nd snippet without auto-complete. So following Chris’ logic... If there are 10,000,000 python users on Stack… And we assume, that every user encounters such need at least 2 times a year (being very speculative here, would say conservative?). Saving on typing and correcting above snippet is 5sec (conservative here?). That’s ~600 days of pure code writing time saved every year. In 100 years, which python will obviously survive - that’s ~16.5 years of pure code typing time saved worldwide!

3 4

Warn when iterating over an already exhausted generator
by BoppreH 14 Jun '23

14 Jun '23

This is my first post to this list, apologies in advance if this is the wrong place or it's a known topic that my search failed to find. As a Python user since 2.6, I make stupid mistakes with exhausted generators more often than I'd like to admit: numbers = (i for i in range(5)) assert 5 not in numbers sorted(numbers) # [] Then the empty list creates hard-to-track bugs. I'm familiar with the iterator protocol and why the behavior above happens, but couldn't it be prevented? A naive example of the behavior I wish it had: class SafeGenerator: def __init__(self, generator): self.generator = generator self.is_exhausted = False def __iter__(self): if self.is_exhausted: raise ValueError("can't iterate over an already exhausted generator") return self def __next__(self): try: return next(self.generator) except StopIteration: self.is_exhausted = True raise safe_generator = SafeGenerator(i for i in range(5)) assert 5 not in safe_generator sorted(safe_generator) # ValueError: can't iterate over an already exhausted generator Note that the error is raised on `__iter__`, not `__next__`, so idioms like `zip(generator, generator)` would still work. I can't imagine any sane code that would break under this change, but even if there is, what's the downside of at least emitting a warning when calling `__iter__` on an exhausted generator?

11 21

yield functionality to match that of await
by Dom Grigonis 13 Jun '23

13 Jun '23

I was wandering if there are any issues in making `yield` usage to be the same as that of `await` Most importantly: l.append(yield Object()) Nice to have: yield with Object(): yield for i in Object(): Also, could anyone point me in the direction, where it is explained why new await/async syntax was introduced instead of making use of already existing yield coroutine functionality?

3 5