Mailman 3 February 2023 - 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

Restricting access to sensitive APIs with a permission model like Deno
by python＠ruebezahl.mozmail.com 01 Mar '23

01 Mar '23

Hello all, Supply chain attacks are becoming a pressing concern in software development due to the large number of dependencies and multiple attack vectors. Using third party modules (libraries, packages etc) is always a risk but the true potential of these attacks is now being weaponized. One way to deal with the risk is by limiting access to sensitive APIs like filesystem, shell, network and ffi so that packages which aren't explicitly granted permissions cannot use them, reducing their ability to do damage. For example, a yaml parser should not need to use ffi, network nor shell. A command line argument parser library should not use network, ffi nor filesystem. Deno, a runtime for Typescript contains an interesting implementation of a permissions model for APIs. I strongly think Python could benefit from such functionality and hacked together a quick experiment here: https://github.com/R9295/cpython Currently, it only prevents module imports in a very elementary manner but perhaps it can be of use to spark a discussion for an implementation. Looking forward to your thoughts, Aarnav

10 27

Proposal: -X importcache to supplement -X importtime for loaded modules
by Noah Kim 27 Feb '23

27 Feb '23

All, I'm writing to propose an adjacent interpreter flag to `-X importtime`: `-X importcache` (open to alternative naming). While `-X importtime` is incredibly useful for analyzing module import times, by design, it doesn't log anything if an imported module has already been loaded. `-X importcache` would provide additional output for every module that's already been loaded: ``` >>> import uuid import time: cached | cached | _io import time: cached | cached | _io import time: cached | cached | os import time: cached | cached | sys import time: cached | cached | enum import time: cached | cached | _io import time: cached | cached | _io import time: cached | cached | collections import time: cached | cached | os import time: cached | cached | re import time: cached | cached | sys import time: cached | cached | functools import time: cached | cached | itertools import time: 151 | 151 | _wmi import time: 18290 | 18440 | platform import time: 372 | 372 | _uuid import time: 10955 | 29766 | uuid ``` In codebases with convoluted/poorly managed import graphs (and consequently, workloads that suffer from long import times), the ability to record all paths to an expensive dependency--not just the first-imported--can help expedite refactoring (and help scale identification of this type of issue). More generally, this flag would provide a more efficient path to tracking runtime dependencies. As a proof of concept, I was able to hack this functionality into `-X importtime` by adding a couple lines to `import_ensure_initialized` in `Python/import.c` (hence the output above). A separate flag is probably desirable to preserve backwards compatibility. Looking forward to your feedback, Noah

5 6

Combinations of keywords
by Otomatyk dupont 21 Feb '23

21 Feb '23

