[Python-ideas] New Python syntax for continuing definitions for existing classes

[nate lust]

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 <guido at 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.schellart at 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 at gmail.com> wrote:
> >>
> >> On 14 September 2016 at 05:46, Ralph Broenink <ralph at ralphbroenink.net>
> wrote:
> >>> Hi all,
> >>>
> >>> On Tue, 13 Sep 2016 at 18:30 Chris Angelico <rosuav at 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 at gmail.com   |   Brisbane, Australia
> >> _______________________________________________
> >> Python-ideas mailing list
> >> Python-ideas at python.org
> >> https://mail.python.org/mailman/listinfo/python-ideas
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160914/567b3d90/attachment-0001.html>