[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On Sat, 23 Apr 2022 at 15:32, Larry Hastings wrote: > > > On 4/22/22 22:03, Chris Angelico wrote: > > Anyhow, [a forward-defined class object is] a class, with some special > features (notably that you can't instantiate it). > > Yes. Specifically, here's my intention for "forward-defined class

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/22/22 22:03, Chris Angelico wrote: Anyhow, [a forward-defined class object is] a class, with some special features (notably that you can't instantiate it). Yes.  Specifically, here's my intention for "forward-defined class objects": you can examine some generic dunder values (__name__,

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/22/22 20:58, Steven D'Aprano wrote: On Fri, Apr 22, 2022 at 06:13:57PM -0700, Larry Hastings wrote: This PEP proposes an additional syntax for declaring a class which splits this work across two statements: * The first statement is `forward class`, which declares the class and binds  

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On Sat, 23 Apr 2022 at 12:50, Larry Hastings wrote: > > > On 4/22/22 19:17, Chris Angelico wrote: > > I'm unsure about the forward class. How is it different from subclassing an > ABC? > > They're just different objects. A subclass of an ABC is either itself > another abstract base class,

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On Fri, Apr 22, 2022 at 06:13:57PM -0700, Larry Hastings wrote: > This PEP proposes an additional syntax for declaring a class which splits > this work across two statements: > * The first statement is `forward class`, which declares the class and binds >   the class object. > * The second

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/22/22 19:36, Terry Reedy wrote: On 4/22/2022 9:13 PM, Larry Hastings wrote: forward class X() New keywords are a nuisance.  And the proposed implementation seems too complex. My proposed implementation seemed necessary to handle the complexity of the problem.  I would welcome a

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/22/22 19:17, Chris Angelico wrote: I'm unsure about the forward class. How is it different from subclassing an ABC? They're just different objects.  A subclass of an ABC is either itself another abstract base class, which will never be instantiatable, or a non-abstract class, which is

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On 4/22/2022 9:13 PM, Larry Hastings wrote:     forward class X() New keywords are a nuisance. And the proposed implementation seems too complex. How about a 'regular' class statement with a special marker of some sort. Example: 'body=None'. Either __new__ or __init__ could raise

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

On Sat, 23 Apr 2022 at 11:16, Larry Hastings wrote: > This PEP proposes an additional syntax for declaring a class which splits > this work across two statements: > * The first statement is `forward class`, which declares the class and binds >the class object. > * The second statement is

[Python-Dev] Proto-PEP part 3: Closing thoughts on "forward class", etc.

Just a quick note from me on the proto-PEP and the two proposed implementations.  When I started exploring this approach, I didn't suspect it'd require such sweeping changes to be feasible. Specifically, I didn't think I was going to propose changing the fundamental mechanism used to create

[Python-Dev] Proto-PEP part 2: Alternate implementation proposal for "forward class" using a proxy object

Here's one alternate idea for how to implement the "forward class" syntax. The entire point of the "forward class" statement is that it creates the real actual class object.  But what if it wasn't actually the "real" class object?  What if it was only a proxy for the real object? In this

[Python-Dev] Proto-PEP part 1: Forward declaration of classes

This document is a loose proto-PEP for a new "forward class" / "continue class" syntax.  Keep in mind, the formatting is a mess. If I wind up submitting it as a real PEP I'll be sure to clean it up first. /arry -- PEP : Forward declaration of

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2022-04-15 - 2022-04-22) 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: open7146 ( +0) closed 51841 ( +0) total 58987 ( +0) Open issues

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On 22. 04. 22 14:47, Fabio Zadrozny wrote: Em sex., 22 de abr. de 2022 às 09:02, Petr Viktorin > escreveu: Hello Fabio, Let's talk a bit about which API should, exactly, be guaranteed to not change across minor releases. So far it looks like: -

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

Em sex., 22 de abr. de 2022 às 09:02, Petr Viktorin escreveu: > Hello Fabio, > Let's talk a bit about which API should, exactly, be guaranteed to not > change across minor releases. > So far it looks like: > - PyEval_RequestCodeExtraIndex > - PyCode_GetExtra > - PyCode_SetExtra > -

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

Hello Fabio, Let's talk a bit about which API should, exactly, be guaranteed to not change across minor releases. So far it looks like: - PyEval_RequestCodeExtraIndex - PyCode_GetExtra - PyCode_SetExtra - PyFrameEvalFunction - PyInterpreterState_GetEvalFrameFunc -