Mailman 3 July 2020 - Python-Dev

PEP 622 idea: "match case object" to represent match patterns
by Federico Salerno July 18, 2020

July 18, 2020

Recent discussion on the store vs. load syntax issues of PEP 622 prompted a (yet unripe) idea that could hopefully spur some progress. What if cases required some sort of MatchCase (name pending) object which could be preconstructed by the user if needed, but also inferred on the fly if absent? I think an example would clarify what I mean. Consider the following block (with & to mark "load" just for demonstration purposes): match some_point: case Point(x, y, _) if … [View More]x > y: print(f"Tridimensional point with x > y") case Point(_, _, _): print("Some other 3D point.") case Point(_, &my_y) as pt: print(f"{pt} has y=={my_y}.") case Point(10, _): print("Some bidimensional point with x==10.") case Point(_, y): print(f"Bidimensional point with {y=}.") case _: print("Something else.") This is admittedly simple enough that it wouldn't require what I'm about to show, but it does require marking my_y in some way to prevent it from being interpreted as a "store" identifier, or to namespace it for the same reason. Now consider the following refactor: 3d_point = MatchCase("Point(x, y, z)") other_3d_point = MatchCase("Point(_, _, _)") point_with_my_y = MatchCase("Point(_, {})", my_y) # syntax with {} is debatable. other_2d_point = MatchCase("Point(_, y)") match some_point: case 3d_point if 3d_point[0] > 3d_point[1]: # 3d_point exposes x, y, and zwith the names given # in the declaration, as well as numerically, # through __getitem__ or perhaps also through attributes # like .args and .kwargs. ... case other_3d_point: # other_3d_point[0] through [2] are available, while # other_3d_point["_"] == other_3d_point[2] because it's the last # one that was given. Presumably the programmer wouldn't care about it. ... case point_with_my_y as pt: # pt still exposes positional arguments like pt[0], pt[1] or pt.args # as well as pt["_"] (== pt[0] in this case), but pt[1] has no # equivalent in pt.kwargs because no name was given. ... case Point(10, _): # Python would construct its own MatchCase here and behave as expected. ... case other_2d_point: print(f"Bidimensional point with y={other_2d_point['y']}.") case _: ... Every case above could be constructed in the same way as in the example without MatchCase, except for point_with_my_y, which contains a lookup: every identifier inside the match is interpreted as "store" unless it's namespaced; the others are included for demonstration purposes. As seen in case Point(10, _), patterns that contain no "load" identifiers can be written without using MatchCase instances. In effect, its usage would be a sort of "plug-in" for when complex or verbose functionality is needed, allowing to load identifiers or encode patterns for readability and/or reuse through the match block. The value of the identifiers to load would be read at MatchCase instantiation and internally converted to a constant value. Guard clauses could optionally be included in the MatchCase instantiation. If both it and the case: provide guards, they are anded together. If deemed appropriate, a special meaning could be given to MatchCase() (no arguments, or with "" or even any falsy value as argument) to represent the default case to appease those who don't like _. Note that the above examples assume at least _ (and possibly any identifier) can be repeated. My proposed MatchCase idea is compatible with the possibility of disallowing repeated identifiers, while still allowing them in MatchCase()'s first argument with the behaviour seen in the other_3d_point case. The constructor MatchCase could be either provided as a builtin or in a stdlib module that must be imported. I think the latter would be more reasonable. Any specific syntax or name presented above (MatchCase, the {}s in its first argument, the names of the MatchCase.args and MatchCase.kwargs attributes) is debatable. I hope I haven't missed any important point that would make the above demonstration invalid. Any thoughts? [View Less]

3 4

PEP 622: capturing into an explicit namespace
by Richard Levasseur July 17, 2020

July 17, 2020

