On 2/2/21 12:36 PM, Stefano Borini wrote:
Hi all,
I would like to request feedback by python-dev on the current
implementation of PEP 637 - Support for indexing with keyword
arguments.
https://www.python.org/dev/peps/pep-0637/
The PEP is ready for SC submission and it has a prototype
On 3/02/21 10:35 pm, Phil Thompson wrote:
On 02/02/2021 23:08, Greg Ewing wrote:
you have no idea what
kind of C struct it expects to get.
I had assumed that some other magic in typeobject.c (eg. conflicting
meta-classes) would have raised an exception before getting to this
stage if there
I like.
On Wed, 2021-02-03 at 15:48 -0800, Guido van Rossum wrote:
> Anyone? I'm +1 on this PEP as it is, and I imagine a few other core
> devs are too (Brandt, Steven). If nobody responds before the end of
> the week I think we can say that there was no disagreement and
> Stefano can submit PEP
Anyone? I'm +1 on this PEP as it is, and I imagine a few other core devs
are too (Brandt, Steven). If nobody responds before the end of the week I
think we can say that there was no disagreement and Stefano can submit PEP
637 to the SC.
On Tue, Feb 2, 2021 at 3:43 AM Stefano Borini
wrote:
> Hi
On Wed, 3 Feb 2021, 10:16 pm Sven R. Kunze, wrote:
> Hi Mark,
>
> I've been working on a project heavily relying on frame.f_locals.
>
> Are you planning to remove it?
>
No, PEP 558 doesn't remove it, it enhances it to be a live view of the
frame state instead of an inconsistently updated
I think this would just perpetuate misunderstanding about how things work.
You're proposing to make it so that changing the body of the function (in
particular, removing `y: T`) would affect the interpretation of the type
annotation. That's just wrong.
On Wed, Feb 3, 2021 at 12:47 PM Caleb
> Here we want to know what the 'C' refers to in g's annotations. But g's
closures are no help (unless g's body were to also reference C, which is
not likely in typical code).
I understand the limitation. I was proposing changing
On Thu, Jan 21, 2021 at 5:09 AM Senthil Kumaran wrote:
> And another security issue was brought up to our attention here (today):
> https://bugs.python.org/issue42987
This one was already fixed (the issue is closed).
Victor
--
Night gathers, and now my watch begins. It shall not end until my
Sadly this won't work, because the annotations are "evaluated" (or not) in
the surrounding scope, not in the function's scope. Example:
```
>>> def f(a: int):
... class C: pass
... def g(b: C): pass
... return g
...
>>> g = f(1)
>>> g.__annotations__
{'b': 'C'}
>>> g.__closure__
>>>
```
Here
On 2/2/2021 8:37 PM, Caleb Donovick wrote:
The discussion around PEP 649 got me thinking about what I believe is
the largest downside to PEP 563: the inability to evaluate annotations
created with closures. While this is in general unavoidable, if
the type is ever referenced in an annotated
Hi Mark,
I've been working on a project heavily relying on frame.f_locals.
Are you planning to remove it?
On 30.01.21 13:18, Mark Shannon wrote:
Given that f_locals is broken, why is keeping compatibility for this
obscure, and probably unused case worthwhile?
The break in compatibility
Well, this one took a bit more time due to some surprise last time
reference leaks and release blockers to fix, but now Python 3.10.0a5 it’s
here. Will this be the first release announcement of the 3.10 series
without copy-paste typos? Go get it here:
On 02/02/2021 23:08, Greg Ewing wrote:
On 3/02/21 4:52 am, Phil Thompson wrote:
Thanks - that's fairly definitive, although I don't really understand
why __new__ has this particular requirement.
The job of tp_new is to initialise the C struct. To do this,
it first has to initialise the
Hi Greg, Hi List,
Greg wrote:
> class MyClass(B, Mixin):
> >"whatever"
> >
> > this leads to an MRO of MyClass -> B -> Mixin -> A -> object.
>
> If you do the tp_new stuff correctly at the C level, you can still
> create such a class. The only limitation is that if Mixin has a
14 matches
Mail list logo
