All, 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 <gu...@python.org> 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 > <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/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/