Mailman 3 December 2019 - Python-ideas

Suggestion for language addition
by Jan Bakuwel Jan. 23, 2020

Jan. 23, 2020

Hi folks, I have a few decades of experience with software engineering using assembler, C, FORTRAN, Pascal, Ada and a fair number of other languages. I've been using Python as well for a number of years now. Both Pascal and Ada have "end" statements, which make the code (at least for me :-) ) a lot more readable and maintainable, especially if the code within if/while/for statements gets longer and nested deeper. These statements exist in these languages for a good reason. I had a look in the archives to see if someone else already proposed this but couldn't find anything, so here goes. Please let me know whether you think this idea is worth to convert to a PEP. thanks, Jan Idea: To include optional "end if", "end while", "end for" and "end <function name>", "end <class name>" in the language. The Python interpreter would test that any "end" matches with the correct corresponding statements and have the correct indentation, in other words throw an error if you would write "end if" where an "end while" should be. This will be a great help preventing errors with procedural logic, that I now have to painstakingly debug at runtime, especially after moving bits of code around. Python editors would ideally highlight "if" and "end if" just like they now highlight "if". By default different colors could be picked for "if" and "end if", "while" and "end while" etc. All this is completely optional of course, so it won't break any existing code. Advantages: - better readability and maintainability - help prevent procedural logic mistakes - editors could use this for improved highlighting of code Disadvantages: - none :-) it's optional, just like the typing that was introduced in Python 3 Code example: def func (i: int, j: int, k: int) -> None: if (i == 3): while (i < 15): i += 1 if (k == 8): lots of other code (think a page or more) lots of other code here is more code <- to which if or while does this belong? and a bit more further code The code could be rewritten like this: def func (i: int, j: int, k: int) -> None: if (i == 3): while (i < 15): i += 1 if (k == 8): lots of other code (think a page or more) lots of other code end if end while (writing "end if" would throw an error at parse time) here is more code and a bit more end if end func further code Looking forward to your feedback! regards, Jan NEW ZEALAND

17 41

Target-and-expression lists and if-try
by Andrew Barnert Jan. 3, 2020

Jan. 3, 2020

Every so often, someone suggests that Python should have a pattern matching case statement like Scala, C#, Swift, Haskell, etc. Or they just suggest that “Python needs algebraic data types” but end up concluding that the biggest part Python is missing is not the types themselves, but a practical way to do something useful with them, which basically means pattern matching. Anyway, with the addition of the walrus operator and @dataclass, Python is actually a lot closer than it used to be. I believe with just two smallish syntax features, it would be possible to do almost anything you’d ever want in a library. The first is to extend unpacking assignment to target-or-expression lists. Like this: x, 0, z = vec Just like `x, y, z = vec`, this raises a TypeError if vec isn’t Iterable, and a ValueError if it has more or fewer than 3 elements, and otherwise, it binds x and z to the first and third elements. But it doesn’t bind anything to the second element; instead, it checks if that element is 0, and, if not, raises a ValueError. The second is an “if try” statement, which tries an expression and runs the body if that doesn’t raise (instead of if it’s truthy), but jumps to the next elif/else/statement (swallowing the exception) if it does. The actual value of the expression is discarded, but the walrus operator takes care of that: if try 0, y, z := vec: # do yz plane stuff elif try x, 0, z := vec: # do xz plane stuff elif try x, y, 0 := vec: # do xy plane stuff elif x, y, z := vec: # do slow/imprecise/whatever 3D stuff else: raise TypeError(f'{vec} is not a 3-vector!') Alternatively, this could just be a try expression that can be used anywhere: it’s truthy if evaluating doesn’t raise, falsey if it does. But I don’t think it’s needed anywhere but if/elif. Anyway, neither of these features seems very useful on its own. (It should be obvious how to rewrite that example as something just as readable that just unpacks and then checks the values with normal if.) But I think the two of them together will allow a pure-library implementation of pattern matching syntax that reads nicely and can do everything most other languages do—in particular, concisely and readably pattern match and deconstruct dataclasses (and other types with an opt-in protocol or registry, but dataclasses would work out of the box the way Scala case classes, Swift structs, etc. do). If people think either of these features is too horrible to contemplate no matter what the potential benefits, I won’t bother working through the details. But if people do want to see the details (including some good motivating examples—I’ll go through tutorials for those other languages to find some that don’t involve recursing into cons lists and other stuff you wouldn’t want to do in Python…), I’ll be happy to do so, and, if it works out, turn this into a more detailed proposal. And obviously, if people want to bikeshed the spelling before even seeing what it’s good for, well, this is Python-ideas. :)

