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 … [View More]

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 … [View More]

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 … [View More]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. [View Less]

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 … [View More]

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 … [View More]

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) … [View More]

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