In addition to the changes proposed here that go beyond PEP-634 (which
other people discuss), I find that many of the definitions fail to capture
some of the basic features of PEP-634, especially when nesting patterns.
Take for example: "case [int(), str()]". According to
https://www.python.org/de
Hi Oscar
Quoting Oscar Benjamin :
On Fri, 19 Feb 2021 at 15:41, Tobias Kohn wrote: [...]
It's not easy now to look back over the history of all of this. My
recollection of the original version of PEP 622 (if that's the right
one...) was that it had an overcomplicated protocol for __match__.
On Fri, 19 Feb 2021 at 15:41, Tobias Kohn wrote:
>
> Hi Mark,
>
> Thank you for your proposal to try and have more precise semantics for
> pattern matching. Of course, the proposal primarily introduces a new and
> extended protocol for pattern matching, upon which the 'semantics' is then
> bas
Oscar Benjamin wrote:
> Under PEP 634 in general, for any class C, a pattern C(x) matches an object
> C(x, y) and there's no way for C to override that. To me that is sufficiently
> unintuitive in the abstract that no example is really needed to see where
> there is room for improvement.
We ori
On Fri, 19 Feb 2021 at 16:27, Tobias Kohn wrote:
>
> Quoting Oscar Benjamin :
>
> > I'm not entirely sure but I think that with PEP 653 you can implement this
> > like:
> >
> > def __deconstruct__(obj):
> > if obj.step != 1:
> > return obj.start, obj.stop, obj.step
> > eli
Hi Mark,
Quoting Mark Shannon :
Hi Tobias,
[...]
But they are not referenced in PEP 634. I shouldn't have to trawl
the internet to find the rejected ideas section.
https://dl.acm.org/doi/10.1145/3426422.3426983
That paper describes a `__match__` method, which is absent from PEP 634.
W
Hi Tobias,
On 19/02/2021 5:57 pm, Tobias Kohn wrote:
> Hi Mark,
>
> Quoting Mark Shannon mailto:m...@hotpy.org>>:
>
>> [...]
>>
>> If you had published these "more complicated, powerful protocols", you
>> might be able to claim that this is a "rehash".
>> But you didn't.
>>
> I would say that the
Hi Mark,
Quoting Mark Shannon :
[...]
If you had published these "more complicated, powerful protocols",
you might be able to claim that this is a "rehash".
But you didn't.
I would say that these ideas have been quite prominently published:
https://www.python.org/dev/peps/pep-0622/#cus
Hi Brandt,
On 18/02/2021 5:32 pm, Brandt Bucher wrote:
Thanks for taking the time to work on this, Mark.
Overall, I'm skeptical of this proposal. It seems like it takes a lot of "simple" things
and makes them quite complex, and takes many "static" things and makes them quite
dynamic. I feel t
Hi,
I wish I'd read this before replaying your last email
On 18/02/2021 6:49 pm, Brandt Bucher wrote:
Brandt Bucher wrote:
For a pattern with no positional subpatterns, such as like `C()` or `C(x=x,
y=y, z=z)`: ...
It also appears that we lose a lot of expressive "idioms" by requiring
`__
Hi Oscar,
Quoting Oscar Benjamin :
Yes, thanks Mark. I'm not sure I've fully understood the PEP yet but
I can see some parts that I definitely like. [...]
As I have just noted in my response to Mark, the aspect with the
"deconstructor" (or `__match__` protocol as we called it) is
defini
Hi Mark,
Thank you for your proposal to try and have more precise semantics for
pattern matching. Of course, the proposal primarily introduces a new
and extended protocol for pattern matching, upon which the 'semantics'
is then based. I think it is important to recognise and discuss your
On Thu, 18 Feb 2021 at 17:35, Brandt Bucher wrote:
>
> Thanks for taking the time to work on this, Mark.
Yes, thanks Mark. I'm not sure I've fully understood the PEP yet but I
can see some parts that I definitely like.
> I fear this is at the expense of most simple classes, which currently "just
Brandt Bucher wrote:
> For a pattern with no positional subpatterns, such as like `C()` or `C(x=x,
> y=y, z=z)`: ...
> It also appears that we lose a lot of expressive "idioms" by requiring
> `__attributes__` to be complete.
> This also means that matching classes like `types.SimpleNamespace` a
Thanks for taking the time to work on this, Mark.
Overall, I'm skeptical of this proposal. It seems like it takes a lot of
"simple" things and makes them quite complex, and takes many "static" things
and makes them quite dynamic. I feel that it also misrepresents certain aspects
of PEP 634.
He
15 matches
Mail list logo
