Mailing List Archive

On Tue, Apr 26, 2022 at 9:55 AM Greg Ewing <greg.ewing@canterbury.ac.nz>
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, it's not just a matter of what you call it.
>
> If I lose my keys and have to break into my house, it's not
> illegal. But if someone else breaks into my house without my
> permission, that is illegal. It doesn't matter if the thief
> *calls* it legal, there's still a difference.
>


MonkeyPatching in Python is not illegal in this sense.

As was put in this thread: let's not criminalize people
for mutating mutable objects.

btw, wether to call certain aspects of one of
the options for this proposal "monkeypatching" or not,
is a discussion that IMHO is far, far beyond bike-shedding.



>
> --
> Greg
>
>

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:

a.py:

from b import B

class A:
value: B

b.py:

class B:
value = None

b.pyi:

from typing import Optional
from a import A

class B:
value: Optional[A] = ...

The pyi files would kind of act like header files that are used in other
languages. It would mean that type checkers need to check the .pyi
files against the code in the .py files to verify that they're
consistent with one another.

-thomas
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VWPWN5KWTRPP6VS4PEHJA4SRVMUDU5WR/
Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, 26 Apr 2022 at 22:56, Greg Ewing <greg.ewing@canterbury.ac.nz> 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, it's not just a matter of what you call it.
>
> If I lose my keys and have to break into my house, it's not
> illegal. But if someone else breaks into my house without my
> permission, that is illegal. It doesn't matter if the thief
> *calls* it legal, there's still a difference.
>

That would be the case if monkeypatching were illegal. Since it's not,
wherein lies the difference?

ChrisA
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4FZTF4TIQY7CEZCQX4FLKS2JOUWZGQ5P/
Code of Conduct: http://python.org/psf/codeofconduct/

How would runtime consumers of annotations use this?

--
Eric

> On Apr 26, 2022, at 12:05 PM, Thomas Kehrenberg <tmke@posteo.net> 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 idea would be that type checkers would merge
> the annotations from .pyi files into the annotations in the
> corresponding .py file.
>
> So:
>
> a.py:
>
> from b import B
>
> class A:
> value: B
>
> b.py:
>
> class B:
> value = None
>
> b.pyi:
>
> from typing import Optional
> from a import A
>
> class B:
> value: Optional[A] = ...
>
> The pyi files would kind of act like header files that are used in other
> languages. It would mean that type checkers need to check the .pyi
> files against the code in the .py files to verify that they're
> consistent with one another.
>
> -thomas
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VWPWN5KWTRPP6VS4PEHJA4SRVMUDU5WR/
> Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2VNYLOHCXWBUYTWRGRJC6C4LXQVF45MD/
Code of Conduct: http://python.org/psf/codeofconduct/

Apr 26, 2022 20:32:55 Eric V. Smith <eric@trueblade.com>:

> How would runtime consumers of annotations use this?
>
> --
> Eric
>
>> On Apr 26, 2022, at 12:05 PM, Thomas Kehrenberg <tmke@posteo.net>
>> 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 idea would be that type checkers would
>> merge
>> the annotations from .pyi files into the annotations in the
>> corresponding .py file.
>>
>> So:
>>
>> a.py:
>>
>>    from b import B
>>
>>    class A:
>>        value: B
>>
>> b.py:
>>
>>    class B:
>>        value = None
>>
>> b.pyi:
>>
>>    from typing import Optional
>>    from a import A
>>
>>    class B:
>>        value: Optional[A] = ...
>>
>> The pyi files would kind of act like header files that are used in
>> other
>> languages.  It would mean that type checkers need to check the .pyi
>> files against the code in the .py files to verify that they're
>> consistent with one another.
>>
>> -thomas
>> _______________________________________________
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-leave@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/VWPWN5KWTRPP6VS4PEHJA4SRVMUDU5WR/
>> Code of Conduct: http://python.org/psf/codeofconduct/
They wouldn't. But I thought PEP 649 solves the runtime problems,
and that the remaining problems are with static typing
of circular definitions.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LHHE7HPSKNT6UAQGSZPCMU5XJATAARRB/
Code of Conduct: http://python.org/psf/codeofconduct/