9 28

Allow metaclass to override __subclasscheck__ for metaclass relations
by Soni L. Jan. 1, 2020

Jan. 1, 2020

I would like this code to work, but currently python ignores __subclasscheck__ in many places where it checks for subclasses: class MM(type): def __subclasscheck__(self, subclass): return issubclass(subclass, type) class M(type, metaclass=MM): pass class N(type): pass class C(metaclass=M): pass class D(metaclass=N): pass class E(C, D, metaclass=N): pass def main(): e = E() main()

3 8

more readable "if" for multiple "in" condition
by iman.h.a.khamse＠gmail.com Jan. 1, 2020

Jan. 1, 2020

Hi I think the following syntax's: if foo in foobar or bar in foobar or baz in foobar: pass if foo in foobar and bar in foobar and baz in foobar: pass can be more readable and shorter if written as: if foo or bar or baz in foobar: pass if foo and bar and baz in foobar: pass maybe for "is" instead of: if foobar is foo or foobar is bar or foobar is baz: pass if foobar is foo or bar or baz: pass now the recommended syntax translate to this: (I think so) if foo (IS NOT '0' or None or empty) or bar (IS NOT '0' or None or empty) or baz in foobar so probably we must introduce a new type of 'or' (I recommend the CAPITAL "OR","AND") so this: if foo OR bar OR baz in foobar: pass translates to this: if foo in foobar or bar in foobar or baz in foobar: pass

15 20

`set` API and various sorting problems
by Marco Sulla Dec. 30, 2019

Dec. 30, 2019

Andrew Barnert wrote: > if you’re going to be a pedant, the floats in > whatever Python you’re using right now are probably 854/754-1985 doubles, not 754-2019 > binary64s. Mr. Andrew Barnet, if pedant means adhere to the standard, yes, I'm a pedant. > > This is because NaN, IMHO, it's not the right name > > for the entity. A number can't be Not a Number. It's an Undefined Number. > OK, so you really are arguing against IEEE float here. So now I'm no more a pedant. No, I'm an heretic, because I don't like the Not A Number name but I prefer Undefined Number? A rose with any another name has the same smell. > > But IEEE 754-2019 is written mainly for C and > > Assembly. And you can't return nothing in a comparison between two floats. So they take > > the most practical solution: return false. > > They defined a whole complicated system of signaling vs. quiet nan values and > signaling (on sNaN) vs. non-signaling operations and multiple forms of exception handling > from traps to checkable flags to substitution of default values. You can use much of that > in C (and all of it in assembly) if you want to, even if people usually don’t. Yes, I perfectly know, I read the specs. You forgot the payload. Thank you for confirming what I said. > Also, who says you can’t return nothing in a comparison between two floats? You can > write a named function that has any API you want (say, it returns -1, 0, 1, or NaN, or > even an enum of less, greater, equal, left nan, right nan, both nan, other incomparable) > instead of a Boolean function that has to return true or false. First, C and assembly has no boolean type. And I can write whatever I want, but IEEE 754-2019 clearly says that every comparison with NaN must return false, that is zero in C. > But the fact that C (and countless other languages, including Python) also provides the > operators and people use them extensively implies that many people don’t think the > operators are useless, even if you do. I never said the operators are useless. Can you quote please? > > This obviously does not apply to total ordering. Even > > if I think mathematically has no sense, IEEE 754 clearly defined a total ordering, also > > for NaNs. So a total_ordering() key function, passed to sort functions, should order as > > IEEE 754 declares, without raising exceptions. There's a bug opened somewhere about this > > key function. > > This is what I've done. Unluckily, the API now works this way. It's not a big problem > > anyway. You have only to pass as key to the sort function: > > def sortNans(x): > > try: > > if math.isnan(x): > > return float("+inf") > > except TypeError > > pass > > > > return x > > > But this isn’t the same thing that IEEE totalOrder defines. I clearly stated that the key function total_order() is being developed, that there's a bug opened by Tim Peters and that what I wrote has nothing to do with total ordering. Can you please read my post with more attention? It's a bit frustrating to explain the things two times, and it's not respectful for who writes.

3 3

AVG Function as Built-in
by Kemal Diri Dec. 30, 2019

Dec. 30, 2019

