Thanks, Carl and Larry for the explanations.
On Sun, 2022-05-01 at 16:13 -0600, Carl Meyer wrote:
> Hi Paul,
>
> On Sun, May 1, 2022 at 3:47 PM Paul Bryan wrote:
> >
> > Can someone state what's currently unpalatable about 649? It seemed
> > to address the forward-referencing issues, certainly
Hi Paul,
On Sun, May 1, 2022 at 3:47 PM Paul Bryan wrote:
>
> Can someone state what's currently unpalatable about 649? It seemed to
> address the forward-referencing issues, certainly all of the cases I was
> expecting to encounter.
Broadly speaking I think there are 3-4 issues to resolve as
On 5/1/22 15:44, Paul Bryan wrote:
Can someone state what's currently unpalatable about 649? It seemed to
address the forward-referencing issues, certainly all of the cases I
was expecting to encounter.
Carl's talk was excellent here; it would be lovely if he would chime in
and reply.
Can someone state what's currently unpalatable about 649? It seemed to
address the forward-referencing issues, certainly all of the cases I
was expecting to encounter.
On Sun, 2022-05-01 at 15:35 -0600, Larry Hastings wrote:
>
> FWIW, I'm in agreement. My "forward class" proposal(s) were me
>
FWIW, I'm in agreement. My "forward class" proposal(s) were me trying
to shine a light to find a way forward; I'm in no way adamant that we go
that direction. If we can make 649 palatable without introducing
forward declarations for classes, that's great! If in the future we
discover more
FWIW, Carl presented a talk about his proposed way forward using PEP 649
with some small enhancements to handle cases like dataclasses (*), and it
was well received by those present. I personally hope that this means the
end of the "forward class declarations" proposals (no matter how
wonderful),
On 26/04/2022 20:48, Carl Meyer via Python-Dev wrote:
On Tue, Apr 26, 2022 at 1:25 PM Guido van Rossum wrote:
I also would like to hear more about the problem this is trying to solve, when
th real-world examples. (E.g. from pydantic?)
Yes please. I think these threads have jumped far too
On Mon, Apr 25, 2022 at 10:32:15PM -0700, Larry Hastings wrote:
[...]
> Whichever spelling we use here, the key idea is that C is bound to a
> "ForwardClass" object. A "ForwardClass" object is /not/ a class, it's a
> forward declaration of a class. (I suspect ForwardClass is similar to a
>
On Tue, Apr 26, 2022 at 1:25 PM Guido van Rossum wrote:
> I also would like to hear more about the problem this is trying to solve,
> when th real-world examples. (E.g. from pydantic?)
Yes please. I think these threads have jumped far too quickly into
esoteric details of implementation and
On Wed, 27 Apr 2022 at 05:05, Larry Hastings wrote:
>
>
> On 4/26/22 09:31, MRAB wrote:
>> Perhaps:
>>
>>class C: ...
>
> Also, your suggestion is already legal Python syntax; it creates a class with
> no attributes. So changing this existing statement to mean something else
> would
I am traveling and have no keyboard right now, but it looks like this
thread is confusing the slots that a type gives to its *instances* and
extra slots in the type object itself. Only the latter are a problem.
I also would like to hear more about the problem this is trying to solve,
when th
> On 26 Apr 2022, at 20:52, Larry Hastings wrote:
>
>
>
> On 4/25/22 23:56, Ronald Oussoren wrote:
>> A problem with this trick is that you don’t know how large a class object
>> can get because a subclass of type might add new slots. This is currently
>> not possible to do in Python code
On 4/26/22 09:31, MRAB wrote:
On 2022-04-26 06:32, Larry Hastings wrote:
Note that this spelling is also viable:
class C
I don't like that because it looks like you've just forgotten the colon.
Perhaps:
class C: ...
That's not a good idea. Every other place in Python where
On 4/25/22 23:56, Ronald Oussoren wrote:
A problem with this trick is that you don’t know how large a class
object can get because a subclass of type might add new slots. This is
currently not possible to do in Python code (non-empty ``__slots__``
in a type subclass is rejected at runtime),
On Apr 25, 2022, at 22:32, Larry Hastings wrote:
> The general shape of it is the same. First, we have some sort of forward
> declaration of the class. I'm going to spell it like this:
>
> forward class C
>
> just for clarity in the discussion. Note that this spelling is also viable:
>
>
On 2022-04-26 06:32, Larry Hastings wrote:
Sorry, folks, but I've been busy the last few days--the Language Summit
is Wednesday, and I had to pack and get myself to SLC for PyCon,
I'll circle back and read the messages on the existing threads
tomorrow. But for now I wanted to post "the
> On 26 Apr 2022, at 07:32, Larry Hastings wrote:
>
>
[…]
> What could go wrong? My biggest question so far: is there such a thing as a
> metaclass written in C, besides type itself? Are there metaclasses with a
> __new__ that doesn't call super().__new__ or three-argument type? If there
On Tue, Apr 26, 2022 at 4:04 AM wrote:
> Larry Hastings wrote:
> > [...]
> >
> > Now comes the one thing that we might call a "trick". The trick: when
> > we allocate the ForwardClass instance C, we make it as big as a class
> > object can ever get. (Mark Shannon assures me this is simply
> On 26 Apr 2022, at 07:32, Larry Hastings wrote:
>
>
[… snip …]
> Next we have the "continue" class statement. I'm going to spell it like this:
>
> continue class C(BaseClass, ..., metaclass=MyMetaclass):
> # class body goes here
> ...
>
> I'll mention other possible spellings
Larry Hastings wrote:
> [...]
>
> Now comes the one thing that we might call a "trick". The trick: when
> we allocate the ForwardClass instance C, we make it as big as a class
> object can ever get. (Mark Shannon assures me this is simply "heap
> type", and he knows far more about CPython
20 matches
Mail list logo
