I don't remember this topic ever being discussed, but still I wouldn't
expect that __something to be mangled, given that it refers to an attribute
of an instance of D.
I might expect that in a "case D(something=__y)" you get the mangling for
__y, but I'm not sure what the implementation does now a
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 Mark,
I think some of these issues have already been raised and replied (even if
no agreement has been reached). but this is a good summary, so let me reply
with a summary of responses for this.
On Sat, 6 Feb 2021 at 15:51, Mark Shannon wrote:
> Hi,
>
> Since a decision on PEP 634 is imminen
This is an answer to "what PEP 634 proposes":
On Fri, 4 Dec 2020 at 19:18, Jim J. Jewett wrote:
> (...)
> I'm getting a bit confused over when people mean "the PEP currently says"
> vs "the implementation probably should" vs "the PEP should additionally
> require" vs "the PEP should instead say"
On Sun, 22 Nov 2020 at 00:31, Greg Ewing
wrote:
> On 22/11/20 6:47 am, David Mertz wrote:
> > I'm convinced by Guido,
> > Brandt, and others that the binding use will be far more common, so
> > adding extra characters for the 90% case does not feel desirable
>
> Minimising the number of characte
Others have replied with most of this covering my opinion but there's a
point I'd like to highlight here
On Fri, 20 Nov 2020 at 14:23, Mark Shannon wrote:
> Hi Daniel,
>
> On 20/11/2020 10:50 am, Daniel Moisset wrote:
> > (... snipping for brevity ...)
> >
&
Hello again Mark, I took some time looking in more detail at your proposal,
and these are my thoughts. I'm writing with the assumption that this
proposal describes some "internal" representation of match statements which
is never exposed to the users (so I'd mostly steer away from
lexical/syntactic
A notorious example here of the "not many" is this proposal (i.e. not part
of the language yet) for C++:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1371r0.pdf . I
think it's an interesting example given that this is a very mature
language, not originally designed with pattern matching
[sorry for the duplicate, meant to reply-all]
Thank you for this approach, I find it really helpful to put the
conversation in these terms (semantics and guiding principles).
This is not an answer to the proposal (which I've read and helps me
contextualize) but to your points below and how they a
In this case, you can use the old parser as an oracle, at least for python
3.8 syntax. The new parser should produce a syntax error if and only if the
old one does. And if it doesn't the AST should be the same I guess (I'm not
sue if the AST structure changed)
On Thu, 8 Oct 2020, 03:12 Terry Reedy
Hi Mark,
As the specific author of that example (and the author of the big it had on
a previous version) let me clarify:
The change in semantics is intentional. I could be more explicit, and
preserve semantics, but I actually find very likely that the original code
does not support other sequence
Javascript hasn't it yet, but there is an active proposal for it in the
standardization committee: https://github.com/tc39/proposal-pattern-matching
On Wed, 5 Aug 2020 at 21:34, Luciano Ramalho wrote:
> On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn wrote:
> > And experience from other programming
Hey Larry, just to clarify on a single point you make:
On Sun, 12 Jul 2020 at 10:48, Larry Hastings wrote:
> [ snip ]
> To address 2), bind '_' when it's used as a name in a pattern.
>
> This adds an extra reference and an extra store. That by itself seems
> harmless.
>
This is not always just
On Tue, 7 Jul 2020 at 15:07, Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> (...) Nor am I keen on "expressions" being interpreted
> differently after 'case' than elsewhere in Python.
Python already has "expressions" (intentional quotes) that are interpreted
differently depending on
If I was to do this in Python, rather than the Rust way of forbidding
refutable patterns, I would put as a rule that the target must have at
least one variable to bind* . It makes sense in the context that the goals
of an assignment are the bindings it does, and the ValueError is an
accident that t
On Wed, 1 Jul 2020 at 15:50, Guido van Rossum wrote:
> Before we all get a little too excited here, I think that allowing
> ```
> 1 = x
> ```
> as a sneaky way of writing
> ```
> assert x == 1
> ```
> would be a terrible mistake.
>
Well, we'll always have the sneaky way to check if an iterable i
Hi, thank you for the comments
On Tue, 30 Jun 2020 at 07:18, Greg Ewing
wrote:
> On 29/06/20 8:47 am, Daniel Moisset wrote:
> > <
> https://github.com/dmoisset/notebook/blob/811bf66/python/pep622/understanding-pep-622.md>
> .
>
>
> You seem to be trying to shoeh
I've been going over the PEP this weekend, trying to get a
deeper understanding of what are its main ideas and consequences, and wrote
some notes. I'm not posting the notes directly to this list because it's a
bit of a long read, but I also tried to make it helpful as an analysis for
people involve
This one is new but I think unrelated and unmentioned:
Why is the mapping match semantics non-strict about keys? Besides the
"asymmetry" with sequence matches, I think a strict match should be useful
sometimes (quickly deconstructing JSON data comes to my mind, where I want
to know that I didn't g
Just a minor editorial thing on the PEP text:
The section https://www.python.org/dev/peps/pep-0622/#case-clauses presents
a simplified syntax. That one mentions "group_pattern", but the document
never mentions (in prose) what a group pattern is. It confused me until I
found the definition in the f
[apologies for the duplicate to Guido, used reply instead of reply to all]
To summarize my previous unanswered post, I posted a +1 to the "defaulting
to binding vs interpreting NAME as a constant" is a dangerous default. And
I submitted a couple of alternate syntactic ways to denote "capture is
de
Wow, this looks fantastic, I've wanted this for a long time! I really
appreciate the work that has been put here.
As a bit of context for this and future emails, I fury wanted to say:
* I'm strongly positive about this even if I propose changes
* I've explored a bit on my own how to do this, so I'
Hi, thanks for the work on this proposal, I think this is at least a tip of
the iceberg and a good start for the bigger question of how the stdlib
should evolve..
I think that the PEP should include an idea of what should happen if
existing stdlib pieces depend on this deprecated modules. For exam
23 matches
Mail list logo