Hello, I think it would be nice to introduce an avg method for lists as a built-in function in python3. To get average of the list, I need to use some libs (eg numpy). In my opinion, if I can get sum of the list, I should get avg also in a same way. For ex [python3]: >>> l = [5, 9, 7,] ... ... import numpy as np ... print(np.mean(l)) 7.0 >>> sum(l) / len(l) 7.0 >>> avg(l) Traceback (most recent call last): File "<input>", line 1, in <module> NameError: name 'avg' is not defined Cordialement/Regards Kemal DIRI

23 183

Giving Loops names
by Oskar Promeuschel Dec. 30, 2019

Dec. 30, 2019

Hello, I was thinking about giving loops names. And It would be interesting if through this name in a continue or break statement could be called. A little example what I mean: loop "outloop" while True: actmonth = datetime.datetime.now().month loop "innerloop" for i in range(0, int(input())): if datetime.datetime.now().month != actmonth: break "outloop" else: print("Waiting for a new Month...") # Do some stuff if loop ended before new Month Without giving names it's always needed to define a new variable and a if statement outside of the innerloop, like this: while True: actmonth = datetime.datetime.now().month shouldend = False for i in range(0, int(input())): if datetime.datetime.now().month != actmonth: shouldend = True break else: print("Waiting for a new Month...") if shouldend: break # Do some stuff if loop ended before new Month It's possible without it, but it is more readable. Maybe another option is, but that's too deep, to make loops to objects. Best Regards, Oskar Promeuschel

2 1

Total_order
by David Mertz Dec. 30, 2019

Dec. 30, 2019

In the IEEE total order, +0 and -0 are distinct, which your order doesn't handle, For NaNs, the issue is that NaN is NOT a single representation, but each combination of the sign bit and the 52 mantissa bits (except all zeros which signify infinity) when the exponent field is all ones is a different NaN (and the MSB of the mantissa indicates quiet or signalling). you code makes all these values unordered with respect to each other as opposed to having a distinct strict order. That probably isn't that important of a distinction. Ok. Fair enough. My 3-line version puts all the NaNs in whatever order they started out in in the list. Well, positive and negative get separated properly. I could add one more line to deal with the +/- zeros, but it's the same idea of making a tuple where the first element sorts first (maybe -0.5 / 0.5, or make the NaNs +/-2, whatever). The thing is that there's no *Python* way (other than the struct module) to get NaNs with any particular bits. I have no control over which bits I'll get with `float('nan')` or `math.nan` or `1e1000-1e999`. But if we actually want those bits I don't control ordered, we have to do it Tim's way... I get it now. Has anyone actually ever used those available bits for the zillions of NaNs for anything good? > IEEE total_order puts NaN as bigger than infinity, and -NaN as > > less than -inf. > > > > You mean like this? > > > > >>> def total_order(x): > > ... if math.isnan(x): > > ... return (math.copysign(1, x), x) > > ... return (0, x) > > ... > > ... > > >>> nums = [1, 2, float('-inf'), float('nan'), float('inf'), > float('-nan')] > > >>> nums > > [1, 2, -inf, nan, inf, nan] > > >>> sorted(nums, key=total_order) > > [nan, -inf, 1, 2, inf, nan] > > >

6 7

The "When" Keyword
by Abdur-Rahmaan Janhangeer Dec. 29, 2019

Dec. 29, 2019

Greetings list, I was wondering if adding the When keyword is a good idea. Normally every when is theoretically an if as you can't be sure if the event will 100% come to pass. if x == 5: ... else: ... However, we use the when keyword in normal language. When you reach home, phone me. When you pass this avenue, turn right etc. Using it in programming might convey the intent of the programmer. when x == 5: ... else: ... which still sells the idea of maybe if but hints away the expectation of the author. Yours, Abdur-Rahmaan Janhangeer pythonmembers.club <http://www.pythonmembers.club/> | github <https://github.com/Abdur-rahmaanJ> Mauritius

6 8

findfirst() from findalliter(), and first
by Juancarlo Añez Dec. 29, 2019

Dec. 29, 2019

These are the implementations I added to my library: ```python def findalliter(pattern, string, flags=0): ''' like finditer(), but with return values like findall() implementation taken from cpython/Modules/_sre.c/findall() ''' for m in re.finditer(pattern, string, flags=flags): g = m.groups() if len(g) == 1: yield g[0] elif g: yield g else: yield m.group() def findfirst(pattern, string, flags=0, default=_undefined): """ Avoids using the inefficient findall(...)[0], or first(findall(...)) """ return first(findalliter(pattern, string, flags=flags), default=default) ``` Fon *first()*, maybe calling it *take_one()* will clear up misunderstandings about it's semantics. -- Juancarlo *Añez*

3 5