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
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.
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
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
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
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
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 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 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
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 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
11 matches
Mail list logo
