Mailman 3 November 2022 - Python-ideas

PEP 671 (late-bound arg defaults), next round of discussion!
by Chris Angelico July 23, 2023

July 23, 2023

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

Better (?) PRNG
by James Johnson Dec. 7, 2022

Dec. 7, 2022

I wrote the attached python (3) code to improve on existing prng functions. I used the time module for one method, which resulted in disproportionate odd values, but agreeable means. I used the hashlib module for the second. It is evident that the code is amateur, but the program might result in better PRN generation. The "app" lends itself to checking, using statistical tools (see comments.) I remain a fan, James Johnson

8 23

Re: Better (?) PRNG
by Chris Angelico Dec. 6, 2022

Dec. 6, 2022

(I'm assuming that you sent this personally by mistake, and am redirecting back to the list. My apologies if you specifically didn't want this to be public.) On Tue, 15 Nov 2022 at 22:34, James Johnson <jj126979(a)gmail.com> wrote: > > It’s been a couple of years ago, but as I recall the duplicates seemed to be of two or three responses, not randomly distributed. > > I looked at my code, and I DID salt the hash at every update. > > At this point, my curiosity is engaged to know if this s/w solution is as good as others. I don’t have the training to test how often 9 follows 5, for example, but I am competitive enough to ask how it holds up against MTprng. I think it’s possibly very good, for s/w, and I’m emboldened to ask you to modify the code (it requires you data enter the numbers back to the machine, allowing time to pass;) to accumulate the results for 2 or 3 million, and see how it holds up. I don’t think the numbers track the bell curve on distribution . I speculate it’s more square. I suppose this is desirable in a PRNG? > I'll get you to do the first step of the modification. Turn your code into a module that has a randbelow() function which will return a random integer from 0 up to the provided argument. (This is equivalent to the standard library's random.randrange() function when given just one argument.) If you like, provide several of them, as randbelow1, randbelow2, etc. Post that code, and then I'll post a test harness that can do some analysis for you. ChrisA

4 10

Enhancing variable scope control
by Anony Mous Dec. 6, 2022

Dec. 6, 2022

As it stands now, to create a local scope, you must define a function. However, there are many cases where various things can reasonably be done inline. Preparatory code is often done this way. Good coding practice is generally accepted to be that variables are local if at all possible. However, in direct, inline Python code, we're inherently creating variables with a global scope. We don't actually need a function for this kind of code; but a local scope would often be valuable (as we see with lambda.) Moving things off into a function can create a circumstance where we have to go looking for the function. When something is a "one-shot" as in global preparatory code, that's doing more work, and creating more indirection, than needs actually be done. But global operations have their own pitfalls, one of which is variable collisions. So Python sort of drives us to make "one-use" functions where lambdas are insufficient to the case in order to control locality. You can end up writing things like... def PrepOne(): for MyCount in range(0,10): pass PrepOne() ...which achieves the locality desired for variable MyCount, but is clunky. It also clutters the global namespace with prepOne, which has no good reason to exist. So I'm thinking of something along these lines: local: # <== or whatever syntax makes sense for MyCount in range(0,10): pass So in that example, the code is inline - runs as part of the global, sequential code execution - but the variable MyCount is local and goes "poof" once the local: scope is exited. This is the scoping equivalent of a pair of curly braces in c and c++. I would like to see it be nestable, as scopes are in c/c++: local: # <== or whatever syntax makes sense for MyCount in range(0,10): local: for YourCount in range(0,MyCount+1) pass There, MyCount is available in both scopes (the first local: is an enclosing scope) and YourCount is available only in the second local: scope. Or, local: could be very strict, and require further syntax to incorporate a previous scope, something like this: local: # <== or whatever syntax makes sense for MyCount in range(0,10): local: incorporate MyCount # <== or whatever syntax makes sense for YourCount in range(0,MyCount+1) pass Lastly, I suggest that the global keyword be used to expose global scope variables, just as it is within def functions: TheirCount = 10 local: # <== or whatever syntax makes sense global TheirCount for MyCount in range(0,TheirCount): local: for YourCount in range(0,TheirCount) pass This would also be useful within normal functions, and again allows the program flow to be linear rather than calling a function-within-a-function.

10 14

zip(x, y, z, strict=True)
by Ram Rachum Dec. 1, 2022

Dec. 1, 2022

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

Re: Enhancing variable scope control
by Anony Mous Dec. 1, 2022

Dec. 1, 2022

