Mailman 3 February 2022 - Python-ideas

PEP 671 (late-bound arg defaults), next round of discussion!
by Chris Angelico 24 Jul '23

24 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 02 Dec '22

02 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 11 Jun '22

11 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

Regex timeouts
by J.B. Langston 22 Mar '22

22 Mar '22

Hello, I had opened this bug because I had a bad regex in my code that was causing python to hang in the regex evaluation: https://bugs.python.org/issue46627. I have fixed the problem with that specific regex, but more generally I think it would be good to have a timeout option that could be configurable when compiling the regex so that if the regex didn't complete within the specified timeframe, it would abort and throw an exception. The bug was closed as Won't Fix and it was suggested that I bring up my idea here. The suggestion made to me on the bug was to read Mastering Regular Expressions and get better at writing regexes. I will take this advice, but this isn't really a reasonable solution to my problem for a few reasons. My use case is log parsing and I have a large number of regexes that run over many different log lines. With the volume of regexes I have, it's hard to make sure every regex has no potential problems, especially when the pathological behavior only occurs on certain inputs that may not have been anticipated when developing the regex. Also because of the volume of data these regexes are parsing, I would never want to allow a regex to run longer than a few milliseconds because if it did, that would kill my log processing throughput. I'd rather that it just raise an exception and move on to the next log entry. Thanks, J.B.

14 50

repeat until
by lynneandallan＠optusnet.com.au 03 Mar '22

03 Mar '22

Has anyone considered the idea of adding a "do at least once" loop to Python? This is frequently referred to as a do ... while or repeat ... until. At the moment, it's a bit of a hack to achieve this in that we do a 'while True: ( do thing ; if cond: ( break ) )'. Since I don't know how to format these messages, I've used '{' for line-beak-and-indent, ')' for line-break-and-dedent, and ';' for line-break-keeping-same-indent-level. My initial thoughts are that it would be reasonably easy to add a 'repeat: ( do thing ) until condition' which would far better specify intent of the loop (despite the possibility of break, while-true loops give no indication that it's not an infinite loop. And using repeat...until will ensure whoever had to add the code to the Python interpreter wouldn't have any clashes with the current while loop. Thoughts, anyone? Anyone? Bueller? :-)

10 19

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

Re: Make 10**400 / 1e200 work?
by Tim Peters 27 Feb '22

27 Feb '22

[Tim] > >>> cmath.phase(complex(0.0, 0.0)) > 0.0 > >>> cmath.phase(complex(-0.0, 0.0)) > 3.141592653589793 > >>> cmath.phase(complex(0.0, -0.0)) > -0.0 > >>> cmath.phase(complex(-0.0, -0.0)) > -3.141592653589793 [Marco Sulla <Marco.Sulla.Python(a)gmail.com>] > Whoa. I'm quite curious about why. ... There's no compelling reason to be had. They just made stuff up. In this case, it's apparently motivated by "OK, if the imaginary part is near 0, the number is very close to the x axis, and the sign of the real part determines on which side. Then we'll take the limit as the imaginary part approaches zero from the direction of its own sign." Why? Why not! The sign of a zero has no inherent "meaning". Note that these non-made-up results show that limiting process in action: >>> pr = 1.0 # abs(real part) >>> pi = 1e-10 # abs(imaginary part) >>> cmath.phase(complex(pr, pi)) 1e-10 >>> cmath.phase(complex(-pr, pi)) 3.141592653489793 >>> cmath.phase(complex(pr, -pi)) -1e-10 >>> cmath.phase(complex(-pr, -pi)) -3.141592653489793 Make |pi| ever smaller, and the limits are clearly what the original example showed. I'll leave off (this really has nothing to do with Python, as nobody is volunteering to do anything in this area) with this link to more details than anyone can bear ;-) http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1399.htm As it says about two-argument complex functions: """ Since there are four components in (a+I*b)*(c+I*d), and each component can have four classifications, there are 4**4 or 256 cases to consider. The same is true for divide. That is why the reference implementation is so large. """ Their "four classifications" is understating it. They have in mind NaN, Inf, 0, or finite non-zero, but subdivisions within those classifications can breed even more special cases. "Bottomless pit."

1 0

Make 10**400 / 1e200 work?
by Stefan Pochmann 25 Feb '22

25 Feb '22

It crashes because it tries to convert 10**400 to a float and that fails: >>> 10**400 / 1e200 Traceback (most recent call last): File "<pyshell#10>", line 1, in <module> 10**400 / 1e200 OverflowError: int too large to convert to float But with two ints it succeeds: >>> 10**400 / 10**200 1e+200 Note that 1e200 is an integer: >>> 1e200.is_integer() True So that could losslessly be converted to int, and then the division would succeed: >>> 10**400 / int(1e200) 1e+200 So could/should 10**400 / 1e200 be implemented to do that instead of raising the error? Or is it a too rare use case and not worth the effort, or does something else speak against it?

11 26

Str to Byte
by one last Day 25 Feb '22

25 Feb '22

bit = "\xd8\xa3\xd9\x88\xd9\x87 \xd8\xa8\xd8\xaf\xd9\x8a\xd9\x84 \xd9\x85\xd9\x86 \xd9\x82\xd9\x88\xd9\x84\xd8\xaa\xd9\x8a \xd9\x88\xd8\xa7\xd9\x87\xd8\xa7" # here it is a byte but in str encode_bit = bytes(bit , "latin-1") # i can here say to the computer it is byte #then it will print the same words in but byte print(encode_bit) decode = encode_bit.decode() # and i can then decode it and get what i want print( decode ) bit = open("ss.txt","r") bit = bit.read() # but here i read the file and its hold the same bytes above encode_bits = bytes(bit , "latin-1") # but here when i want to say it is bytes it encode it so if it was /xa33 it will be //xa33 decode = encode_bits.decode() # and when i decode it i get /xa33 not the same first one print( decode)

2 1

Using "Get Satisfaction" for Python Suggestions
by Samuel Muldoon 23 Feb '22

23 Feb '22

*More than ten years ago, a video game known as "Minecraft" was in its beta testing-phase.**End-users had many suggestions for Minecraft.* *The Mojang team (developers of Minecraft ) used a web platform for suggested changes to the videogame. **The website was known as "Get Satisfaction" **The GetSatisfaction page for Minecraft as so easy to use that sometimes children posted bug reports for Minecraft. Also, several less tenable thoughts fielded by people of the same mental maturity were quickly filtered out and shot down.* *More than ten years ago, there was a system for a major software project which did a good job of floating good ideas to the top and sinking bad ideas to the bottom.* *GetSatisfaction used a voting system, and the most popular suggestions were often implemented by Mojang's development team. When the Microsoft corporation bought Minecraft, the Minecraft GetSatisfaction page died, so it is difficult to look at now.* *Get Satisfaction allowed beta-testers to prioritize and sort well-written bug-reports, and I personally thought it worked better than git or other alternatives * *The python-ideas mailing list is a very cumbersome way to vet changes to the Python interpreter or other aspects of the python language. If the power-that-be would work with GetSatisfaction people to make a copy-cat of the GetSatisfaction page for Minecraft, I think that the python community could then better drive PEPs (Python Enhancement Proposals)* *Samuel Muldoon* *muldoonsamuel(a)gmail.com <muldoonsamuel(a)gmail.com>*

9 10