Mailman 3 December 2021 - 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

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

Bringing the print statement back
by Guido van Rossum 02 Mar '22

02 Mar '22

In Python 3.10 we will no longer be burdened by the old parser (though 3rd party tooling needs to catch up). One thing that the PEG parser makes possible in about 20 lines of code is something not entirely different from the old print statement. I have a prototype: Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun 9 2020, 16:31:17) [Clang 11.0.0 (clang-1100.0.33.8)] on darwin Type "help", "copyright", "credits" or "license" for more information. Cannot read termcap database; using dumb terminal settings. >>> print 2+2 4 >>> print "hello world" hello world >>> print "hello", input("Name:") Name:Guido hello Guido >>> print 1, 2, 3, sep=", " 1, 2, 3 >>> But wait, there's more! The same syntax will make it possible to call *any* function: >>> len "abc" 3 >>> Or any method: >>> import sys >>> sys.getrefcount "abc" 24 >>> Really, *any* method: >>> class C: ... def foo(self, arg): print arg ... >>> C().foo 2+2 4 >>> There are downsides too, though. For example, you can't call a method without arguments: >>> print <built-in function print> >>> Worse, the first argument cannot start with a parenthesis or bracket: >>> print (1, 2, 3) 1 2 3 >>> C().foo (1, 2, 3) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: C.foo() takes 2 positional arguments but 4 were given >>> print (2+2), 42 4 (None, 42) >>> C().foo [0] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'method' object is not subscriptable >>> No, it's not April 1st. I am seriously proposing this (but I'll withdraw it if the response is a resounding "boo, hiss"). After all, we currently have a bunch of complexity in the parser just to give a helpful error message to people used to Python 2's print statement: >>> print 1, 2, 3 File "<stdin>", line 1 print 1, 2, 3 ^ SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1, 2, 3)? >>> And IIRC there have been a number of aborted attempts at syntactic hacks to allow people to call functions (like print) without parentheses, although (I think) none of them made it into a PEP. The PEG parser makes this much simpler, because it can simply backtrack -- by placing the grammar rule for this syntax (tentatively called "call statement") last in the list of alternatives for "small statement" we ensure that everything that's a valid expression statement (including print() calls) is still an expression statement with exactly the same meaning, while still allowing parameter-less function calls, without lexical hacks. (There is no code in my prototype that checks for a space after 'print' -- it just checks that there's a name, number or string following a name, which is never legal syntax.) One possible extension I didn't pursue (yet -- dare me!) is to allow parameter-less calls inside other expressions. For example, my prototype does not support things like this: >>> a = (len "abc") File "<stdin>", line 1 a = (len "abc") ^ SyntaxError: invalid syntax >>> I think that strikes a reasonable balance between usability and reduced detection of common errors. I could also dial it back a bit, e.g. maybe it's too much to allow 'C().foo x' and we should only allow dotted names (sufficient to access functions in imported modules and method calls on variables). Or maybe we should only allow simple names (allowing 'len x' but disallowing 'sys.getrefcount x'. Or maybe we should really only bring back print statements. I believe there are some other languages that support a similar grammar (Ruby? R? Raku?) but I haven't investigated. Thoughts? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>

42 66

Adding a thin wrapper class around the functions in stdlib.heapq
by bunslow 18 Feb '22

18 Feb '22

Nothing so bombastic this time. The heapq functions are basically all named "heapsomething", and basically all take a "heap" for their first argument, with supplementary args coming after. It's a textbook example of the (hypothetical) Object Oriented Manifesto™ where defining a class increases type safety and programmers' conceptual clarity. There're practically no drawbacks, and the code to be added would be very simple. Updating the tests and docs would probably be harder. In pure Python, such a class would look like this: class Heap(list): def __init__(self, iterable=None): if iterable: super().__init__(iterable) else: super().__init__() self.heapify() push = heapq.heappush pop = heapq.heappop pushpop = heapq.heappushpop replace = heapq.heapreplace heapify = heapq.heapify # This could be a simple wrapper as well, but I had the following thoughts anyways, so here they are def nsmallest(self, n, key=None): # heapq.nsmallest makes a *max* heap of the first n elements, # while we know that self is already a min heap, so we can # make the max heap construction faster self[:n] = reversed(self[:n]) return heapq.nsmallest(n, self, key) # do we define nlargest on a minheap?? Wrapping around the C builtin functions (which aren't descriptors) would be a bit harder, but not much so: from functools import partial class Heap(list): def __init__(self, iterable=None): if iterable: super().__init__(iterable) else: super().__init__() self.heapify = partial(heapq.heapify, self) self.push = partial(heapq.heappush, self) ... self.heapify() Thoughts?

17 32

Allow syntax "func(arg=x if condition)"
by Peter O'Connor 19 Jan '22

19 Jan '22

