Thoughts about Python
PPNTWIMBXFFC at spammotel.com
Tue Feb 24 22:14:12 CET 2004
> > *** Problem: clumsy static class methods
> See PEP 318 (and current discussion on python-dev).
Thanks for the hint.
> > class c (object):
> > def staticMethod(arg1, arg2, ...):
> > # self is not handed in... hence I can't use the instance vars
> > pass
> > def normalMethod(self, arg1, arg2, ...):
> > pass
> What's so special about self? I really don't like the idea of
> argument names keying this kind of change in behaviour.
One gets to get used to passing in self into class member functions.
It is there and I learned to live with it (self). What separates a
static method from a non-static-method is its (var) context. A static
method is not allowed to use instance vars. This can be easily
achieved by dropping the self-arg in the method definition... but as I
can see by browsing through PEP 318: A lot of "decorators" are wished
and this proposal only "solves" the static method case. Forget about
it - it was just a thought.
> > *** Problem: clumsy properties for classes
> > My proposal:
> > all getters start with __get__
> > all setters start with __set__
> > all deleters start with __del__
> You seem really fond of magic names...
No, it uses an idea that Python uses in many places: __len__ is used
with the len-function, __init__ is used when a class is instantiated,
__getitem__ is used with , etc. etc. so why not use the same scheme
for class properties. But I can live with you saying:
> I hope you're not too offended if I
> say that your suggestion doesn't seem instantly wonderful.
No problem. 8o)
> > *** Problem: Many builtins are not necessary
> Pah. So what? If you want minimailty scheme is over there ====>
No, I am not asking for minimality. I am asking for a clean design - a
string has a length therefore a string has the method len(). How many
"object oriented" languages do you know that give you the size/length
of an object by calling an external function? Except for Python I know
no other... and I know: Java, C++, Ruby (and others but not so object
> > Many builtins are not necessary. To name a few: min / max / len
> > This functions should be defined on the class:
> Says you!
Yeah, thanks for the convincing arguments against it. 8o)
> > *** Problem: tuples are not necessary
> Says you! Here's a hint: hash().
I suppose this is the argument: list are not immutable that is why
they cannot be used a dict key... I wonder how many people use a tuple
as dict key. This seems to be a common practice to justify its own
"type". I admit, I can think of simple workarounds when there wouldn't
be tuples (eg. Instead of transforming a list into tuple why not
transforming it into a string).
> I think you might be expecting something other of Python than what it
> is. Nothing you suggest is completely ridiculous, just, well,
> slightly un-Pythonic.
un-Pythonic... this bytes ... hmm... why? Reading your comments it
does not justify such a hard judgment - or does it?
Thanks anyway for your response and the hint for PEP 318,
More information about the Python-list