Just to clear up a quick point I made:
> - PyFrameObject.f_back just gives you a dummy wrapper around the previous
> frame object.
> - It's not really useful for unwinding anything.
That should read "previous InterpreterFrame", rather than "previous frame
object".
Also, everything I wrote
Hi Gabriele!
> I hope you would indulge me in asking for some details about the new CFrame
> structure, even in the form of existing literature (e.g. PEP) where the idea
> behind it is explained.
There isn't too much documentation on this, unfortunately (since these are all
very unstable,
Guido van Rossum wrote:
> What's exasperating to me about this whole discussion is that nobody has
> shown any reason why this kind of code would be occurring in user code.
> STORE_FAST x LOAD_FAST x seems that it must come from a user writing
> x = x
I think that would be LOAD_FAST(x)
I can think of two reasons.
The first reason is that this operation *does* have a side-effect: if a fast
local is unbound, the load will raise a NameError!
def f():
x # This should always raise.
x = None # This makes x a fast local.
The second reason is one that Guido already
Łukasz Langa wrote:
> Joking aside, since we allow any expression after 'except' 'group' then this
> is indeed ambiguous. In theory!
The ambiguity with function calls, though, is probably a dealbreaker:
except group (E1, E2) as e: …
except group(E1, E2) as e: …
See my other message for an
Łukasz Langa wrote:
> Joking aside, since we allow any expression after 'except' 'group' then this
> is indeed ambiguous. In theory!
Another option (to remove the ambiguity) could be to move the “group” after the
expression. Bonus points for reading more clearly:
except MemoryError group as e:
Łukasz Langa wrote:
> My idea is this:
> try:
> ...
> except group E as e:
> ...
> except group E1, T2 as e:
> ...
> Should be doable given the magical match-case contextual keywords precedent.
> This looks nice and is explicit, since you will always get an ExceptionGroup
> instance
Irit Katriel wrote:
> It is also not too late to opt for a completely different syntax if a better
> one is suggested.
Honestly, I’ve never been a fan of the PEP’s proposed star syntax.
If we’re okay adding a soft keyword, though, something like “except each” could
help communicate the meaning
Guido van Rossum wrote:
> TBH I don't think there is an *actual* problem here. I think it's just
> about choosing the right wording for the glossary (which IMO does not have
> status as a source of truth anyway).
Good point. I'm probably approaching this from the wrong angle (by trying to
"fix"
Guido van Rossum wrote:
> On Tue, Sep 14, 2021 at 3:49 PM Brandt Bucher brandtbuc...@gmail.com
> wrote:
> > I think it's also worth noting that a missing "`__iter__` that returns
> > self" is trivial to recover from... just use a new reference to the
> > iterator
I think it's also worth noting that a missing "`__iter__` that returns self" is
trivial to recover from... just use a new reference to the iterator instead.
The overhead of a method call for this convention almost seems silly.
What worries me most about changing the current "requirement" is
Brandt Bucher wrote:
> You can even get creative and use the dedicated “pistol” operator…
Ah, wait, ignore this example. I got the chr and ord behavior flipped in my
head.
Brandt
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe s
Steven D'Aprano wrote:
> TIL :-)
> How have I never noticed to_bytes until now? o_O
I’m going to go out on a limb here: because it’s rarely ever needed?
I mean, the proposed bchr() functionality is crazy simple to implement yourself
if you actually *do* need it. You can even get creative and
Steven D'Aprano wrote:
> To me, it sounds like should be the opposite of int.from_bytes.
> >>> int.from_bytes(b'Hello world', 'little')
> 121404708502361365413651784
> >>> bytes.from_int(121404708502361365413651784, 'little')
> # should return b'Hello world'
> If that's not the API
Marco Sulla wrote:
> I remember the BDFL said in a post […]
Really trying not to get involved, but for anybody still reading: Marco is
seriously misquoting somebody here. The actual quote is “too many cooks”.
Ethan Furman wrote:
> On 5/17/2021 6:13 AM, Mark Shannon wrote:
> > Where i1, i2 are integers and s1 is a string.
> > > i1 + i2 + s1
> >
> Wouldn't the carets just be under the i2 + s1 portion?
I don't think so, since this is executed as `((i1 + i2) + s1)`.
Mark's carets look
It has always bugged me that for Enums mixed in with int or str (a common
pattern in my code), `f"{MyEnum.X}"` is not the same as `str(MyEnum.X)`.
I'd be happy to see it changed!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send
Hi Mark.
Thanks for your reply, I really appreciate it.
Mark Shannon said:
> My intention, and I apologize for not making this clearer, was not to
> denigrate your work, but to question the implications of the term "reference".
>
> Calling something a "reference" implementation suggests that
Mark Shannon said:
> I was relying on the "reference" implementation, which is also in the PEP.
Can you please stop putting scare quotes around "reference implementation"?
You've done it twice now, and it's been a weekend-ruiner for me each time.
I've put months of work into writing and
Mark Shannon wrote:
> On 02/04/2021 7:19 am, Brandt Bucher wrote:
> > I agree that self-matching classes should absolutely allow keyword matches.
> > I had no idea the PEP forbade it.
> PEP 634 allows it.
PEP 634 says:
> For a number of built-in types (specified below)
Guido van Rossum wrote:
> Well, now I have egg on my face, because the current implementation does
> reject multiple occurrences of the same identifier in __match_args__. We
> generate an error like "TypeError: C() got multiple sub-patterns for
> attribute 'a'". However, I cannot find this
Guido van Rossum wrote:
> On Wed, Mar 31, 2021 at 2:14 PM Brandt Bucher brandtbuc...@gmail.com
> wrote:
> > (One change from my last email: it doesn't allow `__match_map__` /
> > `__match_seq__` to be set to `False`... only `True`. This prevents some
> > otherwise tricky m
>> - Add new `__match_seq__` and `__match_map__` special attributes,
>> corresponding to new public `Py_TPFLAGS_MATCH_SEQ` and
>> `Py_TPFLAGS_MATCH_MAP` flags for use in `tp_flags`. When Python classes are
>> defined with one or both of these attributes set to a boolean value,
>>
Hi Mark.
I've spoken with Guido, and we are willing to propose the following amendments
to PEP 634:
- Require `__match_args__` to be a tuple.
- Add new `__match_seq__` and `__match_map__` special attributes, corresponding
to new public `Py_TPFLAGS_MATCH_SEQ` and `Py_TPFLAGS_MATCH_MAP` flags
Overall, I am still uncomfortable with PEP 653, and would probably not support
its acceptance.
Although it has thankfully become a much less radical proposal than it was a
few weeks ago (thanks, Mark, for your attention to our feedback), I feel that
the rules it binds implementations to are
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
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 li
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.
Paul Sokolovsky wrote:
> Use punctuation ("sigils") to mark as-binding terms. This choice still seems
> to be under-considered. (As in: it doesn't seem like many people, including
> the PEP authors, tried to say "indeed, what if?" and feel thru it. I mean,
> try really hard. I trust the "gang
Glenn Linderman wrote:
> So what _is_ the syntax for "a tuple of two equal values" ?
If you’re asking about PEP 634:
```
case x, y if x == y:
```
Which is much clearer, in my opinion.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe
> Can we discuss whether we want pattern matching in Python and the broader
> semantics first, before dealing with low level details?
This is a huge step backward. These discussions have already taken place, over
the last 10 years.
Here's just a sampling:
-
Agreed. To prevent the docs from going stale, the "Originally proposed in
:pep:`XXX`." wording should probably be used for *all* of the new links, not
just the ones that are currently out-of-date.
Depending on the scope of these changes, we could also just consider adding a
new ".. pepadded::
Tim Peters wrote:
> `zip` then creates `n` 2-tuple objects, each of which lives only long enough
> to be unpacked into `x` and `y`... With "immediate" reclamation of garbage
> via refcounting, memory use is trival regardless of how large `n` is, as
> CPython reuses the same heap space over &
Federico Salerno wrote:
> Is there anything (bar tradition or other subjective arguments) that speaks
> in favour of this, especially in light of the fact that having the same
> indentation level would also solve other problems? ...if anyone made an
> argument against it I must have missed it:
Ethan Furman wrote:
> Why is this no longer an issue? My apologies if I missed it in the PEP.
This problem was an artifact of the default `object.__match__` implementation,
which allowed one positional argument by default when `__match_args__` was
missing or `None`. Since we've removed
Inada Naoki wrote:
> Since this is very new system, can we have some restriction to allow
> aggressive optimization than regular Python code?
The authors were just discussing a related question yesterday (more
specifically, can the compiler fold `C() | C()` -> `C( | )`).
The answer we arrived
Henk-Jaap Wagenaar wrote:
> The not binding is there only to allow the main way in which "_" is special
> in match/case: ...
The non-binding behavior is useful in other ways:
match range(HUGE_INT):
case [*_, last]:
print(last)
___
Since I took it upon myself to implement PEP 622, I just have a few thoughts to
add to the other excellent responses here. Hopefully these will help clarify
that the intent is not to "railroad" anything.
Rob Cliffe wrote:
> PEP 622 only seems to have been presented to the Python community only
Walter Dörwald wrote:
> This looks strange to me. In all other cases of variable lookup the global
> variable z would be found.
The next case assigns to z, making z local to whereis. This is consistent with
python's existing scoping rules (for example, try rewriting this as the
equivalent
Ethan Furman wrote:
> Ouch. That seems like a pretty serious drawback. Will this issue be
> resolved?
It's currently being revisited.
Realistically, I'd imagine that we either find some straightforward way of
opting-in to the current default behavior (allowing one arg to be positionally
Pablo Galindo Salgado wrote:
> ...users can do a positional match against the proxy with a name pattern:
>
> match input:
> case datetime.date(dt):
> print(f"The date {dt.isoformat()}"
>
> ...if 'datetime.date' were updated to implement a non-default __match_args__,
> allowing
Guido van Rossum wrote:
> So why not .get(key, )? You can reuse the sentinel, and this way
> it's a single call instead of two -- e.g. the code in Mapping implements both
> __contains__() and get() by calling __getitem__() and catching KeyError.
Good point. Another option I've considered is
Guido van Rossum wrote:
> IIUC the pattern matching uses either .get(key, ) or
> .__contains__(key) followed by .__getitem__(key). Neither of those will
> auto-add the item to a defaultdict (and the Mapping protocol supports both).
> @Brandt: what does your implementation currently do? Do you
Woo! Many thanks to Ram for the idea, Antoine for sponsoring, Guido for
PEP-Delegating, and everyone on -Ideas and -Dev for the spirited discussion and
review.
Brandt
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
Maybe I'm missing something here. The PEP specifically says:
> Similarly, the iteration order of the key-value pairs in the dictionary will
> follow the same semantics as the examples above, with each newly added key
> (and its value) being appended to the current sequence.
That seems
In the last 24 hours, this thread has grown a bit beyond my capacity to
continue several different lines of discussion with each individual. I count 22
messages from 14 different people since my last reply, and I assure you that
I've carefully read each response and am considering them as I
Ethan Furman wrote:
> Can you do those with _pydecimal? If performance were an issue anywhere I
> would expect to see it with number crunching.
No difference, probably because those methods look like they spend most of
their time doing string manipulation:
```
$ export PYPERFSETUP='from
Ethan Furman wrote:
> So half of your examples are actually counter-examples.
I claimed to have found "dozens of other call sites in Python's standard
library and tooling where it would be appropriate to enable this new feature".
You asked for references, and I provided two dozen cases of
Thanks for all of your feedback.
Antoine Pitrou wrote:
> I'm not sure what the iters bring here. The snippet would be more readable
> without, IMHO.
Good point. I was trying to demonstrate that it works with iterators, but I
agree it's clearer to just use the lists here.
Ethan Furman wrote:
I have pushed a second draft of PEP 618:
https://www.python.org/dev/peps/pep-0618
Please let me know what you think – I'd love to hear any new feedback that
hasn't yet been addressed in the PEP!
Brandt
___
Python-Dev mailing list --
> The best way to look at this is to consider how long a .pyc file is valid.
> They're currently named something like __pycache__/modulename.cpython-38.pyc
> which is a fairly clear indication that the cached compiled module should be
> valid for any CPython 3.8.x release.
Perhaps an even
Welcome Bhavani!
This is only my second PEP, but I'm sure somebody will correct me if I'm wrong!
Basically, the next steps are:
- Mark the PEP as "Accepted":
https://github.com/python/peps/commit/841188a45f17f0252267f016d7b2f11ac27c5aa1
- Review and merge the implementation/tests:
Thanks to Guido for sponsoring, and to the SC for their acceptance!
Brandt
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Thanks for your response Serhiy.
> Yes, but this is a different thing. You must to implement new __or__ in a
> subclass to make the behavior of d1 | d2 be different from {**d1, **d2}.
Really? I'm sorry, but this doesn't feel like a real argument to me.
There was no clear compatible path
> Are these three cookie classes sufficiently popular that we need to support
> `|` on them?
I don't have much experience with `http`, so I figured I'd open a BPO issue and
let the relevant folks make the call. The main reason I'm considering these is
that `Morsel` was updated back in 3.5 with
Happy to help.
Since it doesn't seem like anybody has issues with the PEP, and the PR looks
solid, I think I'll contact the Steering Council about moving this forward.
Brandt
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an
> we'll also want to look at collections.UserDict, collections.ChainMap, and
> types.MappingProxyType.
UserDict has already been updated in the PR (it has tests that fail if it
doesn't have all of dict's methods). I'll look into the others... thanks for
reminding me!
> collections.Mapping and
Just to follow up on this, here are the subclasses I've found.
Should be updated:
- collections.OrderedDict
- collections.defaultdict
- http.cookies.BaseCookie
- http.cookies.Morsel
- http.cookies.SimpleCookie
Don’t think so:
- typing.TypedDict
Already defines the operator:
-
All of these have been landed. Thanks, everybody!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
Hi everybody!
I've found a handful of trivial PRs from new contributors that have gone
un-core-reviewed since November. CLAs are signed, tests are passing, and I've
verified the quality and correctness of each one.
If anybody has a few spare minutes to merge these, I know that it would make
PEP 614 has recently completed a round of review on Python-Ideas:
https://www.python.org/dev/peps/pep-0614/
It proposes that the current decorator syntax restrictions be relaxed to allow
any valid expression. Nobody has raised any objections, but I wanted to gather
more feedback here prior to
> In particular, you may want to update the implementations of defaultdict and
> ordereddict. (are there others?)
I have a checklist for PEP 584 follow-up PRs I'm planning to make after (and
if) it is accepted. typeshed stubs, docs, and `defaultdict` were on it. I'll
add `OrderedDict` as well
> I am accepting this PEP. Congratulations Steven and Brandt!
Thank you for your guidance, especially the suggestions late last year. And
thanks Steven for taking me on as a co-author and shaping the bulk of the
proposal.
> Hm, the PEP should probably also link to that PR rather than to
> So can we just finish PEP 584 without the .copy() call?
Sounds good. I’ll update the implementation and open a PR to the PEPs repo
later tonight. Thanks everybody!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
After a few days of thinking and experimenting, I’ve been convinced that `copy`
(and also `__copy__`) is not the right protocol for what we want to do here. I
believe that 584 can likely continue without subclass-preserving behavior, but
that better behavior could perhaps could be added to
> > We already have an API for copying a dict (dict.copy). I still fail to see
> > problem with using a method that doesn't start and end with underscores,
> > other than that we "haven't done it".
>
> Before Python 3.0, iterators had a next() method, and that was explicitly and
> consciously
Sorry Paul, I sent my reply too soon.
I see what you're saying, and I'm pretty firmly -1 on reinventing (or
importing) copy.copy. We already have an API for copying a dict (dict.copy).
I still fail to see problem with using a method that doesn't start and end with
underscores, other than that
> but I think the desired semantics can all be achieved using only magic
> methods on the objects themselves
Hm. So, just to clarify, you're suggesting we use `__copy__`, if it exists?
Interesting...
___
Python-Dev mailing list --
> It would create an exception of two rules:
I don't think these are "rules", I think they're just "the way things are".
If I'm subclassing `dict`, and I see in the docs something to the effect of:
> By default, `dict` subclasses will return `dict` objects for `|` operations.
> To force the
> I see this asymmetry between the | and |= mentioned a few times in the PEP,
> but I don't see any rationale other than "the authors have decided".
I agree that this probably deserves to be addressed. I can't speak for Steven,
but I know that my motivation here is to restrict `|` in order to
> We should fix that (by reverting to 3.8.1 behaviour) before 3.8.2 gets
> released.
The commits which changed the behavior were bytecode/compiler changes that only
went to master. I don't think they are present on any other branches.
___
Python-Dev
One issue that's come up during PR review with Guido and Serhiy is, when
evaluating `a | b`, whether or not the default implementation should call an
overridden `copy()` method on `a` in order to create an instance of the correct
subclass (rather than a plain-ol' `dict`). For example,
Commits 13bc139 and 8a4cd70 introduced subtle changes in the evaluation logic
of unpacking operations. Previously, all elements were evaluated prior to being
collected in a container. Now, these operations are interleaved. For example,
the code `[*a, *b]` used to evaluate in the order `a` ->
> I have one suggestion: Wouldn't it be useful for these operators to also
> accept sets (functionally acting like a dict with None for all values)?
> Why None? Why not 0, or False, or 42? This sort of thing belongs more in a
> function or method, IMHO.
Well, in their defense, None is the
It already has a PR open against master, with all tests passing:
https://github.com/python/cpython/pull/12088
Sorry about the messy history - this proposal has changed significantly several
times over the past year (at least as far as the implementation is concerned).
At one point, both
Steven D'Aprano and I have pushed a third draft of PEP 584:
https://www.python.org/dev/peps/pep-0584/
The accompanying reference implementation is on GitHub:
https://github.com/brandtbucher/cpython/tree/addiction
For those who have been following the discussions over the past year on
> On Dec 27, 2019, at 19:48, Tim Peters wrote:
>
> So, ya, I've seen and implemented lots of work queues along these
> lines - but an OrderedSet would be an "attractive nuisance"
> (offhandedly appearing to solve a problem it doesn't actually
> address):
>
> jobs = some_kind_of_queue()
>
Interesting that you bring this up. Just earlier this week I published the
first version of a new package that lets you write compiled bytecode
instructions inline with pure-Python syntax. The code's still a bit messy,
being only a week old and all, but it works as advertised for CPython 3.6.2
Thanks everybody for the quick response! These all now have core review (from
Steering Council members, no less)!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
Hi all. There are a few *very simple* PRs from first-time contributors that
have been sitting un-core-reviewed for several weeks.
https://github.com/python/cpython/pull/16680: bpo-38419: fix "check-c-globals"
path
https://github.com/python/cpython/pull/16678: bpo-38421: Update email.utils
Hi Lewis.
I'm in the Pacific time zone. Barring any surprises (I'm getting married late
next month), I can commit to being online in the morning (the last few hours of
your business day), as well as during my normal business hours (late
evening/night for you). Just tag "@brandtbucher" on any
Hi Lewis.
I'm a trigger (not a core developer), but I'd be happy to make myself available
during that time for expedited PR reviews. Ideally, the core review / merge
stage would be your only bottleneck then.
I'm a bit busy next month though, so do you know the actual dates / time / time
zones
I’m a bit confused. For my own understanding: what’s stopping
PyObject_IsInstance/PyObject_IsSubclass from just trying
PyImport_GetModule("typing") here?
If NULL, carry on. Otherwise, check the Union case.
Brandt
> On Oct 8, 2019, at 05:44, Philippe Prados wrote:
>
>
> Glups.
>
> I am
83 matches
Mail list logo
