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.schell...@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 <ncogh...@gmail.com> wrote: >> >> On 14 September 2016 at 05:46, Ralph Broenink <ra...@ralphbroenink.net> >> wrote: >>> Hi all, >>> >>> On Tue, 13 Sep 2016 at 18:30 Chris Angelico <ros...@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 | ncogh...@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/
