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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
