On Fri, 17 Jul 2020, 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 adept at ignoring
them, we will again
On 7/17/2020 7:23 AM, emmanuel.coir...@caissedesdepots.fr wrote:
Hello everyone,
I'm sorry if my proposition has already being said, or even withdrawn,
but I think that capture variables shouldn't be as implicit as they
are now.
I've looked at the PEP very quickly, jumping on the examples to
On Fri, Jul 17, 2020 at 3:54 PM Guido van Rossum wrote:
>
> On Fri, Jul 17, 2020 at 1:45 PM Yury Selivanov
> wrote:
>>
>> I've built the reference implementation and I'm experimenting with the
>> new syntax in the edgedb codebase. It seems to have plenty of places
>> where pattern matching adds
On Thu, Jul 16, 2020 at 9:21 AM Federico Salerno
wrote:
> [...]
Now consider the following refactor:
>
> 3d_point = MatchCase("Point(x, y, z)")
> other_3d_point = MatchCase("Point(_, _, _)")
> point_with_my_y = MatchCase("Point(_, {})", my_y) # syntax with {} is
> debatable.
> other_2d_point =
On 7/16/2020 9:51 PM, Tobias Kohn wrote:
Hi Everyone,
I feel there are still quite a few misconceptions around concerning PEP
622 and the new pattern matching feature it proposes. Please allow me
therefore to take another attempt at explaining the ideas behind PEP 622
with a different
On 18/07/20 4:34 am, Richard Levasseur wrote:
match get_point() into m:
case Point(m.x, m.y):
print(m.x, m.y)
...etc...
Personally, I thought this was a rather elegant solution to the
load-vs-store problem for names. This is because, essentially, it
changes the mental model from
On Fri, Jul 17, 2020 at 1:45 PM Yury Selivanov
wrote:
> I've built the reference implementation and I'm experimenting with the
> new syntax in the edgedb codebase. It seems to have plenty of places
> where pattern matching adds clarity. I'll see if I find particularly
> interesting examples of
Mark Shannon wrote:
> In future, could you avoid editing emails when replying to them?
> A lot of context can get lost.
I'll add another voice to Ethan's saying that I appreciate having as much as
possible trimmed.
As long as people are arguing in good faith (and I assume that they are
I've built the reference implementation and I'm experimenting with the
new syntax in the edgedb codebase. It seems to have plenty of places
where pattern matching adds clarity. I'll see if I find particularly
interesting examples of that to share.
So far I'm +1 on the proposal, and I like the
ACTIVITY SUMMARY (2020-07-10 - 2020-07-17)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7550 (+20)
closed 45517 (+35)
total 53067 (+55)
Open issues
I like the proposal in general but I am against removing lnotab. The reason
is that many tools rely on reading this attribute to figure out the Python
call stack information. For instance, many sampler profilers read this
memory by using ptrace or process_vm_readv and they cannot execute any code
PEP 626:
Rather than attempt to fix the co_lnotab attribute, a new method co_lines()
will be added, which returns an iterator over bytecode offsets and source code
lines.
Why not attempt to fix co_lnotab?
--
~Ethan~
___
Python-Dev mailing list --
Hi Python-dev and PEP 622 Authors,
I saw this idea, or something like it, posted by a couple of people, but
didn't see much discussion of it, and skimming the PEP today, I didn't see
a mention of it. Maybe I just missed it; my apologies if so, and a link to
the relevant discussion/text would be
On 7/17/20 8:26 AM, Gustavo Carneiro wrote:
I kind of agree it is nicer to be more explicit. But somehow x= looks
ugly. It occurred to me (and, again, apologies if already been
mentioned), we might use the `as` keyword here.
The problem with any kind of sigil/keyword is that it becomes line
PEP 626 wrote:
Abstract
Python should guarantee that when tracing is turned on, "line" tracing events
are generated for all lines of code executed and only for lines of code that are executed.
The sample code shows `return` events being executed, even when there is
no `return` line --
https://www.python.org/dev/peps/pep-0626/ :)
--Ned.
On 7/17/20 10:48 AM, Mark Shannon wrote:
Hi all,
I'd like to announce a new PEP.
It is mainly codifying that Python should do what you probably already
thought it did :)
Should be uncontroversial, but all comments are welcome.
Cheers,
On Fri, 17 Jul 2020 at 12:26, wrote:
> Hello everyone,
>
> I'm sorry if my proposition has already being said, or even withdrawn,
> but I think that capture variables shouldn't be as implicit as they
> are now. I didn't see any mention of capture variable patterns in
> the rejected ideas. So
Hi all,
I'd like to announce a new PEP.
It is mainly codifying that Python should do what you probably already
thought it did :)
Should be uncontroversial, but all comments are welcome.
Cheers,
Mark.
___
Python-Dev mailing list --
Hello everyone,
I'm sorry if my proposition has already being said, or even withdrawn,
but I think that capture variables shouldn't be as implicit as they
are now. I didn't see any mention of capture variable patterns in
the rejected ideas. So here is my idea:
I've looked at the PEP very
19 matches
Mail list logo