> On Apr 26, 2022, at 3:05 PM, Thomas Kehrenberg <tmke@posteo.net> wrote:
>
> ?
> Apr 26, 2022 20:32:55 Eric V. Smith <eric@trueblade.com>:
>
>> How would runtime consumers of annotations use this?
>>
>> --
>> Eric
>>
>>>> On Apr 26, 2022, at 12:05 PM, Thomas Kehrenberg <tmke@posteo.net> 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 idea would be that type checkers would merge
>>> the annotations from .pyi files into the annotations in the
>>> corresponding .py file.
>>>
>>> So:
>>>
>>> a.py:
>>>
>>> from b import B
>>>
>>> class A:
>>> value: B
>>>
>>> b.py:
>>>
>>> class B:
>>> value = None
>>>
>>> b.pyi:
>>>
>>> from typing import Optional
>>> from a import A
>>>
>>> class B:
>>> value: Optional[A] = ...
>>>
>>> The pyi files would kind of act like header files that are used in other
>>> languages. It would mean that type checkers need to check the .pyi
>>> files against the code in the .py files to verify that they're
>>> consistent with one another.
>>>
>>> -thomas
>>> _______________________________________________
>>> Python-Dev mailing list -- python-dev@python.org
>>> To unsubscribe send an email to python-dev-leave@python.org
>>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>>> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VWPWN5KWTRPP6VS4PEHJA4SRVMUDU5WR/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
> They wouldn't. But I thought PEP 649 solves the runtime problems,
> and that the remaining problems are with static typing
> of circular definitions.

If the class needs access to its own type annotations at runtime (for example, if it’s a dataclass), then the circular reference problem still exists with PEP 649. That’s among the cases we’re trying to resolve.

Eric


_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SV37AN7HYQNAVIE2BMJ5C5AC77FENTCS/
Code of Conduct: http://python.org/psf/codeofconduct/

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
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WFVAWIKBQF72KW2IHOERP2DIKD5ECO7N/
Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, 27 Apr 2022 at 08:06, Greg Ewing <greg.ewing@canterbury.ac.nz> 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 its nature.
>

I agree. So why is it monkeypatching sometimes, and not other times?
Why are you distinguishing? To be clear, this is what I'm responding
to:

On Tue, 26 Apr 2022 at 10:05, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
> To me, monkeypatching means modifying the definition of something
> after the fact in a way that it wasn't designed for.
>
> Here, the modification is fully intended, so it's not monkeypatching.

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.

Consider what Python would be like if every class had to declare
whether it was allowed to be subclassed or not. Would subclassing
therefore become legitimate if the original author intended for it,
and be called "method stealing" if it were not? Would that materially
improve the language? I have frequently subclassed something without
the "consent" of the original class's author, because it is a useful
feature.

Python is a "consenting adults" language. If you do something the
original author didn't intend, you might find yourself running into
backward compatibility issues, but you shouldn't have the language
block you unnecessarily.

ChrisA
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2BGUHWOUNJTVETANBVJPCVPQZ43IVA57/
Code of Conduct: http://python.org/psf/codeofconduct/

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
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5DRJG3CGCLHJSXBD6ILPHROX6LBIDCHK/
Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, 27 Apr 2022 at 11:18, Greg Ewing <greg.ewing@canterbury.ac.nz> 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 what C does monkeypatching?
>

No, because C doesn't have first-class types, much less mutable ones.
It doesn't make sense to compare them. The proposed feature is an
alternative way to add attributes to an existing class object, which
we normally call monkeypatching, but you're saying that sometimes it
isn't. I'm still confused as to why you consider there to be a
difference.

According to this proposal, it is entirely possible to continue a
class more than once, with just some fiddling with dunders. But what
you're saying is that sometimes that's monkeypatching and a bad thing,
and other times it's a good thing and not monkeypatching. I say that
it's always monkeypatching, and always a good thing.

ChrisA
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5UYWIKP5PUHDRAE6APVHMBWIAVQYZTH3/
Code of Conduct: http://python.org/psf/codeofconduct/

On Tue, Apr 26, 2022 at 7:24 PM Greg Ewing <greg.ewing@canterbury.ac.nz>
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 what C does monkeypatching?
>

It is not analogous; it is a false analogy that obscures the issues with
this proposal in Python.

A C forward declaration (not to mention the full struct declaration also!)
is purely for the compiler; at runtime one can have a pointer to some
memory that the compiler expects to be shaped like that struct, but one can
never get hold of any runtime value that is “the struct definition itself,”
let alone a runtime value that is the nascent forward-declared
yet-to-be-completed struct. So clearly there can be no patching of
something that never exists at runtime at all.

Python is quite different from C in this respect. Classes are runtime
objects, and so is the “forward declared class” object. The proposal is for
a class object to initially at runtime be the latter, and then later (at
some point that is not well defined if the implementation is in a separate
module, because global module import ordering is an unstable emergent
property of all the imports in the entire codebase) may suddenly,
everywhere and all at once, turn into the former. Any given module that
imports the forward declared name can have no guarantee when (if ever) that
object will magically transform into something that is safe to use.

