On Wed, 27 Apr 2022 at 16:04, Greg Ewing wrote:
>
> On 27/04/22 1:26 pm, Chris Angelico wrote:
> > On Wed, 27 Apr 2022 at 11:18, Greg Ewing
> > wrote:
> >>
> >> The proposed feature is analogous to forward declaring a
> >> struct in C. Would you call what C does monkeypatching?
> >>
> > No,
On 27/04/22 1:26 pm, Chris Angelico wrote:
On Wed, 27 Apr 2022 at 11:18, Greg Ewing wrote:
The proposed feature is analogous to forward declaring a
struct in C. Would you call what C does monkeypatching?
No, because C doesn't have first-class types, much less mutable ones.
The purpose of
On 27/04/22 11:07 am, Chris Angelico wrote:
You're saying that it's somehow different when the original dev
intends for it, and that that makes it "not monkeypatching". I dispute
that, and I consider that the feature would be helpful whether the
original dev meant for it or not.
The forward
On Tue, Apr 26, 2022 at 7:24 PM Greg Ewing
wrote:
> On 27/04/22 2:01 am, Chris Angelico wrote:
> > That would be the case if monkeypatching were illegal. Since it's not,
> > wherein lies the difference?
>
> The proposed feature is analogous to forward declaring a
> struct in C. Would you call
On Wed, 27 Apr 2022 at 11:18, Greg Ewing wrote:
>
> On 27/04/22 2:01 am, Chris Angelico wrote:
> > That would be the case if monkeypatching were illegal. Since it's not,
> > wherein lies the difference?
>
> The proposed feature is analogous to forward declaring a
> struct in C. Would you call
On 27/04/22 2:01 am, Chris Angelico wrote:
That would be the case if monkeypatching were illegal. Since it's not,
wherein lies the difference?
The proposed feature is analogous to forward declaring a
struct in C. Would you call what C does monkeypatching?
--
Greg
On Wed, 27 Apr 2022 at 08:06, Greg Ewing wrote:
>
> On 27/04/22 1:04 am, Joao S. O. Bueno wrote:
> > MonkeyPatching in Python is not illegal in this sense.
>
> I'm not suggesting it is. You're seizing on the wrong part
> of the analogy. The point is that what you call something
> doesn't change
On 27/04/22 1:04 am, Joao S. O. Bueno wrote:
MonkeyPatching in Python is not illegal in this sense.
I'm not suggesting it is. You're seizing on the wrong part
of the analogy. The point is that what you call something
doesn't change its nature.
--
Greg
Apr 26, 2022 20:32:55 Eric V. Smith :
How would runtime consumers of annotations use this?
--
Eric
On Apr 26, 2022, at 12:05 PM, Thomas Kehrenberg
wrote:
If the problem is mostly type annotations, then another potential
solution would be to make use of .pyi files, which are not
> On Apr 26, 2022, at 3:05 PM, Thomas Kehrenberg wrote:
>
>
> Apr 26, 2022 20:32:55 Eric V. Smith :
>
>> How would runtime consumers of annotations use this?
>>
>> --
>> Eric
>>
On Apr 26, 2022, at 12:05 PM, Thomas Kehrenberg wrote:
>>>
>>> If the problem is mostly type
How would runtime consumers of annotations use this?
--
Eric
> On Apr 26, 2022, at 12:05 PM, Thomas Kehrenberg wrote:
>
> If the problem is mostly type annotations, then another potential
> solution would be to make use of .pyi files, which are not hamstrung by
> circular definitions. The
If the problem is mostly type annotations, then another potential
solution would be to make use of .pyi files, which are not hamstrung by
circular definitions. The idea would be that type checkers would merge
the annotations from .pyi files into the annotations in the
corresponding .py file.
So:
On Tue, 26 Apr 2022 at 22:56, Greg Ewing wrote:
>
> On 26/04/22 12:33 pm, Chris Angelico wrote:
> > That's exactly what I mean though: if the only difference between
> > "monkeypatching" and "not monkeypatching" is whether it was intended,
> > then the only difference is what you call it.
>
> No,
On Tue, Apr 26, 2022 at 9:55 AM Greg Ewing
wrote:
> On 26/04/22 12:33 pm, Chris Angelico wrote:
> > That's exactly what I mean though: if the only difference between
> > "monkeypatching" and "not monkeypatching" is whether it was intended,
> > then the only difference is what you call it.
>
>
On 26/04/22 12:33 pm, Chris Angelico wrote:
That's exactly what I mean though: if the only difference between
"monkeypatching" and "not monkeypatching" is whether it was intended,
then the only difference is what you call it.
No, it's not just a matter of what you call it.
If I lose my keys
On Tue, Apr 26, 2022 at 12:33 AM Mehdi2277 wrote:
> The forward class annotations would not need need to be processed at
> runtime and could be no-ops.
>
> forward class A:
> x: int
> y: list[int]
>
>
So, as I"ve written before, since there seems to be no way out of Writing
Everything Twice
The forward class annotations would not need need to be processed at runtime
and could be no-ops.
forward class A:
x: int
y: list[int]
A.__annotations__ could be empty. For a more complete example you could have,
forward class A:
value: B # This annotation is solely for type checker and
The problem comes solely from runtime introspection of type annotations. Static
typing does not need this nor do any exceptional cases occur. From
mypy/pyright/other type checker perspective there is not an issue to solve
here. dataclasses, pydantic, cattrs, click, and other libraries that
One reason I dislike this whole proposal is that I can see forward
declarations (FDs) ending up in code that doesn't need them. This could
happen if
(a) The FDs were needed at some point, but then the type
declarations were taken out. This could happen with someone modifying
their own
On 4/25/2022 9:13 PM, Mehdi2277 wrote:
We could have forward part include all of method signatures/attributes which is
what a type checker needs. In theory we could do,
forward class Foo:
x: int
y: list[str]
def __init__(self, ...)
def process(self, data: list[float]) ->
We could have forward part include all of method signatures/attributes which is
what a type checker needs. In theory we could do,
forward class Foo:
x: int
y: list[str]
def __init__(self, ...)
def process(self, data: list[float]) -> float: ...
and then later do continue class. If
On 4/25/2022 1:10 PM, Jim J. Jewett wrote:
(That said, my personal opinion is that this is pretty heavyweight for very
little gain; why not just create a placeholder class that static analysis tools
are supposed to recognize as likely-to-be-replaced later? And why not just
use strings
On Tue, 26 Apr 2022 at 10:05, Greg Ewing wrote:
>
> On 23/04/22 5:44 pm, Chris Angelico wrote:
> > On Sat, 23 Apr 2022 at 15:32, Larry Hastings wrote:
> >>
> >> Still, it's not the intent of my PEP to condone or facilitate
> >> monkeypatching.
> >>
> >
> > The only difference is that you call
On 23/04/22 6:41 pm, Mehdi2277 wrote:
If it's allowed that a forward class may be continued in a different module I do not see how type checker like mypy/pyright could handle that. Classes are generally viewed as closed and fully defined within type checker.
The way this kind of thing works in
On 23/04/22 5:44 pm, Chris Angelico wrote:
On Sat, 23 Apr 2022 at 15:32, Larry Hastings wrote:
Still, it's not the intent of my PEP to condone or facilitate monkeypatching.
The only difference is that you call it something
different.
To me, monkeypatching means modifying the definition
On 23/04/22 10:10 pm, Terry Reedy wrote:
'forward class' for an incomplete class is not at all clear to me. It
is not clear to me which part of speech you intend it to be: noun, verb,
adjective, or adverb. You must have some experience with 'forward' in a
different context that makes it
On 23/04/22 7:22 pm, Steven D'Aprano wrote:
He said that could be
used as a very primitive form of separation of interface and
implementation, by putting the `forward class` in one module and the
`continue` in another.
But that only works if there is some way to define the interface
of the
On Sat, Apr 23, 2022 at 2:39 PM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> UGH!
>
I understand you don't like the proposal, but do please try to keep it
civil. It's totally okay to say you don't like something, but I don't think
anyone would take kindly to someone coming up to
There is an important difference between monkeypatching in general, vs
monkey-patching an object that was explicitly marked and documented as
expecting a monkeypatch.
(That said, my personal opinion is that this is pretty heavyweight for very
little gain; why not just create a placeholder
I guess Carl's messages put an end to this proposal as it is.
>From "the language side", I can think of nothing short of actually
transforming _in place_ (like it is possible with instances of
ordinary classes when you assign then a new "__class__") the
"forward referenced object" into the
On Sun, Apr 24, 2022 at 10:20 AM Joao S. O. Bueno wrote:
>
> I am not worried about the bikeshed part of which syntax to use -
> and more worried with the possible breaking of a lot of stuff, unless
> we work with creation of a non-identical "forward object" that is
> rebound, as in plain name
I am not worried about the bikeshed part of which syntax to use -
and more worried with the possible breaking of a lot of stuff, unless
we work with creation of a non-identical "forward object" that is
rebound, as in plain name binding, when the second part
is declared. I've stated that amidst my
Hi Larry,
On Sat, Apr 23, 2022 at 1:53 AM Larry Hastings wrote:
> But rather than speculate further, perhaps someone who works on one of the
> static type analysis checkers will join the discussion and render an informed
> opinion about how easy or hard it would be to support "forward class"
On 4/24/2022 5:42 AM, Stephen J. Turnbull wrote:
What's the use case for arbitrary expressions vs. a (possibly
qualified) name? A class factory that produces forward declarations?
Do you have a use case in mind?
It's:
x.py:
--8<
forward class A()
--8<
x_impl.py
Larry Hastings writes:
> On 4/22/22 19:36, Terry Reedy wrote:
> > How about a 'regular' class statement with a special marker of some
> > sort. Example: 'body=None'.
>
> It's plausible. I take it "body=None" would mean the declaration would
> not be permitted to have a colon and a
On Sat, Apr 23, 2022 at 7:10 PM Paul Moore wrote:
> On Sat, 23 Apr 2022 at 22:42, Rob Cliffe via Python-Dev
> wrote:
> >
> > UGH!
> >
> > I thought there was a general understanding that when typing was added
> > to Python, there would be no impact, or at least minimal impact, on
> > people who
On Sat, 23 Apr 2022 at 22:42, Rob Cliffe via Python-Dev
wrote:
>
> UGH!
>
> I thought there was a general understanding that when typing was added
> to Python, there would be no impact, or at least minimal impact, on
> people who didn't use it. (Raises hand.)
> Now we see an(other) instance of
UGH!
I thought there was a general understanding that when typing was added
to Python, there would be no impact, or at least minimal impact, on
people who didn't use it. (Raises hand.)
Now we see an(other) instance of intention creep.
Rob Cliffe
On 23/04/2022 02:13, Larry Hastings wrote:
On 4/23/22 08:57, Eric V. Smith wrote:
On 4/23/2022 9:55 AM, Jelle Zijlstra wrote:
However, it doesn't solve the problem for base classes. For example,
str is conceptually defined as `class str(Sequence["str"]):`. A
forward reference can't make `str` defined when the bases are
evaluated,
On 4/23/22 06:55, Jelle Zijlstra wrote:
So to reiterate, your proposal would be to write this as:
forward class B:
pass
class A:
value: B
continue class B:
value: A
Not quite; the "forward class" statement doesn't have a colon or a class
body. This would be written as:
On 4/23/2022 9:55 AM, Jelle Zijlstra wrote:
However, it doesn't solve the problem for base classes. For example,
str is conceptually defined as `class str(Sequence["str"]):`. A
forward reference can't make `str` defined when the bases are
evaluated, because bases are resolved at the `forward
On 4/23/2022 3:28 AM, Tobias HT wrote:
On the other hand, there's something I've been seeing around. I don't
know if it was introduced by Mypy or something, but its the use of
declaration files. I think they are saved as pyi files. They just have
the declaration of a python object, be it
This seems like it would solve a huge problem that I've often faced myself,
but by introducing something that might later on cause problems I
anticipate.
Like some people suggested earlier, introducing new keyword in python is
not a good solution, I feel it just adds to the already existing bulk
I don't think this proposal is a good solution for the problems of static
typing users.
El vie, 22 abr 2022 a las 18:16, Larry Hastings ()
escribió:
> But the explosion of static type analysis in Python, particularly with
> the `typing` module and the `mypy` tool, has made circular
I should have said "numpy_forward", not "numpy.forward". I changed my mind
at the last second as I was writing that email, and momentarily forgot that
when you import x.y you implicitly import x.
/arry
On Sat, Apr 23, 2022, 01:53 Larry Hastings wrote:
>
> On 4/23/22 01:14, Steven D'Aprano
On 4/23/22 03:10, Terry Reedy wrote:
On 4/22/2022 11:16 PM, Larry Hastings wrote:
So I still prefer "forward class".
I don't think it's as clear as "forward class"
'forward class' for an incomplete class is not at all clear to me. It
is not clear to me which part of speech you intend it
On 4/22/2022 11:16 PM, Larry Hastings wrote:
So I still prefer "forward class".
I don't think it's as clear as "forward class"
'forward class' for an incomplete class is not at all clear to me. It
is not clear to me which part of speech you intend it to be: noun, verb,
adjective, or
On 4/23/22 01:14, Steven D'Aprano wrote:
On Sat, Apr 23, 2022 at 12:46:37AM -0700, Larry Hastings wrote:
But rather than speculate further, perhaps someone who works on one of
the static type analysis checkers will join the discussion and render an
informed opinion about how easy or hard it
On 4/23/22 00:53, Steven D'Aprano wrote:
It's a "forward-declared class object". It's the real class object, but
it hasn't been fully initialized yet, and won't be until the "continue
class" statement.
The only thing that makes it not fully initialised is that it has a bozo
bit dunder
On Sat, Apr 23, 2022 at 12:46:37AM -0700, Larry Hastings wrote:
> But rather than speculate further, perhaps someone who works on one of
> the static type analysis checkers will join the discussion and render an
> informed opinion about how easy or hard it would be to support "forward
> class"
On Fri, Apr 22, 2022 at 10:09:33PM -0700, Larry Hastings wrote:
[Larry]
> >>To be clear: `forward class` creates the official, actual class object.
> >>Code that wants to take a reference to the class object may take
> >>references
> >>to the `forward class` declared class, and interact with it
On 4/22/22 23:41, Mehdi2277 wrote:
My main question for this approach is how would this work with type checkers?
It would be new syntax for Python, so type checkers would have to
understand it.
Is there any restriction that forward class's continuation must appear in same
module?
No.
On Sat, Apr 23, 2022 at 06:41:23AM -, Mehdi2277 wrote:
> My main question for this approach is how would this work with type
> checkers? Is there any restriction that forward class's continuation
> must appear in same module? If it's allowed that a forward class may
> be continued in a
My main question for this approach is how would this work with type checkers?
Is there any restriction that forward class's continuation must appear in same
module? If it's allowed that a forward class may be continued in a different
module I do not see how type checker like mypy/pyright could
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
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__,
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
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,
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
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
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
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
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
63 matches
Mail list logo
