[Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

[Nick Coghlan]

On 12 February 2017 at 12:38, Paul Moore <p.f.moore at gmail.com> wrote:
> On 12 February 2017 at 04:37, Steven D'Aprano <steve at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia