On 7/18/2020 6:23 AM, emmanuel.coir...@caissedesdepots.fr wrote:
Ethan Furman wrote:
The problem with any kind of sigil/keyword is that it becomes line noise
-- we would have to train ourselves to ignore them in order to see the
structure and variables we are actually interested in. Once we bec
PEP 622 authors,
Overall, the PEP describes the proposal quite nicely. However, I do indeed
have concerns and questions, some of which I describe in this email.
(1) Class pattern that does isinstance and nothing else.
If I understand the proposed semantics correctly, `Class()` is equivalent
to c
On Sat, Jul 18, 2020 at 3:29 AM wrote:
> > adept at ignoring them, we will again have difficulties when debugging
> > as we won't easily see them.
> > Besides which, the problem is solved:
> >
> > namespace.var is a lookup
> > var is a store
>
> These rules can't be deduced from a few examples, o
On Sat, Jul 18, 2020 at 09:25:45AM -, emmanuel.coir...@caissedesdepots.fr
wrote:
> This approach, for me, seems to come from functionnal languages where
> pattern matching is a thing. The proposed "match" clause tends to
> mimic this approach, and it can be a good thing. But the Python's
>
On 18/07/2020 11:09, Steven D'Aprano wrote:
On Sat, Jul 18, 2020 at 10:58:17AM +0200, Federico Salerno wrote:
We don't, after all,
confuse function calls for references to a function, or vice-versa.
Beginners do. Frequently. Sometimes it is quite a hurdle for them to
learn to write `function()
On Sat, Jul 18, 2020 at 3:46 AM Terry Reedy wrote:
>
> A major points of Kohn's post is that 'case' is analogous to 'def' and
> match lists are analogous to parameter lists. In parameter lists,
> untagged simple names ('parameter names') are binding targets.
> Therefore, untagged simple names in
Ethan Furman wrote:
> The problem with any kind of sigil/keyword is that it becomes line noise
> -- we would have to train ourselves to ignore them in order to see the
> structure and variables we are actually interested in. Once we become
Every syntax element can become noise once we're used
Terry Reedy wrote:
> A major points of Kohn's post is that 'case' is analogous to 'def' and
> match lists are analogous to parameter lists. In parameter lists,
I'm sorry to disagree, but match lists share very few things in common with
today's parameters list, and introduce a full new concept
On Sat, Jul 18, 2020 at 10:58:17AM +0200, Federico Salerno wrote:
> We don't, after all,
> confuse function calls for references to a function, or vice-versa.
Beginners do. Frequently. Sometimes it is quite a hurdle for them to
learn to write `function()` instead of `function`.
And even experi
On 18/07/2020 02:10, Guido van Rossum wrote:
[...] it was quickly pointed out by my co-authors that this doesn't
fly, because when the parser sees `case other_3d_point:` it doesn't
know whether you meant this as a capture pattern (binding the variable
`other_3d_point`) or as a pattern object.
It seems great improvement, but I am worrying about performance.
Adding more attributes to the code object will increase memory usage
and importing time. Is there some estimation of the overhead?
And I am worrying precise tracing blocks future advanced bytecode optimization.
Can we omit precise t
11 matches
Mail list logo
