Mailman 3 May 2022 - Python-ideas

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

zip(x, y, z, strict=True)
by Ram Rachum 01 Dec '22

01 Dec '22

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

Typescript-Like Notational Shortcuts
by kevinlu1248＠gmail.com 01 Jul '22

01 Jul '22

On the theme of the addition of pip operators to indicate union, I was wondering what people think of using the following shortcuts for type hints. * type[] be a short-hand for List[type] * [type1, type2, type3] be a shorthand for Tuple[type1, type2, type3] * similar ideas for dictionaries and callables with (perhaps with javascript-like arrow notations?) I just think something like this would be easier to read. For example, a lot of functions that return tuples generally are immediately unpacked when it's used, so I think this is a more clear and concise way of stating that this is that it returns three elements: an element of type1, an element of type2 and an element of type3. In other words, the fact that it's a tuple does not matter much.

3 2

disallow assignment to unknown ssl.SSLContext attributes
by Thomas Grainger 10 Jun '22

10 Jun '22

I was debugging some code that was using TLSv1.2 when I expected it to only support TLSv1.3, I tracked it down to a call to: context.miunimum_version = ssl.TLSVersion.TLSv1_3 it should have been: context.minimum_version = ssl.TLSVersion.TLSv1_3 I'd like invalid attribute assignment to be prevented at runtime

13 32

Expand the try-expect syntax to support conditional expect block
by Nadav Misgav 04 Jun '22

04 Jun '22

Hello, I was thinking of a way to expand the current try-expect block to support condinitial expect block. I was imagining the new syntax as try: expression block expect Exception if condition expression block where the expect expression block would only run if the condition is met else it would raise the exception, for example the following code try: config = get_config() except Exception: if use_default: config = default else: raise would be converted to try: config = get_config() except Exception if use_default: config = default I find it very useful and also I found the same pattern in the following packages that were installed on my system. more_itertools/more.py:227 cloudinit/net/__init__.py:364 matplotlib/__init__.py:330 google/protobuf/internal/containers.py:126 networkx/algorithms/connectivity/edge_augmentation.py:296 twisted/internet/pollreactor.py:160 pyqtgraph/opengl/shaders.py:257 setuptools/_vendor/pyparsing.py:2191 setuptools/sandbox.py:253 pip/_internal/utils/misc.py:115 urllib3/poolmanager.py:362 mako/util.py:65 serial/serialposix.py:294 PIL/PngImagePlugin.py:335 click/core.py:1472 numpy/core/memmap.py:216 pyparsing.py:2067 Looking forward to hear some feedback, Regards

8 11

Opt-in “iter def” and/or “gen def” syntax for generator functions
by armload_lakes0c＠icloud.com 01 Jun '22

01 Jun '22

After getting used to writing async functions, I’ve been wanting use a similar syntax to declare generator functions. Something along the lines of `iter def my_iterator() -> T` and/or `gen def my_generator() -> (T, U, V)` Obviously, for backwards compatibility, this would need to be optional or have an opt-in mechanism. Would a feature like this be at all within the realm of possibility? I’d be happy to write up a much longer discussion if so. (I found a short discussion of such a feature in the archives about 8 years ago[1]. But, since it predates both `async def` and the current type checker regime, I thought it might be worth discussing. Apologies if I missed any more recent discussions.) Thanks, Aaron [1] https://mail.python.org/archives/list/python-ideas@python.org/thread/OVIHVR…

6 9

Python array multiplication for negative values should throw an error
by fjwillemsen＠icloud.com 01 Jun '22

01 Jun '22

Hopefully this is not a duplicate of an existing thread or in the wrong section, first time posting here. In Python, array multiplication is quite useful to repeat an existing array, e.g. [1,2,3] * 2 becomes [1,2,3,4,5,6]. Multiplication by 0 yields an empty array: [1,2,3] * 0 becomes []. However, operations such as [numpy array] * -1 are very common to get the inverse of an array of numbers. The confusion here stems from the lack of type checking: while the programmer should check whether the array is a NumPy array or a Python array, this is not always done, giving rise to difficult to trace cases where [1,2,3] * -1 yields [] instead of [-1,-2,-3]. I can not think of good reasons why Python array multiplication should not throw an error for negative multipliers, because it is meaningless to have array multiplication by negative value in the way it is intended in Python. Instead I would propose that array multiplication by negative value throws an error. I would like to hear your opinions on this matter.

