Mailman 3 July 2020 - Python-Dev

Re: PEP 622 version 2 (Structural Pattern Matching)
by Eric Nieuwland 13 Jul '20

13 Jul '20

Rhodri James wrote: > Eric Nieuwland wrote: > >> Just after I hit ‘send’ it dawned on me it might be preferable to make that >> >> match poly: >> p0 = Point(x0, y0) >> p1 = Point(x1, y1) >> p2 = Point(x2, y2) >> case Polygon(p0, p1, p2): >> … >> >> so the part preceded by ‘match’ is the preparation phase for matching. >> > Are you intending p0, p1 and p2 to be subpatterns rather than object instantiations? That makes me a little twitchy; the difference between what you wrote and: > > match poly: > p0 = Point(x0, y0) > p1 = Point(x1, y1) > case Polygon(p0, p1, p2): > ... > is very easy to miss. > You are perfectly right. That is why I prefer explicit marking of variables to be bound by matching. Your example could then become: match poly: p0 = Point(x0, \y0) p1 = Point(\x1, y1) case Polygon(p0, p1, \p2): … and IMHO it would be very clear what to expect. An alternative would be to ‘declare’ variables that are to be bound to make things even more explicit, like: match poly: x1 = to_be_bound_by_matching y0 = to_be_bound_by_matching p2 = to_be_bound_by_matching p0 = Point(x0, y0) p1 = Point(x1, y1) case Polygon(p0, p1, p2): … where a better name than ‘to_be_bound_by_matching’ would certainly be needed. —eric

1 0

Re: Python-Dev Digest, Vol 204, Issue 75
by Federico Salerno 13 Jul '20

13 Jul '20

On 11/07/2020 19:29, Jim J. Jewett wrote: > To me, "else:" has a slightly different meaning than "case _:" case _: > essentially a default, ensuring that the match logic is complete. > else: OK, the subject of this match failed, here is our fallback > logic. Whether this distinction is important enough to express in code > is another question, as is whether or not anyone but me would follow > this "obvious" convention. So I'm not convinced the difference > justifies the existence a second syntax. But I'm also not sure it > doesn't, particularly if that distinction were given in the PEP and in > documentation for the match statement. -jJ Could you construct two examples to prove behaviour would be different between the two? To me the two meanings seem too similar to make a difference in code. On 12/07/2020 00:31, Guido van Rossum wrote: > Hm... Just the fact that people have been arguing both sides so > convincingly makes me worry that something bigger is amiss. I think > we're either better off without `else` (since the indentation of `case > _` cannot be disputed :-), or we have to revisit the reasons for > indenting `case` relative to `match`. As MRAB said, it's a case of > picking the least inelegant one. > > Let me add that the parser can easily deal with whatever we pick -- > this is purely about human factors. That is a good point. I don't think there would be any particular objection to allowing one case to catch anything that wasn't caught before—the issue is with making _ (or any other particular symbol) special for the occasion, or at the very least none of those proposed thus far has been universally accepted. Was anything beside _ and ... proposed? What if case object(): or case any: did that instead? The former is already used to a similar meaning in the context of a match block, the latter would be very obvious to any reader and, since it's already a builtin, few would think shadowing it for use as a store-identifier would be a good idea. On 11/07/2020 21:13, Eric Nieuwland wrote: > This could also resolve the discussion on indentation of the ‘case’ > parts and the placement of the default matching: > match <expression> [as <var>]: <preparation statements> case <pattern> > [<guard>]: <statements> … [else: <statements>] within the preparation > statements it would then be allowed to use undefined variables as > receivers of matched parts. This is intriguing, but I do share Greg Ewing's doubt: what happens if you need no preparation? Personally I'd accept if the line could be omitted altogether, but I understand many others are opposed to having the line following a colon be indented at the same level, and likewise I don't think the idea of having to write pass (or ...) explicitly when no preparation is needed will be well received.

4 3

Re: PEP 622 version 2 (Structural Pattern Matching)
by Eric Nieuwland 13 Jul '20

13 Jul '20

