I must say It is still exciting to be at a point of getting an official declaration on a topic from Guido. We thank you for your time and feedback. It has been a good experience and hope to be able to contribute in some other way in the future.
Nate and Pim

On Wed, Sep 14, 2016 at 12:30 PM Guido van Rossum <> wrote:
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
<> 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
> 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 <> wrote:
>> On 14 September 2016 at 05:46, Ralph Broenink <> wrote:
>>> Hi all,
>>> On Tue, 13 Sep 2016 at 18:30 Chris Angelico <> 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:
>>> There's also this  post from Guido a few years back in python-dev, which
>>> does something similar using metaclasses:
>>> 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:
>> 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:
>> 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   |   |   Brisbane, Australia
>> _______________________________________________
>> Python-ideas mailing list
>> Code of Conduct:
> _______________________________________________
> Python-ideas mailing list
> Code of Conduct:

--Guido van Rossum (
Python-ideas mailing list
Code of Conduct: