Mailman 3 November 2019 - Python-ideas

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

Nov. 22, 2019

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

12 33

Adding CLOCK_TAI to Python
by Russell Owen Nov. 22, 2019

Nov. 22, 2019

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

1 0

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

Nov. 20, 2019

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 Nov. 20, 2019

Nov. 20, 2019

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

10 26

Consider blocking heterogeneous chained comparison
by Neil Girdhar Nov. 19, 2019

Nov. 19, 2019

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

6 5

Improved Function Decorators
by Samuel Muldoon Nov. 19, 2019

Nov. 19, 2019

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

4 3

Differentiate variables form everything else
by tonycstech＠gmail.com Nov. 19, 2019

Nov. 19, 2019

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

5 10

Tuple Comprehension
by Daniel Zeng Nov. 19, 2019

Nov. 19, 2019

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 Nov. 18, 2019

Nov. 18, 2019

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

6 6

Re: Consider blocking heterogeneous chained comparison
by Kyle Stanley Nov. 17, 2019

Nov. 17, 2019

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

2 2