Greg Ewing wrote: > Eric Nieuwland wrote: > >> ... >> match poly: >> p0 = Point(x0, y0) >> p1 = Point(x1, y1) >> p2 = Point(x2, y2) >> case Polygon(p0, p1, p2): >> … >> > > Interesting idea, but what happens if you don't > need any setup? > Do you have to write > > > match poly: > pass > case ... > > ? Yes, that would be the idea. Unless you would need to setup variables to be bound in the cases, of course. Without that an if … elif … elif … else structure would be equivalent and possibly preferable.

1 0

Re: PEP 622 version 2 (Structural Pattern Matching)
by Eric Nieuwland 12 Jul '20

12 Jul '20

Much of the discussion seems to focus on how to distinguish between a variable as a provider of a value and a variable as receiver of a matched value. In normal Python syntax a variable in an expression provides a value, please let’s keep that unchanged. So it seems to me we should explicitly mark a variable to receive a matched value. I have seen ‘?’ suggested as a prefix to do this, ‘\’ would also do fine. This would solve the single variable issue, too: case foo: matches the value of ‘foo’, while case \foo: matches anything and stores it in ‘foo’. This would also mean case Point(x=\x, y=\y): should be used to obtain x and y from the Point instance.

8 14

Re: PEP 622 version 2 (Structural Pattern Matching)
by Federico Salerno 12 Jul '20

12 Jul '20

On 11/07/2020 00:57, Paul Sokolovsky wrote: > The PEP itself in "rejected" ideas makes an argument against it: > indented stuff after a line ending with ":" must be a *statement*. It > would be totally nuts for that to be something else, e.g. an expression: Good point. > That of course leads us to the obvious idea: > match a: case 1: ... case 2: ... else: ... Of course, PEP > smartly has an argument against that too, in the vein of "after line > ending with ':', there should be an indent suite (list of > statements)". But that's where it goes sideways. Exactly. I think not identing what comes after match a: comes with far more advantages than disadvantages. In fact, if the only "real" issue is that anything after : must be indented, I'd say it is vastly outweighed by the issues not doing it would solve. Would the parser allow us to write the above without the colon, thus avoiding the aforementioned objection? > And if the above snippet looks weird to anybody, it's only because of > all the "case" business. There wouldn't be such a problem if it was > instead: match a: | 1: ... | 2: ... |: ... The above > ML-like syntax should be perfect for almost everyone, ... except the > PEP authors, because they have it in "rejected ideas" either. I don't know, that doesn't look very pythonic based on the preference Python makes for words over symbols. I don't think there's any problem with using case, it's the expectations many have for what should come around it that creates issues. On 11/07/2020 12:49, Greg Ewing wrote: > I can't think of one at the moment, but I don't think you > should dismiss tradition so easily. I don't mean to dismiss it, but I wouldn't want it to get in the way of a change if there are good reasons to go against tradition. This seems like one of these cases to me. > One of the arguments used > to justify significant indentation in Python is that "you're > going to indent it for readability anyway, so the compiler > might as well take notice of it". > > For the most part, Python indentation follows what people > would naturally do even if they didn't have to. So I think it's > worth looking at what people typically do in other languages > that don't have mandatory indentation. > > [...] > > or like this: > > switch (x) { > case 1: > ... > case 2: > ... > default: > ... > } > > This suggests to me that most people think of the cases as being > subordinate to the switch, and the default being on the same level > as the other cases. I think that last one would be perceived as ok if it weren't for the brackets: everyone naturally indents any set of brackets' contents. I wouldn't normally mind cases being indented extra relative to "match" if not for two points: 1. Python relies heavily on indentation. It's likely for a match block to appear in a place that is already well indented, *and* it is also likely to often include further levels of indentation. It would be preferable not to require two levels at a minimum every time a match block is needed. 2. Unless the default case is signalled with an ad-hoc keyword like default (which I personally would like), it seems a wildcard symbol like the controversial _ is needed to pair with case. Going against tradition and setting only one indentation level would solve this issue, while still allowing (I think) any programmer to indent the default case extra if they so wish. If none of this is convincing, I do believe the matter is easier than it appears, because few would be confused by else being at the same level as each other case. Alternatively, what if (gasp!) both were allowed as synonyms? I'm sure one of the two would eventually settle as conventional, and there is no possible ambiguity. I know it goes against the "one obvious way to do it" precept but it's clear that there is no obvious way here at all, so, ¿porque no los dos?