I often find that python lacks a nice way to say "only pass an argument under this condition". (See previous python-list email in "Idea: Deferred Default Arguments?") Example 1: Defining a list with conditional elements include_bd = True current_way = ['a'] + (['b'] if include_bd else [])+['c']+(['d'] if include_bd else []) new_way = ['a', 'b' if include_bd, 'c', 'd' if include_bd] also_new_way = list('a', 'b' if include_bd, 'c', 'd' if include_bd) Example 2: Deferring to defaults of called functions def is_close(a, b, precicion=1e-9): return abs(a-b) < precision def approach(pose, target, step=0.1, precision=None): # Defers to default precision if not otherwise specified: velocity = step*(target-pose) \ if not is_close(pose, target, precision if precision is not None) \ else 0 return velocity Not sure if this has been discussed, but I cannot see any clear downside to adding this, and it has some clear benefits (duplicated default arguments and **kwargs are the scourge of many real world code-bases)

6 9

Add a decorators called @staticproperty
by me＠chenjt.com 06 Jan '22

06 Jan '22

In the following situations: class Data(object): @staticmethod @property def imagesTotal(): return 10 print(Data.imagesTotal) The "print(Data.imagesTotal)" can't print "10", it print "<property object at 0x...>". It might be a good idea to use "@staticproperty" to solve this problem. "@staticproperty" is a decorators, it mix the @staticmethod and @property. Then the static property has getter and setter.

9 12

Enhancing iterator objects with map, filter, reduce methods
by Remy 30 Dec '21

30 Dec '21

Hi, I'd like to revive this thread after what seemed like a decade and see where this might take us 😃 I like this idea that the OP suggested but I'd like to extend this to all iterator objects (range_iterators, list_iterators etc.). 📌Idea Iterables to expose the .__iter__() method in iterable as .iter(). Iterators to implement 'transformational' functions like map, filter, flat_map, 'reductional' functions like reduce, sum, join, and 'evaluate' functions like to_list and to_set. ( [1,2,3].iter() .map(lambda x: x+1) .filter(lambda x: x % 2 == 0) .to_list() ) 📌Why? 1. It is readable in a manner that is procedural and dataflow centric. At one glance, it is easy to reason about how our data gets transformed - we start with the subject, our data, then we perform a sequence of transformations. The previous way of doing this: list( filter( lambda x: x%2==0, map( lambda x: x+1, iter([1,2,3])))) incurs a lot of cognitive overload. We could separate them into different lines: it = iter([1,2,3]) it = map(lambda x: x+1, it) it = filter(lambda x: x%2==0, it) list(it) but I would argue that there is a lot of repetition. 2. There are existing communities which deal with frameworks that focus on data transformations. This includes PySpark and pandas. 3. It is conventional - many modern languages like Rust, Scala, JavaScript and Kotlin have a similar API like this. 4. The existing map, filter APIs are not so commonly used (this is the impression I have). Apparently list comprehension appears more pythonic on StackOverflow posts. This extended iterator API could possibly 'revive' the use of lazy evaluation. 5. This API is 'flat', rather than the 'nested' map, reduce and filter. (I guess we can argue that "Flat is better than nested"?) 📌Why not? 1. Method chaining is uncommon and not really well-liked. I have this impression a lot among the community. Could somebody please explain why? 2. A lot of 'lambda' keywords. Agreed. (However, this would tie in well with the alternate lambda syntax proposal https://mail.python.org/archives/list/python-ideas@python.org/thread/QQUS35… .) 📌On list comprehension vs. method chaining I don't think the aim of this API should be to replace list comprehension and the like. Rather it offers programmers an alternative pattern to transform and reason about their data.

15 94

Add a `count` argument to `list.remove`
by Jeremiah Vivian 26 Dec '21

26 Dec '21

I expect some sort of "there's no benefit in this, just write the current implementation", indirectly or directly. Currently, this is the way to remove `num` occurrences of an element from a list: > idx = 0 > while idx < len(the_list) and num: > if the_list[idx] == element_to_remove: > del the_list[idx] > num -= 1 > else: > idx += 1 With a `count` argument to `list.remove`, this is how it would be done: > the_list.remove(element_to_remove, count=num) (Doesn't necessarily have to be a keyword argument) Is this a good idea?

6 12

Add set.intersects method
by Stefan Pochmann 24 Dec '21

24 Dec '21

Multiple times I wished that sets had an `intersects` method. Simply the negation of the `set.isdisjoint` method. Sometimes I can write `not a.isdisjoint(b)`, but: 1) Together with the "dis", that's a double negation. Saying "a.intersects(b)" is the correct and much clearer way to express my intent. 2) I sometimes want to pass a set's bound method, for example as the first argument to `filter`, and then I can't pass that `not` along with it. The isdisjoint method is great. Takes any iterable, returns a bool, and is efficient: It doesn't turn the iterable into a set like some other `set` methods, but just iterates it and checks each element against the set (and stops early if it finds a common value). I'd like the same for `set.intersects`.

2 1