Whether we call it monkeypatching or not is irrelevant. Having global
singleton objects change from one thing to a very different thing, at an
unpredictable point in time, as a side effect of someone somewhere
importing some other module, causes very specific problems in being able to
locally reason about code. I think it is more useful to discuss the
specific behavior and its consequences than what it is called.

Carl

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 declaration and continuation both have to be specially
marked, so you *can't* use it for monkeypatching.

> Would subclassing
> therefore become legitimate if the original author intended for it,
> and be called "method stealing" if it were not?

You seem to think I have something against monkeypatching. Personally
I don't, but someone else seems to as they objected that they don't
want monkeypatching to be encouraged. I was just pointing out that
(1) I don't think it's the same thing as monkeypatching and (2)
you can't use it to modify an existing class in an ad-hoc manner
anyway.

--
Greg

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6HOFAR3TKR62YFPUZ4OIBY5DJBNV374V/
Code of Conduct: http://python.org/psf/codeofconduct/

On 27/04/22 1:26 pm, Chris Angelico wrote:
> On Wed, 27 Apr 2022 at 11:18, Greg Ewing <greg.ewing@canterbury.ac.nz> 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 a forward declaration, in any language, is to
allow a name to be used before it's fully defined. Mutability
or first-classness of types has nothing to do with it.

> According to this proposal, it is entirely possible to continue a
> class more than once, with just some fiddling with dunders.

No, it's not. As has been explained upthread, stuff is done
when finalising a class that can't be repeated.

> But what
> you're saying is that sometimes that's monkeypatching and a bad thing,
> and other times it's a good thing and not monkeypatching.

No, I'm saying that the proposed feature is not monkeypatching
because it does not and cannot be used to modify an existing
class.

--
Greg
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SVZPAEBDIGHR2TADKCOXND4S3RPKXAMY/
Code of Conduct: http://python.org/psf/codeofconduct/

On Wed, 27 Apr 2022 at 16:04, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>
> On 27/04/22 1:26 pm, Chris Angelico wrote:
> > On Wed, 27 Apr 2022 at 11:18, Greg Ewing <greg.ewing@canterbury.ac.nz> 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 a forward declaration, in any language, is to
> allow a name to be used before it's fully defined. Mutability
> or first-classness of types has nothing to do with it.

The ONLY thing you can do in C without the full structure definition
is to declare a pointer to it. It has all the functionality of a void
pointer (ie basically none), but you know it's a pointer to this
undefined type. Python simply doesn't have an equivalent, since there
is no concept of typed pointers, but the nearest equivalent would be
making it legal in type hints.

Python DOES, however, have first-class types. They are real objects
and can be examined at run-time. This proposed feature isn't analogous
to C's structs, since C types its variables rather than its objects.

> > According to this proposal, it is entirely possible to continue a
> > class more than once, with just some fiddling with dunders.
>
> No, it's not. As has been explained upthread, stuff is done
> when finalising a class that can't be repeated.

From the OP:

On Sat, 23 Apr 2022 at 11:16, Larry Hastings <larry@hastings.org> wrote:
> #### Semantics of forward-declared class objects
> ...
> However, the user isn't permitted to instantiate a forward-declared
> class object until after the corresponding `continue class X`.
> We ensure this with a new dunder attribute, `__forward__`,
> which if present tells the Python runtime that this is a
> forward-declared class object. The `continue class` statement
> would delete this attribute from the object, after which it
> could be instantiated.
>
> (Users could work around this constraint, or even delete `__forward__`
> if they so chose--again, the "consenting adults" rule applies.)
> ...
> `continue class` may only be run on a class once.
> (As Eric V. Smith pointed out in response to an early version of
> this proposal, allowing multiple "continue" declarations on the
> same class would lead directly to language-condoned monkey-patching.)

So unless I'm horrifically misreading this, the only thing stopping
you from doing multiple continues is this attribute which says that
it's a forward-declared class. Removing this would allow you to work
around this constraint, which exists solely to avoid the perception of
"language-condoned monkey-patching".

The proposal explicitly lays out that a forward-declared class IS a
class, and can be used in a number of basic ways (but can't be
instantiated). The "continue class" statement removes this flag, but
you can mess with that flag and re-continue a class, or instantiate a
non-completed class.

ChrisA
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7CVJPKQ53K2BOQ4KOOXWLZ7LOX4G2NQH/
Code of Conduct: http://python.org/psf/codeofconduct/