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 email@example.com 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 firstname.lastname@example.org wrote:
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
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
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
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,
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
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/
Python-ideas mailing list Pythonfirstname.lastname@example.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 Pythonemail@example.com https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/