[Python-ideas] Pseudo methods

Steven D'Aprano steve at pearwood.info
Fri Aug 4 07:32:33 EDT 2017


Hi Paul, and welcome!


On Fri, Aug 04, 2017 at 07:39:56AM +0000, Paul Laos wrote:
> Hi folks
> I was thinking about how sometimes, a function sometimes acts on classes, and
> behaves very much like a method.

I'm not really sure what you mean by "acts on classes". I can only think 
of a function which takes a class as a parameter, and modifies the 
class. Like a class decorator. Or possibly a classmethod. But that's not 
what you seem to mean below. So I'm not quite certain I understand your 
proposal.


> Adding new methods to classes existing classes
> is currently somewhat difficult,

If the class is written in Python, it isn't difficult at all, it is 
trivially easy. First define your method:

def method(self, arg):
    pass


Then inject it onto the class using ordinary attribute assignment:

TheClass.method = method

And we're done!

If the class is a built-in, or otherwise written in C, then "somewhat 
difficult" is an understatement. I think it can't be done at all.


> and having pseudo methods would make that easier.

I'm not sure that "easier" in this case would be better.


> Code example: (The syntax can most likely be improved upon)
>     def has_vowels(self: str):
>         for vowel in ["a", "e,", "i", "o", "u"]:
>             if vowel in self: return True


How does Python, and for that matter the human reader, know which 
class or classes that method is injected into? My guess is it looks at 
the annotation. But that's a big change: annotations are currently 
guaranteed to have no runtime semantics (apart from being stored in the 
function's __annotation__ attribute). I'm not saying that can't be done, 
but there may be consequences we haven't thought of.

If we say dir(str), will "has_vowels" show up?

How about vars(str)?

How does this interact with metaclasses?


 
> This allows one to wring `string.has_vowels()` instead of `has_vowels(string)`,
> which would make it easier to read, 

Well that's one opinion.


> and would make it easier to add
> functionality to existing classes, without having to extend them. This would be
> useful for builtins or imported libraries, so one can fill in "missing" methods.

http://www.virtuouscode.com/2008/02/23/why-monkeypatching-is-destroying-ruby/

I think monkeypatching is great, so long as I'm the only one that does 
it. When other people do it, invariably they introduce bugs into my code 
by monkeypatching other things I didn't expect to be monkeypatched.


> * Simple way to extend classes
> * Improves readability
> * Easy to understand

I'll agree with the first one of those, if by "simple" you mean 
"somebody else did all the work to make this syntax do 
what I want it to do".

The work behind the scenes is not likely to be simple: for starters, 
allowing monkeypatching of built-ins is likely going to require a rather 
big re-design of the Python interpreter.


-- 
Steve


More information about the Python-ideas mailing list