7 8

Awaiting until a condition is met
by Aaron Fink 30 May '22

30 May '22

Hello. I've been thinking it would be nice to be able to use await to suspend execution until a condition is met (as represented by a function or lambda which returns a boolean. Currently, as far as I can tell, the way to accomplish this is with a while loop which frequently checks the condition, suspending execution in between checks. My use case is in robotics, so I'll use that. Here's a minimal version of my current approach. start_moving_to(dest) while distance_to(dest) > tolerance: await asyncio.sleep(1 / 60) This requires choosing a somewhat arbitrary frequency with which to check the condition. But if the frequency is too high, the function may not be suspended often enough for other tasks to run and if it's too low, there's a significant delay before the condition's satisfaction can be noticed. So here's my proposal for syntax that I think is quite a bit cleaner: start_moving_to(dest) await lambda: distance_to(dest) <= tolerance This eliminates the need to choose a frequency and makes the code even more readable. Of course, a previously-defined function could be used in place of a lambda, which would allow for the even cleaner expression await has_arrived if has_arrived is already defined. While I only have a basic understanding of how the event loop works, it seems to me it should be fairly straightforward to add a list of that pairs conditions with callbacks and check those conditions on each pass through the list of registered callbacks, fairly similarly to how scheduled callbacks created with asyncio.sleep wait until enough time has passed. Looking forward to hearing people's thoughts.

6 6

Enhance flexibility of dataclass repr
by Steve Jorgensen 30 May '22

30 May '22

The desire for this came up for me in relation to a set of dataclasses used to define a tree structure where each item has a reference to its parent. Including the complete expansion of the parent (with its children and its parent with its children, etc.) is WAY too much information, but at the same time, I do want to at least identify the parent. Currently, the only way to get what I'm looking for is to write a custom `__repr__` from scratch. It would be great if there was at least 1 way to take advantage of the automatic repr and still customize its handling for specific fields. The first thing I thought of in that regard for my example was to add a `parent_name` property using `@property` and specify `repr=False` for `parent. The auto-generated repr is not aware of properties defined that way though. Maybe that could be solved by adding an argument named something like `descriptor=<True|False>` to `field()` where a `True` value means that getting and setting happens through a separately defined descriptor (e.g. via`@property`) and should not be implemented automatically, even though it should be otherwise treated as a dataclass property. The second thought I had is to be able to customize `repr` for any field. One way to do that might be to allow `field()`'s `repr` argument to accept a method name string and/or a callable that accepts an instance of the class in addition to accepting `True` or `False`. I actually like the idea of having both of those capabilities. Opinions?

1 1

Provide an asynchronus equivalent to itertools.chain, and possibly more of itertools
by rammers2＠hotmail.co.uk 28 May '22

28 May '22

I recently started to dive into asynchronous programming in Python. My program iterates over text from posts on a website and analyses it. I wanted to add the ability to asynchronously apply the same analysis to posts from multiple websites. It seemed likely to me that this would be something people commonly want to do, but I was surprised to find no built-in solution. There are a few relevant stack overflow posts: https://stackoverflow.com/questions/55299564/join-multiple-async-generators… In which people suggest either using the library aiostream: https://aiostream.readthedocs.io/en/latest/operators.html#aiostream.stream.… Or use an implementation based on `asyncio.Queue`. It seems to me that the aiostream solution goes beyond what I imagine most people would want to do. The solution using `asyncio.Queue` I think is fine, but is tricky to understand and a bit ugly to have to implement as a helper in every project looking to do this sort of thing. I propose there should be an asynchronous version of `itertools.chain` e.g. called `achain` which would allow users to write something like: ``` async for item in achain(async_gen1(), async_gen2(), async_gen3()): process(item) ``` I think it's very clear what this expression is doing and I can't imagine it's just me who'd find it useful. I have made an effort to implement at prototype version here: https://github.com/0Hughman0/achain/tree/no_context It works for the most basic case, but I imagine there's lots of nitty gritty regarding error handling etc. that I won't have done right. I'd love to hear others thoughts. Particularly whether you think this would be good to add to the standard library. It seems natural to me to try and make asynchronous compatible version of lots of the Python generators, e.g. `enumerate` and others from `itertools`. Many thanks, Hugh

1 0