Hello, here is my ideas of new keywords combinations : (the code is writed like this #code#. Sorry if I do some english mistakes) 1 - and pass if except This one is just a shortcut of # try : code here except : do something # Its syntaxe is #CODE and DO_SOMETHING if except#, it's more readable i think. It is usefull for code like this : #import A_WINDOW_MODULE and import A_UNIX_MODULE if except If DO_SOMETHING is replaced by #pass# it just skips the ligne (and the error) 2 - CODE if CONDITION else CODE I would like the #VALUE if CONDITION else OTHER_VALUE" can also executes code. Like : #Sign_in(user) if button_i_dont have_a_acount.press() else Log_in(user)# or #break if quit==True# If the #else# isnt present and the condition result is False, the interpreter don't executes that ligne What do you think about ?

5 4

Deprecate misleading escapes in strings
by Arusekk 17 Feb '23

17 Feb '23

Hi all! I was writing a tutorial on the distinction between bytes and strings and why it is important, when I saw the root cause. People coming from C, Perl, Python 2 and similar languages tend to misinterpret "\x90" for b"\x90" often. My idea is that Python could deprecate string literals containing any non-ASCII codepoints specified in any way different from unicode or unicode escapes (\u, \U, \N). (Actually I found that I started having the idea already back in 2021 on StackOverflow[1]. The question is an excellent example of what I mean.) I would not go so far to follow JSON (disallowing \x11 and \222 escapes completely), but while writing "\x00" or "\0" is useful and widely used, "\x99" (and especially "\777"!) is probably marginal and definitely less explicit than "\u0099" (in the Zen of explicit better than implicit). Byte strings do not treat b"\u00ff" as b"\xff". In the first part of implementing it, Python could raise a SyntaxWarning (or should it be DeprecationWarning? BytesWarning?), suggesting "\x99" to either become b"\u0099" or b"\x99", eventually promoting it to some equally helpful SyntaxError. All of it could be hidden behind a feature like from __future__ import backslashes (one nice name I can think of). The new regular expression for octals would be \\[01]?[0-7]{1,2} and \\x[0-7][0-9A-Fa-f] for hexadecimals, hopefully not confusing anyone, and not much more complex than the old ones. In the meantime, probably between introducing a warning and changing it to become an error (the most reasonable timeline I can think of now), the default ascii() representation should eventually use the \u0099 form for all such codepoints, to keep the invariant of eval(ascii(x)) == x without syntax warnings. repr() is also affected, but it is fortunately limited to the [\x80-\xa0\xad] range. I mean [\u0080-\u00a0\u00ad] :-) Another timeline would be to change the repr first, initially hidden under an interpreter flag or environment variable, then officially deprecate it in the documentation, then introduce the error guarded by from __future__ import backslashes or another flag, then make the repr use \u by default, then add the warning and finally make it always raise an error. As a precedent, breaking repr() was not a dealbreaker when introducing randomized seeds (even repr({"a", "b"}) is now unpredictable). This would be of course a breaking change for a lot of unit tests, and stuff like pickle should probably support old syntax, delaying any such change until a new protocol comes (if it applies to the newest one --- quite sure it does not). Such a breaking change must be used wisely. Other changes to octal escapes could be sneaked in, based on conclusions from the 2018 'Python octal escape character encoding "wats"' thread[2] (I like writing "\0" and "\4" though, just to make my opinion clear). If going the whole hog, the 2015 'Make non-meaningful backslashes illegal in string literals' thread[3] could be revived as well, maybe even with "\f\v" deprecated, "\e" = "\33" introduced and such. Please let me know what you think, what else could break, and is it useful anywhere else apart from my use case, and what similar problems you have. Cheers, Arusekk [1]: https://stackoverflow.com/q/64832281/3869724 [2]: https://mail.python.org/archives/list/python-ideas@python.org/thread/ARBCIP… [3]: https://mail.python.org/archives/list/python-ideas@python.org/message/PJXKD…

6 7

timedelta.strptime() and timedelta.strftime()
by Thomas Mc Kay 02 Feb '23

02 Feb '23

I was looking for a simple intuitive way to parse a timedelta from a string. The best I could find feels clunky at best: https://stackoverflow.com/questions/4628122/ Solution 1 looks like this: ``` from datetime import datetime, timedelta t = datetime.strptime('05:20:25', '%H:%M:%S') delta = timedelta(hours=t.hour, minutes=t.minute, seconds=t.second) ``` Solution 2 looks like this: ``` from datetime import datetime, timedelta t = datetime.strptime('05:20:25', '%H:%M:%S') delta = t - datetime.combine(t.date(), time.min) ``` Solution 3 looks like this: ``` from datetime import timedelta import re match = re.match(r'(?P<hours>\d{2}):(?P<minutes>\d{2}):(?P<seconds>\d{2})', '05:20:25') delta = timedelta(**match.groupdict()) ``` Formatting back to strings is as verbose: ``` string = f'{delta.hours:02d}:{delta.minutes:02d}:{delta.seconds:02d}' I think it would be nicer and more intuitive if timedelta had strptime and strftime like datetime has. ``` delta = timedelta.strptime('05:20:25', '%H:%M:%S') # timedelta(hours=5, minutes=20, seconds=25) string = delta.strftime('%H:%M:%S') # '05:20:25' ``` The reason I would like this in the standard lib (vs maintaining my own helpers) is that : a) it feels very natural, especially after years of using these methods on datetime. b) there's currently three ways to do it that I've seen in the wild (documented above). Having this in the std lib would help with the ZoP "There should be one-- and preferably only one --obvious way to do it." (the "obvious" part of this statement is covered in (a)). I'm sure there's corner cases I'm not seeing that make this more complicated to implement than it seems... Let me know. Cheers, Thomas

2 2