There shall be no standard syntax for monkey-patching.

Decorators are fine. I recommend putting a monkey-patching package on
PyPI and see if people use it.

Maybe eventually it can be in the stdlib but I really don't want to
encourage this idiom (even if it's sometimes useful). You should
always consider other options (like petitioning upstream for a better
API) before accepting the need to monkey-patch.

On Wed, Sep 14, 2016 at 8:46 AM, Pim Schellart
<p.schellart@princeton.edu> wrote:
> Dear All,
>
> Thank you for your feedback!
> While we think the decorator solution is not as writable, readable or discoverable as our
> proposed syntax we understand the desire to discourage a potential
> paradigm switch to `open classes’.
>
> We recognise that in many cases refactoring the code to eliminate the need for monkey patching
> is the preferable solution. However, there are many instances where this is not the case, such as
> the one Guido described in https://mail.python.org/pipermail/python-dev/2008-January/076194.html.
>
> Personally, we have encountered the need for this in many projects each of us have worked on.
> The fact that monkey patching is common enough lexicon to be mentioned in Python programming
> books highlights the fact that programmers may encounter this in codebases they work on.
>
> In particular when using third party libraries or code written in other languages wrapped into Python,
> the existing syntaxes are less readable and non-standard.
> Each project using such codes is thus forced to come up with their own custom solution leading
> to a somewhat fractured appearance in otherwise similar Python codebases.
>
> We had hoped to come up with a standardised solution. And if new syntax is not desirable, perhaps
> including other solutions such as the proposed decorator in the standard library is an option?
> Or do you feel this is a problem that should be solved by better documentation and understanding
> instead?
>
> Kind regards,
>
> Pim Schellart & Nate Lust
>> On 14 Sep 2016, at 08:02, Nick Coghlan <ncoghlan@gmail.com> wrote:
>>
>> On 14 September 2016 at 05:46, Ralph Broenink <ralph@ralphbroenink.net> wrote:
>>> Hi all,
>>>
>>> On Tue, 13 Sep 2016 at 18:30 Chris Angelico <rosuav@gmail.com> wrote:
>>>>
>>>> Did you know that you can actually abuse decorators to do this with
>>>> existing syntax? Check out this collection of evil uses of decorators:
>>>>
>>>> https://github.com/Rosuav/Decorators/blob/master/evil.py
>>>
>>> There's also this  post from Guido a few years back in python-dev, which
>>> does something similar using metaclasses:
>>>
>>> https://mail.python.org/pipermail/python-dev/2008-January/076194.html
>>>
>>> I'm not sure it does exactly the same, but it is also an interesting
>>> approach. (Although I like the decorator syntax more.) The discussion that
>>> follows in that thread may also be of interest for this discussion.
>>
>> PEP 422 and its reference implementation had a more fleshed out
>> implementation of that concept:
>> https://www.python.org/dev/peps/pep-0422/#new-ways-of-using-classes
>>
>> With class namespaces becoming ordered by default, I ended up
>> withdrawing PEP 422 in favour of the simpler PEP 487 that's actually
>> in 3.6: https://www.python.org/dev/peps/pep-0487/
>>
>> I do think Pim's proposal is an excellent exemplar of what a PEP
>> should be, and if we *did* want to make class extension easier than it
>> already is, then the suggested "continue class ..." syntax would be an
>> elegant way of spelling it.
>>
>> However, I also believe the proposal founders on:
>>
>> 1. Class extensions are a fundamentally bad idea from a
>> maintainability perspective, as they make the original class
>> definition incomplete with no local indicator of its lack of
>> completeness (hence the "don't do this" caveat on the relevant example
>> in PEP 422)
>> 2. There are already ways to do this using metaclasses that provide a
>> local indicator at the point of definition that the affected class is
>> extensible (i.e. the use of the custom metaclass, or inheritance from
>> a base class that uses it) and hence that the given definition may be
>> incomplete
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/



--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/