Mailman 3 August 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

Add __name__ to functools.partial object
by Charles Machalow 31 Aug '22

31 Aug '22

Hey folks, I propose adding __name__ to functools.partial. >>> get_name = functools.partial(input, "name: ") >>> get_name() name: hi 'hi' >>> get_name.__name__ Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'functools.partial' object has no attribute '__name__' >>> get_name.func <built-in function input> >>> get_name.func.__name__ 'input' We could set __name__ based off of partial.func.__name__ or we could try to set it to something like 'partial calling func.__name__' If the callable doesn't have a name, we could fall back to a None __name__ or set it to something generic. Even lambdas have __name__ set: >>> l = lambda: input('name: ') >>> l.__name__ '<lambda>' This proposal makes __name__ on partial objects more useful than the current behavior of __name__ on lambda objects as well. We could port over similar functionality to lambda if we'd like. - Charlie Scott Machalow

5 11

PEP Idea: native f-string support as a match pattern
by Tushar Sadhwani 23 Aug '22

23 Aug '22

Since Python has built-in syntax for interpolated strings, I believe it's a good area to idea to extend it to pattern matching, like so: def unquote(string: str) -> str: match string: case f'"{value}"': return value case f"'{value}'": return value case _: return string Doing this with current match syntax is not as easy. I have other reasons to consider this idea as well, but before I try to pursue this, I'd like to know if something like this was already discussed when the proposal was being made?

4 5

Re: A standard library Multiset implementation?
by Raymond Hettinger 21 Aug '22

21 Aug '22

> I am often driven to use, for example, itertools set(permutations(multiset, n)) Try the more-itertools package: https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.dis… from more_itertools import distinct_permutations from collections import Counter c = Counter('abracadabra’) print(list(distinct_permutations(c.elements(), 3))) > there is little if any solid evidence that they do what they claim to do ( The code in more-itertools is trustworthy. Also the docs have links to the source, so you can just read the code and let it earn your trust. Raymond

4 5

Expose `_make_key` in `functools.lru_cache` to caller
by Alec Mori 19 Aug '22

19 Aug '22

Previous Thread on Similar Topic: https://mail.python.org/archives/list/python-ideas@python.org/thread/4XXGPX… Relevant Code: https://github.com/python/cpython/blob/f9433ff/Lib/functools.py#L528 I have been beset by two different scenarios where having some option to modify the input of the `lru_cache` key would be useful. These are simplified versions of said scenarios, but emphasize why I might want this capability. 1. Scoring model on repeated input. def score(model, feature_vector_that_includes_example_id): ... This would be easily memorizable with a key of (model.__hash__(), feature_vector[ID_INDEX]). 2. Multiple user-friendly wrappers around the same complex internal function def _foo(obj, transform_fn): # Some non-trivial logic new_obj = transform_fn(obj) # Some non-trivial logic return new_obj def foo_1(obj): def _transform_1(obj): ... return foo(obj, _transform_1) def foo_2(obj): def _transform_2(obj): ... return foo(obj, _transform_2) For this subset of functions, I know I can safely use (obj, fn.__name__) as a key. This, alongside the "Previous Thread" (wanting to use a subset of arguments for the key) and the comment in the `_make_key` function (https://github.com/python/cpython/blob/f9433ff/Lib/functools.py#L464), indicate that there are other scenarios in which users might want to customize the `_make_key` function. The main drawbacks I see are 1. Very prone to error (see conversation in "Previous Thread") 2. For sufficiently complex `_make_key` functions, the benefit may be obscured by the cost. For instance, casting a `list` to a `tuple` would incur an O(n) cost, which many users may not recognize. I would love to get community feedback before pursuing this idea further.

1 0

A standard library Multiset implementation?
by Brian Gladman 12 Aug '22

12 Aug '22

One of the nice features of capabilities provided in the standard library is a set of data types together with a set of algorithms that that work consistently with them. For example, we have sequence types that can be used with the itertools module where combinations, combinations_with_replacement, permutations and product are all available. Being a part of the standard library, these facilities are implemented consistently and their widespread use means that we can have great deal of confidence in their efficiency, effectiveness, reliability and correctness. In short, we can trust them. Maybe I am on my own here but I make a lot of use of multisets and find that this data type is not well catered for in the Python universe. There is the counter class in the standard library but it is not a full multiset implementation; there is also a full implementation on PyPy but there are no 'itertools equivalent' algorithms that are designed to work with it. As a result, I am often driven to use, for example, itertools set(permutations(multiset, n)) which is typically very inefficient when compared with a properly implemented multiset permutation algorithm. And, although there are implementations of various multiset 'itertools algorithms' around, these are 'one-off' pieces of code put together by 'people who needed them' and in which there is little if any solid evidence that they do what they claim to do (some I have tried certainly don't!). So my plea is for a multiset implementation in the Python standard library (combined witn its itertools equivalent combinatorial algorithms). Being a part of the standard library will bring implementation consistency and widespread use over time will bring us reliability, efficiency, effectiveness and trustworthiness. Brian Gladman

2 1

range() manipulations
by arvindsistla＠gmail.com 03 Aug '22

03 Aug '22

Hello everyone. First time here, so please be forgiving of any missteps on my part. This is an idea I have thought about for a while, and I believe it could be quite useful. Would it be possible to enhance the standard range() type to allow for elementary operations on ranges? For example : range(10) - range(5) => range(5, 10) range(3, 5, 2) + range(3, 6, 2) => range(3, 6, 2) I believe this could be a fair first step into allowing for a whole range of mathematical operations in abstract algebra.

6 7