On 07/08/2020 08:02 AM, Guido van Rossum wrote:
Today I’m happy (and a little trepidatious) to announce the next version of PEP 622, Pattern Matching.
All in all I like it a lot!
As authors we welcome Daniel F Moisset in our midst
Welcom, Daniel, and thank you!
That said, the new version does not differ dramatically in what we propose. Apart from dropping `__match__` we’re dropping the leading dot to mark named constants,
Excellent!
without a replacement,
So namespaced variables only... is there a recommendation on handling global() and local() type variables? The only thing I didn't see addressed was the concern raised by Pablo:
On 06/25/2020 04:07 PM, Brandt Bucher wrote:
Pablo Galindo Salgado wrote:
...users can do a positional match against the proxy with a name pattern:
match input: case datetime.date(dt): print(f"The date {dt.isoformat()}"
...if 'datetime.date' were updated to implement a non-default __match_args__, allowing individual fields to be pulled out of it like this, then the first block would be valid, correct code before the change, but would raise an ImpossibleMatch after the change because 'dt' is not a field in __match_args__. Is this argument misinterpreting something about the PEP or is missing some important detail?
Well yeah, it's actually a fair bit worse than you describe. Since dt is matched positionally, it wouldn't raise during matching - it would just succeed as before, but instead binding the year attribute (not the whole object) to the name "dt". So it wouldn't fail until later, when your method call raises a TypeError.
Why is this no longer an issue? My apologies if I missed it in the PEP. -- ~Ethan~ P.S. Thanks for all your hard work! I am very much looking forward to using this.