Mailman 3 April 2021 - Python-ideas

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

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 17 Feb '22

17 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

Barrier Object in asyncio lib
by Yves Duprat 10 May '21

10 May '21

Hi,the list, I'm wondering why Barrier object does not exist in the synchronization primitives of the asyncio lib while it is present in threading and multiprocessing libs ? This may not be the right place to ask this question, but I never found an answer on the web. Thanks for your help. Yves

6 13

Changing The Theme of Python Docs Site
by Abdur-Rahmaan Janhangeer 08 May '21

08 May '21

Greetings, A proposal to change the theme of the Python docs. Great softwares are not distinguished by docs crankiness and unpleasantness. Though what's more important is the content, nevertheless it can be made more enjoyable to read. The Masonite docs for example is quite nice: https://docs.masoniteproject.com/ Kind Regards, Abdur-Rahmaan Janhangeer about <https://compileralchemy.github.io/> | blog <https://www.pythonkitchen.com> github <https://github.com/Abdur-RahmaanJ> Mauritius

12 27

String comprehension
by David Álvarez Lombardi 06 May '21

06 May '21

I propose a syntax for constructing/filtering strings analogous to the one available for all other builtin iterables. It could look something like this. >>> dirty = "f8sjGe7" >>> clean = c"char for char in dirty if char in string.ascii_letters" >>> clean 'fsjGe' Currently, the best way to do this (in the general case) seems to be the following. >>> clean = "".join(char for char in dirty if char in string.ascii_letters) But I think the proposed syntax would be superior for two main reasons. - Consistency with the comprehension style for all other iterables (which seems to be one of the most beloved features of python) - Confusion surrounding the str.join(iter) syntax is very well documented <https://stackoverflow.com/questions/493819/why-is-it-string-joinlist-instea…> and I believe it is particularly unintuitive when the string is empty I also believe the following reasons carry some weight. - Skips unnecessary type switching from str to iter and back to str - Much much MUCH more readable/intuitive Please let me know what you all think. It was mentioned (by @rhettinger) in the PBT issue <https://bugs.python.org/issue43900> that this will likely require a PEP which I would happily write if there is a positive response. -- *David Álvarez Lombardi* Machine Learning Spanish Linguist Amazon | Natural Language Understanding Boston, Massachusetts alvarezdqal <https://www.linkedin.com/in/alvarezdqal/>

16 42

Support more conversions in format string
by Serhiy Storchaka 05 May '21

05 May '21

Currently format strings (and f-string expressions) support three conversions: !s -- str, !r -- repr and !a for ascii. I propose to add support of additional conversions: for int, float and operator.index. It will help to convert automatically printf-like format strings to f-string expressions: %d, %i, %u -- use int, %f -- use float, %o, %x -- use operator.index. For float the conversion letter is obvious -- !f. But I am not sure for what !i should be used, for int or operator.index. If make it operator.index, then !d perhaps should be used for int. If make it int, then !I perhaps should be used for operator.index. Or vice verse? Also I propose to support applying multiple conversions for the same item. It is common when you output a path or URL object as quoted string with all escaping, because in general it can contain special or non-printable characters. Currently I write f"path = {repr(str(path))}" or f"path = {str(path)!r}", but want to write f"path = {path!s!r}". Do we need support of more standard conversions? Do we want to support custom conversions (registered globally as encodings and error handlers). re.escape, html.escape and shlex.quote could be very useful in some applications.

8 20

TACE16 text encoding for Tamil language
by பா. மு. செல்வக்குமார் 02 May '21

02 May '21

Hi, I want to use this encoding <https://github.com/vanangamudi/tace16-utf8-converter/blob/master/tace16.py>[1] for Tamil language text because it is more consistent with the language's nature, and Unicode encoding severely damages(read more here[2] <https://en.wikipedia.org/wiki/Tamil_All_Character_Encoding>) the intrinsic features of the fusion of alphabets. a specific example would be when dealing with regex. *'^[சிகு]'* is the intended expression for lines that starts with either 'சி' or 'கு' just like how in English '^[ab]' matches lines that start with either 'a' or 'b'. But since Unicode represents some of the eastern languages with multiple code points, '^[சிகு]' basically translates to '^[ச,ி,க,ு]' (using the commas for clarity) சி -> ச,ி and கு -> க,ு . Running the expression over a few words in python, gives the results as shown in the attached image. Note: expected results can be obtained by using this expression '^(சி|கு)' but this works for this specific case, but there should be a way to write expressions to match சிசிசிகுகுசிகு? regex in tamil is not a python issue. it is a unicode issue. I suppose if I can encode Tamil text in TACE16 encoding, I can use regex directly over it since (as I understand) re module runs matching over bytes. Two basic questions, 1. How do I approach writing a new text encoding codec for python and register it with the codec module. 2. How would I convert utf-8 encoded pattern for regex into the custom codec so that the pattern and input string for re.match/search is consistent. Links: [1] https://github.com/vanangamudi/tace16-utf8-converter/blob/master/tace16.py [2] https://en.wikipedia.org/wiki/Tamil_All_Character_Encoding -- Thanks, வணங்காமுடி (vanangamudi)

3 4

Accepting a function argument of a particular type specified by the user
by Shreyan Avigyan 26 Apr '21

26 Apr '21

Think it like this. We have this code in Python :- def add(a, b): return a + b Here we are taking two arguments a, b and then returning a + b. But we can pass in instance of any class like str, int, float, dict, user-defined class, etc. But we only want to add int here. Here we can modify it to be, def add(a, b): if type(a) == int and type(b) == int: return a +b raise Exception("Error") In this example it's pretty easy to check if the arguments are int. But in real world programs as the functions become bigger and bigger it's very difficult to check arguments using an if statement. Therefore why not let the user specify what parameter types are gonna be? Like, def add(int a, int b): return a + b If instance of a different class is passed in then raise a TypeError perhaps? If parameter types are not given then let the parameter accept any kind of class instance. This kind of functionality will minimize a lot of if statements related to parameter types and arguments. Thanking you, With Regards

5 9