Mailman 3 November 2019 - Python-ideas

Python should take a lesson from APL: Walrus operator not needed
by martin_05＠rocketmail.com 22 Nov '19

22 Nov '19

During a recent HN discussion about the walrus operator I came to realize yet another advantage of notation. I used APL professionally for about ten years, which made it an obvious source of inspiration for an example that, in my opinion, demonstrates why the Python team missed a very valuable opportunity to take this wonderful language and start exploring the judicious introduction of notation as a valuable tool for thought (borrowing from Ken Iverson's APL paper with that title [0]). To simplify, I'll define the desire for this walrus operator ":=" as "wanting to be able to make assignments within syntax where it was previously impossible": if x = 5 # was impossible # and now if x := 5 # makes is possible A more elaborate example given in the PEP goes like this: Current: reductor = dispatch_table.get(cls) if reductor: rv = reductor(x) else: reductor = getattr(x, "__reduce_ex__", None) if reductor: rv = reductor(4) else: reductor = getattr(x, "__reduce__", None) if reductor: rv = reductor() else: raise Error( "un(deep)copyable object of type %s" % cls) Improved: if reductor := dispatch_table.get(cls): rv = reductor(x) elif reductor := getattr(x, "__reduce_ex__", None): rv = reductor(4) elif reductor := getattr(x, "__reduce__", None): rv = reductor() else: raise Error("un(deep)copyable object of type %s" % cls) At first I thought, well, just extend "=" and be done with it. The HN thread resulted in many comments against this idea. The one that made me think was this one [1]: "These two are syntactically equal and in Python there's no way a linter can distinguish between these two: if reductor = dispatch_table.get(cls): if reductor == dispatch_table.get(cls): A human being can only distinguish them through careful inspection. The walrus operator not only prevents that problem, but makes the intent unambiguous." Which is a perfectly valid point. I get it. Still, the idea of two assignment operators just didn't sit well with me. That's when I realized I had seen this kind of a problem nearly thirty years ago, with the introduction of "J". I won't get into the details unless someone is interested, I'll just say that J turned APL into ASCII soup. It was and is ugly and it completely misses the point of the very reason APL has specialized notation; the very thing Iverson highlighted in his paper [0]. Back to Python. This entire mess could have been avoided by making one simple change that would have possibly nudged the language towards a very interesting era, one where a specialized programming notation could be evolved over time for the benefit of all. That simple change would have been the introduction and adoption of APL's own assignment operator: "←" In other words, these two things would have been equivalent in Python: a ← 23 a = 23 What's neat about this is that both human and automated tools (linters, etc.) would have no problem understanding the difference between these: if reductor ← dispatch_table.get(cls): if reductor == dispatch_table.get(cls): And the larger example would become this: if reductor ← dispatch_table.get(cls): rv ← reductor(x) elif reductor ← getattr(x, "__reduce_ex__", None): rv ← reductor(4) elif reductor ← getattr(x, "__reduce__", None): rv ← reductor() else: raise Error("un(deep)copyable object of type %s" % cls) This assignment operator would work everywhere and, for a period of time, the "=" operator would be retained. The good news is that old code could be updated with a simple search-and-replace. In fact, code editors could even display "=" as "←" as an option. The transition to only allowing "←" (and perhaps other symbols) could be planned for Python 4. Clean, simple and forward-looking. That, to me, is a good solution. Today we have "=" and ":=" which, from my opinionated perspective, does not represent progress at all. [0] http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf [1] https://news.ycombinator.com/item?id=21426338

12 33

Adding CLOCK_TAI to Python
by Russell Owen 21 Nov '19

21 Nov '19

I would like access to CLOCK_TAI in the time package, for systems where it is available (such as linux, but not, alas, macOS). For systems that are properly configured CLOCK_TAI is very useful as a *standard* monotonic time with a standard epoch. Use cases include message timestamps and pointing telescopes… I am willing to do most or all of the work, but before I start on that I would like to know if this pull request is likely to be approved. Will this need a PEP first? Regards, Russell P.S. For systems that are not properly configured CLOCK_TAI typically returns the same thing as CLOCK_UTC. This is a well known issue, but Python is in no position to do anything about it other than warn in the documentation.

1 0

Using 'with' with extra brackets for nicer indentation
by gabriel.kabbe＠mail.de 20 Nov '19

20 Nov '19

Hello everybody, today I tried to open four files simultaneously by writing with ( open(fname1) as f1, open(fname2) as f2, open(fname3) as f3, open(fname4) as f4 ): ... However, this results in a SyntaxError which is caused by the extra brackets. Is there a reason that brackets are not allowed in this place?

27 112

Ability to set precedence of classdict (returned from __prepare__) for a metaclass type
by Steve Jorgensen 20 Nov '19

20 Nov '19

When using a custom classdict to implement a DSL or use in the body of a class definition, from what I can tell by experiment, the classdict takes priority, and the surrounding context is only referenced if trying to get an item from the classdict raises `KeyError`. There is at least one case in which I would like to do the reverse, and have the classdict be secondary to (masked by) any variables defined in the context surrounding the execution of the class body. I have been able to at least unmask builtins by having the classdict object first try to get a result from `__builtins__` and then fall back to itself. Also, in the actual class body, declaring a variable as `global` seems to be a workaround for global variables, but that has to be done explicitly in the body of any subclass that needs it. Also, that does not handle non-globals in its surrounding context. I'm not sure what the best way to deal with this would be, but my first thought is to maybe have a property that can be set on the metaclass type such as `metacls.relictant_classdict = True`.

10 26

Consider blocking heterogeneous chained comparison
by Neil Girdhar 19 Nov '19

19 Nov '19

Some people find this legal syntax confusing: A in B < C (It means A in B and B < C.) I feel like most code reviews would not allow this kind of code to be checked in, at least without a comment explaining what the code does. What are the motivating reasons for allowing this syntax? Is there any idiomatic code that uses it? If not, I suggest dividing the comparison operators into two groups: in, not in, is, is not and <, >, <=, >=, ==, != and then disallowing chaining of operators from both groups. For example, still allowed: A <= B <= C A in B in C disallowed: A < B in C The advantage of such a change is that there is fewer "gotcha" code. I admit that this code is rarely written, but it can come up. For example, you might write your own comparison operator and then want to see if it's working: A < B is None returns false if B is not None even if A < B returns None. Also, in my opinion, the existence is a deterrent to Python and takes away from Python's beauty as a language. The downside of such a change is that the language is more complicated. As far as implementation goes, this can be done after parsing when the AST is checked and errors are raised (from what I remember). Best, Neil

6 5

Improved Function Decorators
by Samuel Muldoon 19 Nov '19

19 Nov '19

At present, multi-argument function decorators are a little bit tricky to implement. As an example (somewhat contrived), suppose that `wait` is a function decorator which haults program execution for a few seconds before calling the wrapped function. If you do not pass a float value into *delay* then the default value is 1 second. #EXAMPLE 1A @wait def print_something(something): print (something) #EXAMPLE 2A @wait(0.2) def print_something_else(something): print (something) The `@wait` gets implemented almost like the following code: # EXAMPLE 1B def print_something(something): print (something) print_something = wait(print_something) # EXAMPLE 2B temp = wait(0.2) def print_something_else(something): print (something) print_something = temp(print_something) What is tricky is the following: * if `Wait` has no arguments: `Wait` is the decorator. else: # `Wait` receives arguments `Wait` is not the decorator itself. Instead, `Wait` ***returns*** the decorator* As a result, people write strange-looking (hard-to-read) decorators, like the following: def wait(func=None, delay=1.0): def decorator_wait(func): def wrapper_wait(*args, **kwargs): time.sleep(delay) return func(*args, **kwargs) return wrapper_wait return decorator_wait(func) if func is not None else decorator_wait This suggestion is that a new operator be introduced. The old @-syntax for decorators would remain unchanged, preserving backwards compatibility. It does not really matter to me what string is used for the operator, but I was thinking *$*, or if not that !@ with an interobang before the @. Our opening example of how it would work is shown below: # Example 3A $dec(1, 2, 3) def foo(): pass ########################################### # Example 3B def foo(): pass foo = dec(foo, 1, 2, 3) Examples 3A and 3B are meant to be equivalent. The new decorator operator would simply pass the decorated function into the decorator as the leftmost argument. @wait def slowly_print_something(something): print(something) #-------------------------------- def slowly_print_something(something): print(something) slowly_print_something = wait(slowly_print_something) ################################################## @wait(3.0) def slowly_print_something_else(something_else): print(something_else) #----------------------------------- def bar(something_else): print(something_else) slowly_print_something_else = wait(bar, 3.0) ###################################################### import time def wait(inny, delay=1.0): def outty(*args, **kwargs): time.sleep(delay) return inny(*args, **kwargs) return outty Maybe call them "dollar decorators," or if the !@ syntax is used, then maybe call them "bang decorators." I care more about the functionality than the exact strings of symbol which is used to signal the interpreter what's coming next.

4 3

Differentiate variables form everything else
by tonycstech＠gmail.com 18 Nov '19

18 Nov '19

Inability to visually identify a variable without looking at where its placed and/or how its used is sometimes brain damaging task when it comes to understanding code someone else wrote. In fact, i dont know any IDE that can identify python or any language variable and color them as good as Autoit version of Scite does. In Autoit, variables are prefixed with $ sign. You look at the code and you instantly know ITS A VARIABLE and it cannot be anything else. Many people search google wanting to use $ sign for variables and it is mentioned to be "not best practice". Who says "not best practice" ? If it works and works well, i see no reason to not take advantage of every great benefit it provides.

5 10

Tuple Comprehension
by Daniel Zeng 18 Nov '19

18 Nov '19

Syntax for tuple comprehension, something like: (i, for i in range(10)) This shouldn't result in ambiguity, since generators need to be in parentheses anyway: (i, for i in range(10)) vs (1, (i for i in range(10)))

7 11

COMBINE operator &
by tonycstech＠gmail.com 18 Nov '19

18 Nov '19

x = 5 y = 5 print (x+y) #prints 10 This is easy because everyone knows that + sign adds 2 values together. print(str(x)+str(y)) #prints 55 I understand that there are more then one way to do this but, the bottom line is, this is not logical. Tony+Maria is what we used to write when we were little children fallen in love, but once we grow up, we started to think (more or less) and write the following: Tony & Maria This is pretty much what i suggest. Add new COMBINE operator sign & that will combine what ever value there is into one printable line without need for converting or formatting it. Examples: x = ("I love") y = ("this idea ") z = ("posted on November ") a = 18 print (x & y & z & a) # prints I love this idea posted on November 18 As of right now, this could look like this: x = ("I love") y = ("this idea ") z = ("posted on November ") a = 18 print (x + y + z + str(a)) and thats not much difference to worry about. Problem comes when there are more different data types need to be added and combined together. This would make things allot easier for many people and make string handling easier also.

6 6

Re: Consider blocking heterogeneous chained comparison
by Kyle Stanley 17 Nov '19

17 Nov '19

> Some people find this legal syntax confusing: > A in B < C I agree, that syntax definitely seems counter-intuitive. If it came up in a code review, I would request a revision to "A in B and B < C". > I feel like most code reviews would not allow this kind of code to be checked in, at least without a comment explaining what the code does. What are the motivating reasons for allowing this syntax? Is there any idiomatic code that uses it? I can't personally imagine any practical use case for the syntax that couldn't be expressed differently in a way that's far more clear to readers. But, I don't think this is so much of a case of us choosing to *allow* the syntax, this seems to be more of a case where we don't explicitly *prevent* the syntax (through raising a SyntaxError). From my experience, SyntaxError is raised primarily from clear mistakes that are easy to make (particularly for those who are new to the language or accidental typos) rather than simply syntax that is obscure, impractical, and/or hard to understand. It's realistically impossible to isolate every case of highly counter-intuitive usage of Python syntax, not to mention the resources it takes to implement a SyntaxError for each of them. To me, it seems that the usage of "A in B <comparison_operator> C" is something that's not easy to do by accident, I can't imagine what someone would be intending to practically accomplish and mistakenly end up with that syntax, not knowing it could be expressed differently. A few important questions to consider: 1) Is this syntax misused enough to justify implementing a SyntaxError? 2) Would raising a SyntaxError help to point those who misuse it in the right direction? 3) Is it worth the resources it would take to implement the SyntaxError? 4) Does implementing the SyntaxError provide enough positive benefit to justify breaking backwards compatibility? Even if it's very rarely used and could be expressed differently, this still applies. > Also, in my opinion, the existence is a deterrent to Python and takes away from Python's beauty as a language. I would have to disagree, every language has its obscure corner cases and confusing ways to write expressions. I don't think the number of ways that users can misuse the language in an obscure manner to write confusing code should at all detract from it's beauty. If it were easy to misuse the language and *accidentally* write confusing code that would be one thing, but I don't think "A in B < C" is an example of that scenario. As the others mentioned, I think the best solution to dealing with this type of syntax would be with a linter rather than directly preventing its usage. (resent because the CC address was incorrect) On Sun, Nov 17, 2019 at 6:01 AM Kyle Stanley <aeros167(a)gmail.com> wrote: > > Some people find this legal syntax confusing: > > > A in B < C > > I agree, that syntax definitely seems counter-intuitive. If it came up in > a code review, I would request a revision to "A in B and B < C". > > > I feel like most code reviews would not allow this kind of code to be > checked in, at least without a comment explaining what the code does. What > are the motivating reasons for allowing this syntax? Is there any > idiomatic code that uses it? > > I can't personally imagine any practical use case for the syntax that > couldn't be expressed differently in a way that's far more clear to > readers. But, I don't think this is so much of a case of us choosing to > *allow* the syntax, this seems to be more of a case where we don't > explicitly *prevent* the syntax (through raising a SyntaxError). > > From my experience, SyntaxError is raised primarily from clear mistakes > that are easy to make (particularly for those who are new to the language > or accidental typos) rather than simply syntax that is obscure, > impractical, and/or hard to understand. It's realistically impossible to > isolate every case of highly counter-intuitive usage of Python syntax, not > to mention the resources it takes to implement a SyntaxError for each of > them. > > To me, it seems that the usage of "A in B <comparison_operator> C" is > something that's not easy to do by accident, I can't imagine what someone > would be intending to practically accomplish and mistakenly end up with > that syntax, not knowing it could be expressed differently. A few important > questions to consider: > > 1) Is this syntax misused enough to justify implementing a SyntaxError? > > 2) Would raising a SyntaxError help to point those who misuse it in the > right direction? > > 3) Is it worth the resources it would take to implement the SyntaxError? > > 4) Does implementing the SyntaxError provide enough positive benefit to > justify breaking backwards compatibility? Even if it's very rarely used and > could be expressed differently, this still applies. > > > Also, in my opinion, the existence is a deterrent to Python and takes > away from Python's beauty as a language. > > I would have to disagree, every language has its obscure corner cases and > confusing ways to write expressions. I don't think the number of ways that > users can misuse the language in an obscure manner to write confusing code > should at all detract from it's beauty. If it were easy to misuse the > language and *accidentally* write confusing code that would be one thing, > but I don't think "A in B < C" is an example of that scenario. > > As the others mentioned, I think the best solution to dealing with this > type of syntax would be with a linter rather than directly preventing its > usage. > > On Sun, Nov 17, 2019 at 3:45 AM Neil Girdhar <mistersheik(a)gmail.com> > wrote: > >> Some people find this legal syntax confusing: >> >> A in B < C >> >> (It means A in B and B < C.) >> >> I feel like most code reviews would not allow this kind of code to be >> checked in, at least without a comment explaining what the code does. What >> are the motivating reasons for allowing this syntax? Is there any >> idiomatic code that uses it? >> >> If not, I suggest dividing the comparison operators into two groups: >> >> in, not in, is, is not >> >> and >> >> <, >, <=, >=, ==, != >> >> and then disallowing chaining of operators from both groups. >> >> For example, still allowed: >> >> A <= B <= C >> >> A in B in C >> >> disallowed: >> >> A < B in C >> >> The advantage of such a change is that there is fewer "gotcha" code. I >> admit that this code is rarely written, but it can come up. For example, >> you might write your own comparison operator and then want to see if it's >> working: >> >> A < B is None >> >> returns false if B is not None even if A < B returns None. >> >> Also, in my opinion, the existence is a deterrent to Python and takes >> away from Python's beauty as a language. >> >> The downside of such a change is that the language is more complicated. >> >> As far as implementation goes, this can be done after parsing when the >> AST is checked and errors are raised (from what I remember). >> >> Best, >> >> Neil >> _______________________________________________ >> Python-ideas mailing list -- python-ideas(a)python.org >> To unsubscribe send an email to python-ideas-leave(a)python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/S7NBN… >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >

2 2