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?
Pim Schellart & Nate Lust
On 14 Sep 2016, at 08:02, Nick Coghlan email@example.com wrote:
On 14 September 2016 at 05:46, Ralph Broenink firstname.lastname@example.org wrote:
On Tue, 13 Sep 2016 at 18:30 Chris Angelico email@example.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:
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: 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:
- 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
-- Nick Coghlan | firstname.lastname@example.org | Brisbane, Australia _______________________________________________ Python-ideas mailing list Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/