Thoughts about Python

[Marco Aschwanden]

> > *** 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
oriented ones).

> > 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,
Greetings,
Marco