On 12 February 2017 at 12:38, Paul Moore <p.f.mo...@gmail.com> wrote: > On 12 February 2017 at 04:37, Steven D'Aprano <st...@pearwood.info> wrote: >>> Making a dedicated syntax or decorator for patching is saying that we >>> (the language) think you should do it. >> >> We already have that syntax: >> >> anything.name = thing > > And the point here is that we don't need to extend def, because we > already have that syntax. Adding new syntax for something that we can > already do is generally accepted when the "thing we can already do" is > deemed sufficiently important that it's worth making it a language > feature in its own right. Decorators are a prime example of this - > before the decorator syntax was added, decorating functions was just > something that people occasionally did, but it wasn't a specific > "concept".
Note that true method injection would *NOT* be the same as binding a callable as a class attribute after the fact: - attribute assignment doesn't modify __name__ - attribute assignment doesn't modify __qualname__ - attribute assignment doesn't call __set_owner__ - attribute assignment doesn't adjust the __class__ cell reference Any method injection syntax worthy of the name would need to do those things (probably via a new __setdescriptor__ magic method that is a counterpart to PEP 447's __getdescriptor__). > I'd argue that method injection (to use your phrase) isn't > sufficiently important to warrant promotion to language syntax. There's a lot to be said for implementing mixin behaviour by way of definition time method injection rather than via MRO traversal when looking up method names (although __init_subclass__ took away one of the arguments in favour of it, since mixins can check their invariants at definition time now). > I will say, though, that you're right that we've over-reacted a bit to > the monkeypatching use case. Although maybe that's because no-one can > think of many *other* use cases that they'd need the new syntax for > :-) Method injection is most attractive to me as a potential alternative to mixin classes that has fewer runtime side effects by moving more of the work to class definition time. More philosophically though, it offends my language design sensibilities that we have so much magic bound up in class definitions that we don't expose for procedural access post-definition time - there's a whole lot of behaviours that "just happen" when a method is defined lexically inside a class body that can't readily be emulated for callables that are defined outside it. However, even with that, I'm still only +0 on the idea - if folks really want it, `types.new_class` can already be used to creatively to address most of these things, and it's not exactly a problem that comes up very often in practice. 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/
