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

[Pim Schellart]

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/