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

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

Python Documentation in Bengali (translation)
by sharifmehedi24＠outlook.com 16 Sep '21

16 Sep '21

Hi there all, I am preparing a team to start translating python documentation to Bengali. I'd appreciate some reference materials, comments and ideas about this. Thank you

4 4

Create a @deprecated decorator (annotation)
by Leonardo Freua 15 Aug '21

15 Aug '21

[Migrating from https://bugs.python.org/issue44701] Would it be interesting to create a @deprecated decorator to avoid adding warnings.warn("deprecation message", DeprecationWarning, stacklevel=2) in methods body? Using the decorator approach to indicate depreciation would make the methods cleaner (leaving only their responsibilities in the body) and would be easier to identify, as the cue would be close to the method signature and not mixed with the logic inside the body. in some cases it will still be necessary to put warnings.warn (..) inside the body of functions/methods because of some message display condition, or we could also express the message display condition in the decorator in @deprecated itself. But it would be interesting to have the possibility of not putting this inside the method body. Even the decorator can come from the notices module. Example: (Before) def check_metadata(self): """Deprecated API.""" warn("distutils.command.register.check_metadata is deprecated, \ use the check command instead", PendingDeprecationWarning) check = self.distribution.get_command_obj('check') check.ensure_finalized() check.strict = self.strict check.restructuredtext = 1 check.run() (after) @deprecated("distutils.command.register.check_metadata is deprecated, \ use the check command instead") def check_metadata(self): """Deprecated API.""" check = self.distribution.get_command_obj('check') check.ensure_finalized() check.strict = self.strict check.restructuredtext = 1 check.run()

13 16

copy-paste code snippets to the python console
by Raymond Bisdorff 15 Aug '21

15 Aug '21

Dear Python developers, It would be helpful, if the following issue with copy-pasting python code-snippets into the standard shell console, could be investigated and corrected. https://stackoverflow.com/questions/2501208/copying-and-pasting-code-into-t… In particular, copying and pasting from sphinx python and pycon code-blocks with copy button (only >>> and ... lines), is at present not generally working due to the "the shell-s de-indent cmd" need for empty lines. See https://digraph3.readthedocs.io/en/latest/index.html Thank you in advance for you attention, Best Regards, Raymond Bisdorff -- Raymond Bisdorff Emeritus Professor of Computer Science and Applied Mathematics University of Luxembourg http://rbisdorff.github.io/

2 1

More natural type hints for built-in containers
by Ignacio Pickering 02 Aug '21

02 Aug '21

Currently type hints for built-in containers are, in my opinion, less succint than required. I suspect it is probably not very difficult for a type checker to interpret something like this for example: var1: {str: (int, int)} = {"label": (1, 2)} var2: {str} = {"other_label"} def function(param1: {int: str} = {1: "foo"}, param2: (int, ...) = (1, 2, 3)) -> (int, (str, ...)): return 3, ("foo", "bar") as equivalent to: var1: dict[str, tuple[int, int]] = {"label": (1, 2)} var2: set[str] = {"other_label"} def function(param1: dict[int, str] = (1, "foo"), param2: tuple[int, ...] = (1, 2, 3)) -> tuple[int, tuple[str, ...]]: return 3, ("foo", "bar") I thought of posting something like this as a mypy feature suggestion, but I suspect the language would need to modify the way type annotations are interpreted for something like it to work (or maybe not?). Basically, inside a type annotation, the objects created by (a, b), [a], {a: b}, {a} would be reinterpreted as the same thing as constructing tuple[a, b], dict[a, b], list[a], set[a]. I have found myself wanting to write things like this a couple of times, so I think this overloaded usage of builtin containters is natural. I actually feel it is so natural it must either have been proposed before (in which case I would love to give the feature my +1) or there is some more or less obvious flaw.

5 6

Possibility to specify port in __init__ of ftplib.FTP
by Marty 01 Aug '21

01 Aug '21

Hi. If there is possible to connect and login to ftp server within __init__, I think it would make sense to add parameter **port** in ftplib.FTP. It could look like this: ``` def __init__(self, host='', port=0, user='', passwd='', acct='', timeout=_GLOBAL_DEFAULT_TIMEOUT, source_address=None, *, encoding='utf-8'): self.encoding = encoding self.source_address = source_address self.timeout = timeout if host: self.connect(host, port) if user: self.login(user, passwd, acct) ``` (Or port parameter could be added at the end of the __init__ parameters not to break current logic.) Currently if I need to specify port, I have to do it like this: ``` with FTP() as ftp: ftp.connect(host, port) ftp.login(user, password) # my actions ``` If the port parameter would be added, I could use it like this: ``` with FTP(host, port, user, password) as ftp: # my actions ``` In all my cases, all I need is to connect to ftp server and work with it. If there is some trouble with connection or login, the code still can't continue working with ftp... Do you rather use connect() and login() explicitly or just let it connect and login within __init__ implicitly? What do you think about it? Thanks.

2 1