Hi Python-dev and PEP 622 Authors, I saw this idea, or something like it, posted by a couple of people, but didn't see much discussion of it, and skimming the PEP today, I didn't see a mention of it. Maybe I just missed it; my apologies if so, and a link to the relevant discussion/text would be appreciated. In any case, the basic idea was to have an explicit namespace that captures are put into, and is treated as assignment instead of lookup. e.g. match get_point() into m: case Point(m.x, … [View More]

2 1

Re: PEP 622: Structural Pattern Matching (version 2)
by Mark Shannon July 17, 2020

July 17, 2020

Hi, As I wrote in an earlier email: > > For a PEP to succeed it needs to show two things. > > 1. Exactly what problem is being solved, or need is to be fulfilled, and that is a sufficiently large problem, or need, to merit the proposed change. > > 2. That the proposed change is the best known solution for the problem being addressed. > > IMO, PEP 622 fails on both counts. > This email addresses point 1 (for version 2). Abstract -------- Why the use of "shape" … [View More]in "scare quotes"? It worries me that the abstract can't explain what PEP 622 does directly. Could you use a real example in the abstract? Using a contrived example like this seems like a straw man. It feels like it is constructed to favour the PEP, whilst being unlike any real code. Rationale and Goals ------------------- > Python programs frequently need to handle data which varies in type, presence of attributes/keys, or number of elements. Typical examples are operating on nodes of a mixed structure like an AST, handling UI events of different types, processing structured input (like structured files or network messages), or “parsing” arguments for a function that can accept different combinations of types and numbers of parameters. AST, and UI objects usually (pretty much always) form a class hierarchy, making is easy to add utility matching methods to the base class. Where matching *might* have some value is when unrelated types are involved, but you need to show that enhanced destructuring would be insufficient. > In fact, the classic 'visitor' pattern is an example of this, done in an OOP style -- but matching makes it much less tedious to write. This might be true of the "classic" visitor pattern, but that's a straw man. The Python visitor pattern is a joy to use. Each case gets its own self contained method, clearly named, which is much better than a giant `match` statement. > Much of the code to do so tends to consist of complex chains of nested if/elif statements, including multiple calls to len(), isinstance() and index/key/attribute access. Inside those branches users sometimes need to destructure the data further to extract the required component values, which may be nested several objects deep. There seem to be three things you want to enhance here: Unpacking; to avoid calls to `len` Type checking; to avoid calls to `isinstance`. To avoiding nesting by using complex lvalues. You fail to justify why the first two cannot be handled separately with much simpler extensions to the language and why complex lvalues are better than nesting. The examples ------------ There are only three examples, none of which are compelling. In fact, two of them serve as a warning against the additional complexity this PEP entails. Django example: ''''''''''''''' Saves two lines of code, but introduces two bugs! (Assuming that the original behavior should be preserved) If the authors of the PEP cannot use this feature correctly in the first example they give, what chance do the rest of us have? is_tuple example: ''''''''''''''''' (Repeating my earlier email) Python's support for OOP provides an alternative to ADTs. For example, by adding a simple "matches" method to Node and Leaf, `is_tuple` can be rewritten as something like: def is_tuple(node): if not isinstance(node, Node): return False return node.matches("(", ")") or node.matches("(", ..., ")") The "switch on http response codes" example. '''''''''''''''''''''''''''''''''''''''''''' This clearly demonstrates the value of symbolic constants for readability and the serious flaw in the PEP that I cannot use them. I really don't see you how you can claim that `case 406:` is more readable than `elif response == HTTP_UPGRADE_REQUIRED:` ? Preventing the use of symbolic constants or other complex rvalues is a impairment to usability. Silently failing when symbolic constants are used is terrible. I do see the value of a `switch` statement for repeated tests against the same value; its intent is clearer than repeated `elif`s. But there is no need for it to be so hard to use. Cheers, Mark. [View Less]

4 4

Summary of Python tracker Issues
by Python tracker July 17, 2020

July 17, 2020

ACTIVITY SUMMARY (2020-07-10 - 2020-07-17) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7550 (+20) closed 45517 (+35) total 53067 (+55) Open issues with patches: 3067 Issues opened (39) ================== #39960: Using typename.__setattr__ in extension type with Py_TPFLAGS_H https://bugs.python.org/issue39960 reopened by gvanrossum #41271: Add … [View More]

1 0

Re: PEP 622 constant value syntax idea
by Eric Nieuwland July 16, 2020

July 16, 2020

> From: Baptiste Carvello <devel2020(a)baptiste-carvello.net> > Subject: [Python-Dev] Re: PEP 622 constant value syntax idea > > What about simply "is", which is already a keyword? > > AFAIK "is" has no meaning as a prefix operator as of now, so hopefully > it would not make the grammar ambiguous (how can one check that for sure?). > > match color: > case is RED: > print("red") > case is BLUE: > print("blue") > case other:… [View More]

1 0

Problems with python and Geany?
by arajgure＠sevenmentor.com July 16, 2020

July 16, 2020

So I have recently purchased a rapsberry pi in hope that it will ease me in to programming and learn a bit more about computing. I was reading an article in pc pro about creating a game using python so thought I would give it a shot. However, when I try to execute on Geany I keep getting the same message : "09:13:05: Failed to execute "C:\Python27\python "raspberry.py"" (start-script could not be created: Failed to create file: Permission denied)" I've been searching google and forums for … [View More]

2 1

I plan to accept PEP 623 "Remove wstr from Unicode" next week
by Victor Stinner July 15, 2020

July 15, 2020

Hi, As the PEP delegate of the PEP 623, I plan to accept PEP 623 "Remove wstr from Unicode" next week. As far as I know, all previous remarks have been taken in account. https://www.python.org/dev/peps/pep-0623/ I worked with INADA-san to adjust his PEP 623 plan: * DeprecationWarning warnings will be emitted as soon as Python 3.10 to help developers detect the deprecation at runtime, rather than only announcing the deprecation with compiler warnings and in the documentation. * Developers … [View More]

2 2

BPO-41182 - Update
by Abhijeet Kasurde July 14, 2020

July 14, 2020

Hi Team, I am waiting for a review on https://github.com/python/cpython/pull/21257. It would be great if someone can take a look at it and move PR forward. Thanks in advance. -- Thanks, Abhijeet Kasurde

1 0

[RELEASE] Python 3.8.4 is now available
by Łukasz Langa July 13, 2020

July 13, 2020

Python 3.8.4 is the fourth maintenance release of Python 3.8. Go get it here: https://www.python.org/downloads/release/python-384/ <https://www.python.org/downloads/release/python-384/> Maintenance releases for the 3.8 series will continue at regular bi-monthly intervals, with 3.8.5 planned for mid-September 2020. What’s new? The Python 3.8 series is the newest feature release of the Python language, and it contains many new features and optimizations. See the “What’s New in Python 3.8 … [View More]

1 0

PEP 622 and fitting the pieces together
by Paul Svensson July 12, 2020

July 12, 2020

Having followed this discussion for a while, I'm trying to put my finger on why I feal uneasy about it. The major features I see in this proposal are: * New syntax for trying multiple assignments until one matches. * Extending destructuring assignment to match constants in the LHS. * Adding syntax to tell constants from targets. * Extending destructuring assignment to match isinstance and properties. * Making _ a special variable that doesn't always gets … [View More]

1 0