[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636
Hi,
first of all, I'm a big fan of the changes being proposed here since in my
code I prefer the 'union' style of logic over the OO style.
I was curious, though, if there are any plans for the match operator to
support async stuff. I'm interested in the problem of waiting on multiple
asyncio tasks concurrently, and having a branch of code execute depending
on the task.
Currently this can be done by using asyncio.wait, looping over the done set
and executing an if-else chain there, but this is quite tiresome. Go has a
select statement (https://tour.golang.org/concurrency/5) that looks like
this:
select {
case <-ch1:
fmt.Println("Received from ch1")
case <-ch2:
fmt.Println("Received from ch2")
}
Speaking personally, this is a Go feature I miss a lot when writing asyncio
code. The syntax is similar to what's being proposed here. Although it
could be a separate thing added later, async match, I guess.
> Message: 2
> Date: Thu, 22 Oct 2020 09:48:54 -0700
> From: Guido van Rossum
> Subject: [Python-Dev] Pattern matching reborn: PEP 622 is dead, long
> live PEP 634, 635, 636
> To: Python-Dev
> Message-ID:
> [email protected]>
> Content-Type: multipart/alternative;
> boundary="39e83905b2453edf"
>
> --39e83905b2453edf
> Content-Type: text/plain; charset="UTF-8"
>
> After the pattern matching discussion died out, we discussed it with the
> Steering Council. Our discussion ended fairly positive, but there were a
> lot of problems with the text. We decided to abandon the old PEP 622 and
> break it up into three parts:
>
> - PEP 634: Specification
> - PEP 635: Motivation and Rationale
> - PEP 636: Tutorial
>
> This turned out to be more work than I had expected (basically we wrote all
> new material) but we've finally made it to a point where we can request
> feedback and submit the new version to the SC for approval.
>
> While the text of the proposal is completely different, there aren't that
> many substantial changes:
>
> - We changed walrus patterns ('v := p') to AS patterns ('p as v').
> - We changed the method of comparison for literals None, False, True to use
> 'is' instead of '=='.
> - SyntaxError if an irrefutable case[1] is followed by another case block.
> - SyntaxError if an irrefutable pattern[1] occurs on the left of '|', e.g.
> 'x | [x]'.
> - We dropped the `@sealed` decorator and everything aimed at static type
> checkers.
>
> [1] An irrefutable pattern is one that never fails, notably a wildcard or a
> capture. An irrefutable case has an irrefutable pattern at the top and no
> guard. Irrefutability is defined recursively, since an '|' with an
> irrefutable pattern on either side is itself irrefutable, and so is an AS
> pattern with an irrefutable pattern before 'as'.
>
> The following issues were specifically discussed with the SC:
>
> - Concerns about side effects and undefined behavior. There's now some
> specific language about this in a few places (giving the compiler freedom
> to optimize), and a section "Side Effects and Undefined Behavior".
>
> - Footgun if `case NAME:` is followed by another case. This is now a
> SyntaxError.
>
> - Adding an 'else' clause. We decided not to add this; motivation in PEP
> 635.
>
> - Alternative 'OR' symbol. Not changed; see PEP 635.
>
> - Alternative wildcard symbol. Not changed, but Thomas wrote PEP 640 which
> proposes '?' as a general assignment target. PEP 635 has some language
> against that idea.
>
> - Alternative indentation schemes. We decided to stick with the original
> proposal; see PEP 635.
>
> - Marking all capture variables with a sigil. We all agreed this was a bad
> idea; see PEP 635.
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/GQP2EXF4EC5FCUJPTRY2CTLNHLWHD5GY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2020-10-16 - 2020-10-23) 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: open7608 (-99) closed 46258 (+176) total 53866 (+77) Open issues with patches: 3059 Issues opened (66) == #2190: MozillaCookieJar ignores HttpOnly cookies https://bugs.python.org/issue2190 reopened by terry.reedy #25655: Python errors related to failures loading DLL's lack informati https://bugs.python.org/issue25655 reopened by steve.dower #33987: IDLE: use ttk.Frame for ttk widgets https://bugs.python.org/issue33987 reopened by terry.reedy #38820: Make Python compatible with OpenSSL 3.0.0 https://bugs.python.org/issue38820 reopened by christian.heimes #40703: PyType_FromSpec*() overwrites the type's "__module__" https://bugs.python.org/issue40703 reopened by petr.viktorin #41950: Typo in Python 3.9 what's new page https://bugs.python.org/issue41950 reopened by gvanrossum #42026: index function return first index for same element if repetiti https://bugs.python.org/issue42026 reopened by chetanpalliwal13 #42054: email message get_content throws KeyError for content main typ https://bugs.python.org/issue42054 opened by msapiro #42058: Process not running with args https://bugs.python.org/issue42058 opened by vbanait #42059: TypedDict(...) as function does not respect "total" when setti https://bugs.python.org/issue42059 opened by alex.gronholm #42060: Usage of assert in http/client.py https://bugs.python.org/issue42060 opened by fbidu #42061: Document __format__ method for IPv[46]Address https://bugs.python.org/issue42061 opened by eric.smith #42062: Usage of HTTPResponse.url https://bugs.python.org/issue42062 opened by fbidu #42063: More options to http.server & SimpleHTTPRequestHandler https://bugs.python.org/issue42063 opened by jacobsorme #42064: Convert sqlite3 to multi-phase initialisation (PEP 489) https://bugs.python.org/issue42064 opened by erlendaasland #42066: CookieJar cookies should not be sorted https://bugs.python.org/issue42066 opened by IKermani #42067: Type annotation in for-loops https://bugs.python.org/issue42067 opened by gaaartner #42068: For macOS, package the included Tcl and Tk frameworks in a rat https://bugs.python.org/issue42068 opened by culler #42070: I think the rationale to keep IsoCalendarDate private from the https://bugs.python.org/issue42070 opened by msimpasona #42073: classmethod does not pass "type/owner" when invoking wrapped _ https://bugs.python.org/issue42073 opened by eriknw #42074: setup error on windows https://bugs.python.org/issue42074 opened by rikkuguzai #42075: Verbose/confusing default format on warnings https://bugs.python.org/issue42075 opened by Mithil #42076: urllib ResourceWarning in case of usage of FTP https://bugs.python.org/issue42076 opened by icegood #42078: _tracemalloc.c and Clang-cl https://bugs.python.org/issue42078 opened by gvanem #42079: Why does tarfile.next swallow InvalidHeaderError https://bugs.python.org/issue42079 opened by jan.schatz #42082: Eliminate test_peg_generator redundant output https://bugs.python.org/issue42082 opened by terry.reedy #42083: PyStructSequence_NewType broken in 3.8 https://bugs.python.org/issue42083 opened by wdi2 #42085: Add dedicated slot for sending values https://bugs.python.org/issue42085 opened by v2m #42086: AST: Document / re-design? the simple constructor nodes from s https://bugs.python.org/issue42086 opened by BTaskaya #42087: Remove pre-AIX 6.1 dead code paths https://bugs.python.org/issue42087 opened by kadler #42088: types.SimpleNamespace.__repr__ documentation inconsistency https://bugs.python.org/issue42088 opened by avrahami.ben #42090: zipfile.Path.joinpath API inconsistent with pathlib.Path.joinp https://bugs.python.org/issue42090 opened by conchylicultor #42091: strftime returns empty string for -d, -I 3.8.3 https://bugs.python.org/issue42091 opened by PMARINA #42092: test_host_resolution_bad_address does not always fail as expec https://bugs.python.org/issue42092 opened by barry #42094: isoformat() / fromisoformat() for datetime.timedelta https://bugs.python.org/issue42094 opened by Erik Cederstrand #42095: plistlib: Add tests that compare with plutil(1) https://bugs.python.org/issue42095 opened by ronaldoussoren #42096: zipfile.is_zipfile incorrectly identifying a gzipped file as a https://bugs.python.org/issue42096 opened by aroussel #42097: Python 3.7.9 logging/threading/fork hang https://bugs.python.org/issue42097 opened by Adq #42098: Test suite should verify auditing events get triggered https://bugs.python.org/issue42098 opened by akuchling #42099: Fix reference to ob_type in unionobject.c and ceval https://bugs.python.org/issue42099 opened by nascheme #42100: Add _PyType_GetModuleByDef https://bugs.python.org/issue42100 opened by petr.viktorin #4210
[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636
On Fri, Oct 23, 2020 at 6:19 AM Tin Tvrtković wrote:
> Hi,
>
> first of all, I'm a big fan of the changes being proposed here since in my
> code I prefer the 'union' style of logic over the OO style.
>
> I was curious, though, if there are any plans for the match operator to
> support async stuff. I'm interested in the problem of waiting on multiple
> asyncio tasks concurrently, and having a branch of code execute depending
> on the task.
>
> Currently this can be done by using asyncio.wait, looping over the done
> set and executing an if-else chain there, but this is quite tiresome. Go
> has a select statement (https://tour.golang.org/concurrency/5) that looks
> like this:
>
> select {
> case <-ch1:
> fmt.Println("Received from ch1")
> case <-ch2:
> fmt.Println("Received from ch2")
> }
>
> Speaking personally, this is a Go feature I miss a lot when writing
> asyncio code. The syntax is similar to what's being proposed here. Although
> it could be a separate thing added later, async match, I guess.
>
Hadn't seen this before. You could propose this as a follow-up for 3.11.
But aren't Go channels more like asyncio Queues? I guess we'd need way more
in terms of a worked-out example (using asyncio code, not Go code).
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
[Python-Dev] fail keyword like there is pass keyword
Hello Can I suggest a feature to discuss and hopefully develop and send a PR. I think having a *fail* keyword for unit testing would be great. So we write a test as follows which will fail to begin with. class MyTest(unittest.TestCase): def test_this_and_that(self): """ Given inputs When action is done Then it should pass """ fail This keyword is to fill an empty function block like *pass* but this will make the function raise an exception that test is failing. I know there is *raise* but I feel this *fail* keyword is needed to write a test first which fails and then write code and then come back to the test and fill its body. Umair -- ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/QPOVO34K63CLEY66GSY5JOLWBRG5QRUM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: fail keyword like there is pass keyword
I do not understand how a simple raise is worse than this. A simple variable
holding some standard error (like test not implemented error) should be no
different. (like fail = NotImplementedError("Test has not been implemented yet")
I feel like this is a useless syntactic sugar but if you give some real-world
examples that could be significantly improved with this keyword, many people
here could support it.___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/LDD6DRFNVCXFQJU3AMDAX4MPCNIOMOIF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: fail keyword like there is pass keyword
On 10/23/20 11:52 AM, Umair Ashraf wrote: Hello Howdy! Can I suggest a feature to discuss and hopefully develop and send a PR. You can, but the place to do it is Python Ideas: https://mail.python.org/mailman3/lists/python-ideas.python.org/ [email protected] I think having a *fail* keyword for unit testing would be great. Luckily, we already have it: assert False -- ~Ethan~ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/PEHC3L52QXWHY7SIPUSBC2BRXK6YNHIH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: fail keyword like there is pass keyword
On 24/10/20 7:52 am, Umair Ashraf wrote:
class MyTest(unittest.TestCase):
def test_this_and_that(self):
"""
Given inputs
When action is done
Then it should pass
"""
fail
def fail():
raise Exception("It didn't work!")
Not every one-line function needs to be a keyword!
I feel this *fail* keyword is needed to write a
test first which fails and then write code and then come back to the
test and fill its body.
Um, that's not quite how TDD is supposed to work. You don't explicitly
write the *test* so that it fails. You write a proper test, and it
fails initially because you haven't yet written the code that it tests.
--
Greg
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/5PHQ6FMCOF7LSBYLIP5KWMEPSDEUU7MM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: fail keyword like there is pass keyword
On Fri, Oct 23, 2020 at 01:06:36PM -0700, Ethan Furman wrote: > >I think having a *fail* keyword for unit testing > >would be great. > > Luckily, we already have it: > > assert False I take it you don't run your unit tests under -O :-) `raise Exception` works fine for me. -- Steve ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/25ITIXVMKRJVAVLGJINCBYCOPHYQLU2W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: fail keyword like there is pass keyword
On 10/23/20 4:50 PM, Steven D'Aprano wrote: On Fri, Oct 23, 2020 at 01:06:36PM -0700, Ethan Furman wrote: I think having a *fail* keyword for unit testing would be great. Luckily, we already have it: assert False I take it you don't run your unit tests under -O :-) `raise Exception` works fine for me. Good point. I should start doing that. -- ~Ethan~ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/IVOVHZKZAPCQO2RLYNTBHQPO2IMXHAUI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636
Woah, this is both exciting and scary. If adopted, it will be a major change to how Python programs are written. It seems a lot of work has been put into polishing the design. That's good because if we do this, will not be easy to fix things later if we made design errors. One of my first thoughts is this sounds similar to Clojure's "spec"[1]. Are the pattern matching PEP authors aware of it? I don't mean we need to copy what spec does (really, I'm not all that familiar with it). I do notice that spec patterns are not just used for case statement de-structuring. Maybe we should think about a future Python that would use similar patterns for those things too. I believe "spec" has been in use for a number of years and so the Clojure community has useful experience with the design. An example of something "spec" does and this proposal agrees on is the matching of mappings. I.e. that if there are additional key/value pairs, they don't cause the match to fail by default. That's important for loose coupling between systems. [1] https://clojure.org/about/spec ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/HEPSCFLR7ONEDUMCX7MRFBH7A3CVYCUJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] When to remove BytesWarning?
Hi, all. To avoid BytesWarning, the compiler needs to do some hack when they need to store bytes and str constants in one dict or set. BytesWarning has maintenance costs. It is not huge, but significant. When can we remove it? My idea is: 3.10: Deprecate the -b option. 3.11: Make the -b option no-op. Bytes warning never emits. 3.12: Remove the -b option. BytesWarning will be deprecated in the document, but not to be removed. Users who want to use the -b option during 2->3 conversion need to use Python ~3.10 for a while. Regards, -- Inada Naoki ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/XBIZSPXCSH4KHPX7A6W7XB3H26LLNZQ4/ Code of Conduct: http://python.org/psf/codeofconduct/