2 1

Summary of Python tracker Issues
by Python tracker 11 Jul '20

11 Jul '20

ACTIVITY SUMMARY (2020-07-03 - 2020-07-10) 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 7530 (+10) closed 45482 (+58) total 53012 (+68) Open issues with patches: 3058 Issues opened (41) ================== #39542: Cleanup object.h header https://bugs.python.org/issue39542 reopened by rhettinger #41194: Python 3.9.0b3 crash on compile() in PyAST_Check() when the _a https://bugs.python.org/issue41194 reopened by arcivanov #41203: Replace references to OS X in documentation with macOS https://bugs.python.org/issue41203 opened by pxeger #41205: Documentation Decimal power 0 to the 0 is Nan (versus 0 to the https://bugs.python.org/issue41205 opened by JD-Veiga #41209: Scripts Folder is Empty https://bugs.python.org/issue41209 opened by Jamesss04 #41210: LZMADecompressor.decompress(FORMAT_RAW) truncate output when i https://bugs.python.org/issue41210 opened by miurahr #41212: Emoji Unicode failing in standard release of Python 3.8.3 / tk https://bugs.python.org/issue41212 opened by Ben Griffin #41214: -O0: Segmentation fault in _PyArg_UnpackStack https://bugs.python.org/issue41214 opened by Vincent LE GARREC #41217: Obsolete note for default asyncio event loop on Windows https://bugs.python.org/issue41217 opened by waszil #41219: Mimetypes doesn't support audio/webm https://bugs.python.org/issue41219 opened by cere blanco #41220: add optional make_key argument to lru_cache https://bugs.python.org/issue41220 opened by Itayazolay #41221: io.TextIOWrapper ignores silently partial write if buffer is u https://bugs.python.org/issue41221 opened by mjacob #41222: Undocumented behaviour change of POpen.stdout.readine with buf https://bugs.python.org/issue41222 opened by yann #41223: `object`-backed `memoryview`'s `tolist` errors https://bugs.python.org/issue41223 opened by jakirkham #41226: Supporting `strides` in `memoryview.cast` https://bugs.python.org/issue41226 opened by jakirkham #41228: Fix the typo in the description of calendar.monthcalendar(year https://bugs.python.org/issue41228 opened by ndini #41229: Asynchronous generator memory leak https://bugs.python.org/issue41229 opened by zkonge #41231: Type annotations lost when using wraps by default https://bugs.python.org/issue41231 opened by David Caro #41232: Python `functools.wraps` doesn't deal with defaults correctly https://bugs.python.org/issue41232 opened by Thor Whalen2 #41233: Missing links to errnos on Built-in Exceptions page https://bugs.python.org/issue41233 opened by yyyyyyyan #41234: Remove symbol.sym_name https://bugs.python.org/issue41234 opened by nanjekyejoannah #41236: "about" button in MacOS caused an error https://bugs.python.org/issue41236 opened by Baozhen Chen #41238: Python 3 shelve.DbfilenameShelf is generating 164 times larger https://bugs.python.org/issue41238 opened by Paweł Miech #41241: Unnecessary Type casting in 'if condition' https://bugs.python.org/issue41241 opened by ys19991 #41245: cmath module documentation is misleading on branch cuts https://bugs.python.org/issue41245 opened by mark.dickinson #41246: IOCP Proactor same socket overlapped callbacks https://bugs.python.org/issue41246 opened by tontinton #41248: Python manual forced in maximized window https://bugs.python.org/issue41248 opened by Mischiew Rithe #41249: TypedDict inheritance doesn't work with get_type_hints and pos https://bugs.python.org/issue41249 opened by keithblaha #41253: unittest -h shows a flag -s but it doesn't work https://bugs.python.org/issue41253 opened by Faris Chugthai #41254: Add to/from string methods to datetime.timedelta https://bugs.python.org/issue41254 opened by tebeka #41255: Argparse.parse_args exits on unrecognized option with exit_on_ https://bugs.python.org/issue41255 opened by mhughes #41256: activate script created by venv is not smart enough https://bugs.python.org/issue41256 opened by kunaltyagi #41257: mimetypes.guess_extension('video/x-matroska') return wrong val https://bugs.python.org/issue41257 opened by Saber Hayati #41259: Find adverbs is not correct on the documentation https://bugs.python.org/issue41259 opened by Rim Chatti #41260: datetime: strftime method takes different keyword argument: fm https://bugs.python.org/issue41260 opened by Anthony Sottile #41261: 3.9-dev SEGV in object_recursive_isinstance in ast.literal_eva https://bugs.python.org/issue41261 opened by arcivanov #41262: Convert memoryview to Argument Clinic https://bugs.python.org/issue41262 opened by serhiy.storchaka #41265: lzma/bz2 module: inefficient buffer growth algorithm https://bugs.python.org/issue41265 opened by malin #41266: Wrong hint when class methods and builtins named same https://bugs.python.org/issue41266 opened by wyz23x2 #41268: 3.9-dev regression? TypeError: exec_module() missing 1 require https://bugs.python.org/issue41268 opened by hugovk #41270: NamedTemporaryFile is not its own iterator. https://bugs.python.org/issue41270 opened by xzy3 Most recent 15 issues with no replies (15) ========================================== #41270: NamedTemporaryFile is not its own iterator. https://bugs.python.org/issue41270 #41268: 3.9-dev regression? TypeError: exec_module() missing 1 require https://bugs.python.org/issue41268 #41266: Wrong hint when class methods and builtins named same https://bugs.python.org/issue41266 #41265: lzma/bz2 module: inefficient buffer growth algorithm https://bugs.python.org/issue41265 #41262: Convert memoryview to Argument Clinic https://bugs.python.org/issue41262 #41257: mimetypes.guess_extension('video/x-matroska') return wrong val https://bugs.python.org/issue41257 #41256: activate script created by venv is not smart enough https://bugs.python.org/issue41256 #41249: TypedDict inheritance doesn't work with get_type_hints and pos https://bugs.python.org/issue41249 #41248: Python manual forced in maximized window https://bugs.python.org/issue41248 #41246: IOCP Proactor same socket overlapped callbacks https://bugs.python.org/issue41246 #41241: Unnecessary Type casting in 'if condition' https://bugs.python.org/issue41241 #41234: Remove symbol.sym_name https://bugs.python.org/issue41234 #41233: Missing links to errnos on Built-in Exceptions page https://bugs.python.org/issue41233 #41229: Asynchronous generator memory leak https://bugs.python.org/issue41229 #41228: Fix the typo in the description of calendar.monthcalendar(year https://bugs.python.org/issue41228 Most recent 15 issues waiting for review (15) ============================================= #41270: NamedTemporaryFile is not its own iterator. https://bugs.python.org/issue41270 #41262: Convert memoryview to Argument Clinic https://bugs.python.org/issue41262 #41259: Find adverbs is not correct on the documentation https://bugs.python.org/issue41259 #41255: Argparse.parse_args exits on unrecognized option with exit_on_ https://bugs.python.org/issue41255 #41246: IOCP Proactor same socket overlapped callbacks https://bugs.python.org/issue41246 #41241: Unnecessary Type casting in 'if condition' https://bugs.python.org/issue41241 #41234: Remove symbol.sym_name https://bugs.python.org/issue41234 #41233: Missing links to errnos on Built-in Exceptions page https://bugs.python.org/issue41233 #41232: Python `functools.wraps` doesn't deal with defaults correctly https://bugs.python.org/issue41232 #41231: Type annotations lost when using wraps by default https://bugs.python.org/issue41231 #41220: add optional make_key argument to lru_cache https://bugs.python.org/issue41220 #41219: Mimetypes doesn't support audio/webm https://bugs.python.org/issue41219 #41217: Obsolete note for default asyncio event loop on Windows https://bugs.python.org/issue41217 #41210: LZMADecompressor.decompress(FORMAT_RAW) truncate output when i https://bugs.python.org/issue41210 #41205: Documentation Decimal power 0 to the 0 is Nan (versus 0 to the https://bugs.python.org/issue41205 Top 10 most discussed issues (10) ================================= #26205: Better specify number of nested scopes https://bugs.python.org/issue26205 14 msgs #41177: ConvertingList and ConvertingTuple lack iterators and Converti https://bugs.python.org/issue41177 7 msgs #41202: Allow to provide custom exception handler to asyncio.run() https://bugs.python.org/issue41202 7 msgs #41221: io.TextIOWrapper ignores silently partial write if buffer is u https://bugs.python.org/issue41221 7 msgs #40360: Deprecate lib2to3 (and 2to3) for future removal https://bugs.python.org/issue40360 6 msgs #41255: Argparse.parse_args exits on unrecognized option with exit_on_ https://bugs.python.org/issue41255 6 msgs #40170: [C API] Make PyTypeObject structure an opaque structure in the https://bugs.python.org/issue40170 5 msgs #41205: Documentation Decimal power 0 to the 0 is Nan (versus 0 to the https://bugs.python.org/issue41205 5 msgs #41210: LZMADecompressor.decompress(FORMAT_RAW) truncate output when i https://bugs.python.org/issue41210 5 msgs #41220: add optional make_key argument to lru_cache https://bugs.python.org/issue41220 5 msgs Issues closed (57) ================== #13554: Tkinter doesn't use higher resolution app icon https://bugs.python.org/issue13554 closed by terry.reedy #20257: test_socket fails if using tipc module and SELinux enabled https://bugs.python.org/issue20257 closed by christian.heimes #20353: Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10. https://bugs.python.org/issue20353 closed by terry.reedy #21333: Document recommended exception for objects that shouldn't be p https://bugs.python.org/issue21333 closed by terry.reedy #23885: urllib.quote horribly mishandles unicode as second parameter https://bugs.python.org/issue23885 closed by terry.reedy #24163: shutil.copystat fails when attribute security.selinux is prese https://bugs.python.org/issue24163 closed by christian.heimes #24670: os.chdir breaks result of os.path.abspath(__file__) and os.pat https://bugs.python.org/issue24670 closed by terry.reedy #26212: Python with ncurses6.0 will not load _curses module on Solaris https://bugs.python.org/issue26212 closed by terry.reedy #26328: shutil._copyxattr() function shouldn't fail if setting securit https://bugs.python.org/issue26328 closed by christian.heimes #27154: Regression in file.writelines behavior https://bugs.python.org/issue27154 closed by terry.reedy #28681: Clarify multiple function names in the tutorial https://bugs.python.org/issue28681 closed by terry.reedy #29727: collections.abc.Reversible doesn't fully support the reversing https://bugs.python.org/issue29727 closed by pablogsal #33864: collections.abc.ByteString does not register memoryview https://bugs.python.org/issue33864 closed by gvanrossum #35350: importing "ctypes" immediately causes a segmentation fault https://bugs.python.org/issue35350 closed by christian.heimes #37765: IDLE: Include keywords in module-level autocomplete list https://bugs.python.org/issue37765 closed by terry.reedy #39168: Generic type subscription is a huge toll on Python performance https://bugs.python.org/issue39168 closed by gvanrossum #39417: Link to "Python Packaging User Guide: Creating and using virtu https://bugs.python.org/issue39417 closed by Mariatta #39960: Using typename.__setattr__ in extension type with Py_TPFLAGS_H https://bugs.python.org/issue39960 closed by scoder #40597: generated email message exceeds RFC-mandated limit of 998 char https://bugs.python.org/issue40597 closed by maxking #40742: Doc: Parallel build break audit table https://bugs.python.org/issue40742 closed by mdk #40832: hi param in bisect module should not accept negative values https://bugs.python.org/issue40832 closed by rhettinger #41014: warning: 'sqlite3_trace' is deprecated https://bugs.python.org/issue41014 closed by ronaldoussoren #41018: warning: 'Tk_MainWindow' is deprecated: first deprecated https://bugs.python.org/issue41018 closed by ronaldoussoren #41075: Make support of navigating through prev. commands in IDLE more https://bugs.python.org/issue41075 closed by wyz23x2 #41172: test_peg_generator C tests fail on Windows ARM https://bugs.python.org/issue41172 closed by steve.dower #41173: Windows ARM buildbots cannot upload results https://bugs.python.org/issue41173 closed by steve.dower #41198: Round built-in function not shows zeros acording significant f https://bugs.python.org/issue41198 closed by mark.dickinson #41199: Docstring convention not followed for dataclasses documentatio https://bugs.python.org/issue41199 closed by eric.smith #41204: Use of unitialized variable `fields` along error path in code https://bugs.python.org/issue41204 closed by vstinner #41206: behaviour change with EmailMessage.set_content https://bugs.python.org/issue41206 closed by maxking #41207: distutils.command.build_ext raises FileNotFoundError https://bugs.python.org/issue41207 closed by vstinner #41208: An exploitable segmentation fault in marshal module https://bugs.python.org/issue41208 closed by serhiy.storchaka #41211: PyLong_FromUnicodeObject document is wrong https://bugs.python.org/issue41211 closed by inada.naoki #41213: Cannot locate MSBuild.exe on PATH or as MSBUILD variable https://bugs.python.org/issue41213 closed by Amen8 #41215: AIX: build fails for xlc/xlC since new PEG parser https://bugs.python.org/issue41215 closed by pablogsal #41216: eval don't load local variable in dict and list comprehensions https://bugs.python.org/issue41216 closed by eric.smith #41218: PyCF_ALLOW_TOP_LEVEL_AWAIT + list comprehension set .CO_COROUT https://bugs.python.org/issue41218 closed by pablogsal #41224: Document is_annotate() in symtable and update doc strings https://bugs.python.org/issue41224 closed by nanjekyejoannah #41225: Add a test for get_id() in the symtable module https://bugs.python.org/issue41225 closed by nanjekyejoannah #41227: minor typo in asyncio transport protocol https://bugs.python.org/issue41227 closed by xtreak #41230: IDLE intellisense https://bugs.python.org/issue41230 closed by terry.reedy #41235: Incorrect error handling in SSLContext.load_dh_params() https://bugs.python.org/issue41235 closed by benjamin.peterson #41237: Access violation in python39.dll!meth_dealloc on exit https://bugs.python.org/issue41237 closed by cgohlke #41239: SSL Certificate verify failed in Python3.6/3.7 https://bugs.python.org/issue41239 closed by christian.heimes #41240: Use the same kind of quotation mark in f-string https://bugs.python.org/issue41240 closed by eric.smith #41242: When concating strings, I think it is better to use += than jo https://bugs.python.org/issue41242 closed by asvetlov #41243: SPAM https://bugs.python.org/issue41243 closed by steven.daprano #41244: Change to use str.join() instead of += when concatenating stri https://bugs.python.org/issue41244 closed by zach.ware #41247: asyncio.set_running_loop() cache running loop holder https://bugs.python.org/issue41247 closed by yselivanov #41250: Number separators in different places https://bugs.python.org/issue41250 closed by rhettinger #41251: __future__.barry_as_FLUFL.getMandatoryRelease() is wrong https://bugs.python.org/issue41251 closed by christian.heimes #41252: Incorrect reference counting in _ssl.c's _servername_callback( https://bugs.python.org/issue41252 closed by christian.heimes #41258: CVE-2020-14422 https://bugs.python.org/issue41258 closed by vstinner #41263: Convert code.__new__ to Argument Clinic https://bugs.python.org/issue41263 closed by serhiy.storchaka #41264: Do not use the name of the built-in function as a variable. https://bugs.python.org/issue41264 closed by serhiy.storchaka #41267: Attribute error: Pandas module doesn't have 'Plotting' attribu https://bugs.python.org/issue41267 closed by eric.smith #41269: Wrong subtraction calculations https://bugs.python.org/issue41269 closed by mark.dickinson

1 0

Re: PEP 622 version 2 (Structural Pattern Matching)
by Eric Nieuwland 10 Jul '20

10 Jul '20

> On 10 Jul 2020, Stefano Borini <stefano.borini(a)gmail.com> wrote: > > Just my 2 cents, I find it kind of annoying that the whole structure > requires two levels of indentation to actually reach the operational > code. > This would be a first in python. > > I would prefer an option akin to if elif elif else where each block is > only one level deep. It very much depends on how you read it. To me the proposed structure is like with <expression> as <container>: if <container> <match-op> <pattern>: … elif <container> <match-op> <pattern>: … and thus not really different

1 0

Re: PEP 622 version 2 (Structural Pattern Matching)
by Federico Salerno 09 Jul '20

09 Jul '20

On 08/07/2020 12:30, Rhodri James wrote: > Any name used as a pattern is a catch-all. The only difference > between "case dummy:" and "case _:" is that "_" doesn't bind to the > thing being matched, but "dummy" does bind to it. I meant catch-all as in "case _:" (or "else:"). I apologise for the lack of clarity. On 08/07/2020 17:02, Guido van Rossum wrote: > There’s one other issue where in the end we could be convinced to > compromise: whether to add an `else` clause in addition to `case > _`. In fact, we probably would already have added it, except for one > detail: it’s unclear whether the `else` should be aligned with `case` > or `match`. If we are to add this we would have to ask the Steering > Council to decide for us, as the authors deadlocked on this question. Thanks for the write-up. What were the arguments in support of aligning else with case? I expect it has to be with aesthetics, but for what concerns semantics, it seems to me that "match...else", interpreted as "no match was found" would make the most sense; aligning it with case would look like the else has to do with whatever case was last. Unless both match and all cases are on the same indentation level. Here an example: match: variable case "some constant": # ... case x if x == guard_clause: # ... else: # ... I know at least Elm indents the match variable on a separate line. On 08/07/2020 19:44, Tim Peters wrote: > One microscopic point: > > [Guido] >> ... >> (if `.x` is unacceptable, it’s unclear why `^x` would be any >> better), > As Python's self-appointed spokesperson for the elderly, there's one > very clear difference: a leading "." is - literally - one microscopic > point, all but invisible. A leading caret is far easier to see, on a > variety of devices and using a variety of fonts. Indeed, I missed the > leading dot in ".x" in your email the first two times I read that > sentence. > > But a caret is harder to type. So here's an off-the-wall idea: use > an ellipsis. If you're still using a maximal-munch lexer, ellipsis > followed by an identifier is currently a syntax error. "...x" is far > easier to see than ".x', easier to type than "^x", and retains the > mnemonic connection that "something is a named load pattern if and > only if it has dots". +1 on a simple dot being hard to see. Alternative idea: if we really ought to have a mark for references¹, why not use the & symbol, which already signifies something like "reference" in C(++) and Rust? ¹: I know marking "store" instead of "load" has been suggested before; I'm still on the fence on which I prefer but I would even accept marking both (with = and == respectively, for example).

1 0

Request for code review
by Mark Shannon 09 Jul '20

09 Jul '20

Hi, Would someone be kind enough to review https://github.com/python/cpython/pull/20803, please? It cleans up tracking and introspection of frame state. Cheers, Mark.

1 0

PEP 622 (match statement) playground
by Guido van Rossum 09 Jul '20

09 Jul '20

If you are interested in learning more about how PEP 622 would work in practice, but don't feel like compiling a Python 3.10 fork from source, here's good news for you. In a hurry? https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playgro… This will open a Binder instance that runs a Jupyter kernel built from Brandt Bucher's fork of Python 3.10 that includes the match statement. This is a complete implementation of the PEP. (Note that we've already made some design changes in response to feedback, but the basic syntax is still the same. Expect a new draft within a week.) The code for the playground was contributed by Fernando Perez, Matthias Bussonnier and Chris Holdgraf. We also thank the Binder and Jupyter teams for Binder and Jupyter and all the infrastructure that made this playground possible, and we thank gesis.org for hosting. For details, see https://github.com/gvanrossum/patma/tree/master/binder -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>

27 55