Danceswithmice wrote: > The larger criticism of the above is the chosen-name The name is irrelevant; an extremely minor implementation detail, and one that is meaningless if the idea itself does not pass muster. Users would not see the name in any case; it's an interpreter level issue. So on with the concept, then: > However, deliberating over the choice of name for the function makes the code easy to read The idea is that YOU write "local:", and the interpreter, without you ever seeing it, promotes that into a hidden function with a hidden name and a hidden call. --- p.f.moore wrote: > That would make "return" in the local scope exit the scope, not the enclosing function. Which is almost certainly not what people would expect from a "local scope" statement. Hence my remark about return and yield requiring attention. These would be disallowed in the context of "local:" UNLESS there is an enclosing scope of "def function():", so there's no issue of what they do if they are simply mainlined, and (I think) a well defined result if they are not. --- rosuav wrote: > Not sure what you mean about "mak[ing] sure return and yield were appropriate" though. Inside such a local block, are you expecting yield and return to apply to the outer function? I would expect them to return to, or yield to, the next outer "def" function, assuming they were in a "local:" inside another function. I would expect return and yield to be outright disallowed otherwise. I would also expect that the interpreter would know very well how deep it is in functions, generated or programmer defined. > For a much, MUCH easier way to give semantics to this for local MyVariable in range(0,10): Yes, that could work. It requires more declarations (one per variable, right?) than declaring an entire block local to limit the scope(s), but that's the only issue I see. The ability to create non-colliding local variables is the endgame benefit either way. The name-mangling... low level interpreter action, if done well, we'd never see it. It could live in un-mangled form in its own collection. --- I've written a Python pre-compiler (primarily in order to allow extending the string class, which has some annoying tight couplings to "string" and 'string') I wanted to work around; I think I'll add "local:" to it and see how that feels. Thanks for everyone's input. --Ben

3 2

Re: Enhancing variable scope control
by Anony Mous Dec. 1, 2022

Dec. 1, 2022

Barry wrote: > The ways scoping works in python is very hard to change as you are asking for i think was a major reason to reject. Perhaps it isn't all that difficult; For instance, a "local:" declaration could be treated as if it were "def function()" with an immediately succeeding call as far as the interpreter is concerned. That buys the scoping for (nearly) free. We write... local: for MyVal in range(0,10) pass ...interpreter codes that, out of sight, as: def ghost_func_0000001(): for MyVal in range(0,10) pass ghost_func_0000001() Might take a bit of fiddling to make sure return and yield were appropriate [requiring an actual enclosing def function():], but other than that, it's basically the same idea -- provides scoping, making it easier for us to code, debug, and document, while significantly decreasing the likelihood of variable collisions. --Ben

4 3

Idea: PEP 3132 – Extended Iterable Unpacking for custom classes
by Randolf Scholz Nov. 28, 2022

Nov. 28, 2022

Basically, I think it would be need if we could write first, *tail = np.array([1,2,3]) and have tail be a np.ndarray. Currently, the result is list. Either, python could try initializing the object using the received type, or one could introduce a new dunder classmethod __from_iterable__ that custom classes can implement.

2 1

Allow more flexibility for describing bytes objects.
by Ronald Hoogenboom Nov. 24, 2022

Nov. 24, 2022

Refer to PEP 3137 and PEP 358. Bytes objects are for conveying binary data (or encoded strings). Such binary data is customary specified in hex-dump or base64 format in source files. It would be nice to introduce a way in python to do that 'natively' (at lexical analysis time) using x-strings and y-strings (in lieu of f-strings). x-strings: x"0123456789abcdef" (x-prefixed quoted string of even-numbered amount of characters of the set [0-9a-fA-F], whitespace ignored) equivalent to: b"\x01\x23\x45\x67\x89\xab\xcd\xef" (but more readable) y-strings: y"ASNFZ4mrze8=" (y-prefixed quoted string of valid base64, whitespace ignored) equivalent to: b"\x01\x23\x45\x67\x89\xab\xcd\xef" (but shorter) This is not a replacement of the hex/base64 encoding, binascii packages etc. It just gives the programmer more freedom to specify literal bytes objects in the source code.

5 4

Moderator: does this code execute correctly?
by James Johnson Nov. 18, 2022

Nov. 18, 2022

Dear Sir: This script SHOULD build a grid with staggered columns. I am not satisfied that it should stagger in the direction that I want it to, but standing alone, it should do SOMETHING. I keep getting a grid of identical rows. Is it my anaconda3; is it a code optimization? I know it sounds like incompetence on my part, but it's pretty straightforward. Am I actually an idiot, or is this an artifact? Regards, James J Abilene, TX

2 3