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

[Steven D'Aprano]

On Fri, Feb 10, 2017 at 12:11:46PM -0600, Steve Dower wrote:

> When you apply the "what if everyone did this" rule, it looks like a 
> bad idea (or alternatively, what if two people who weren't expecting 
> anyone else to do this did it).

When you apply that rule, Python generally fails badly. In theory, 
Python is the worst possible language to be programming in, because the 
introspection capabilities are so powerful, the data hiding so feeble, 
the dynamicism of the language so great that almost anything written in 
pure-Python can be poked and prodded, bits deleted and new bits 
inserted. Python doesn't even have constants!!!

import math
math.pi = 3.0 # change the very geometry of spacetime


And yet, in practice this is a problem more in theory than in practice. 
While you are right to raise this as a possible disadvantage of the 
proposal ("may ever-so-slightly encourage monkey-patching, by making it 
seem ever-so-slightly less mucky") I don't think you are right to weigh 
it as heavily as you appear to be doing.

Python has had setattr() forever, and the great majority of Python 
programmers manage to avoid abusing it.


> Monkeypatching is fairly blatantly taking advantage of the object 
> model in a way that is not "supported" and cannot behave well in the 
> context of everyone doing it, whereas inheritance or mixins are safe.

That's an extremely optimistic view of things.

Guido has frequently eluded to the problems with inheritance (you can't 
just inherit from anything and expect your code to work), and he's 
hardly the only one that has pointed out that inheritance and OOP hasn't 
turned out to be the panacea that people hoped. As for mixins, Michele 
Simionato has written a series of blog posts about the dangers of mixins 
and multiple inheritance, and suggesting traits as a more restricted and 
safer alternative. Start here:

http://www.artima.com/weblogs/viewpost.jsp?thread=246488

 
> 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


> (The extension_method decorator 
> sends exactly the wrong message about what it's doing.)

Are you refering to a decorator something like this?

@extend(TheClass)
def method(self, arg):
    ...

assert TheClass.method is method

Arguments about what it should be called aside, what is the wrong 
message you see here?


> Enabling a __class__ variable within the scope of the definition would 
> also solve the motivating example, 

Can you elaborate on that a bit more?

Given the current idiom for injecting a method:

class MyClass:
    ...

# Later on...
def method(self, arg):
   ...

MyClass.method = method
del method


where does the __class__ variable fit into this?




-- 
Steve