Thoughts about Python

[nnes]

PPNTWIMBXFFC at spammotel.com (Marco Aschwanden) wrote in message news:<15c2d03b.0402240311.395f5382 at posting.google.com>...
> Hi
> 
> I don't have to talk about the beauty of Python and its clear and
> readable syntax... but there are a few things that striked me while
> learning Python.
> 
> I have collected those thoughts. I am sure there are many discussions
> on the "problems" mentioned here. But I had this thoughts without
> looking into any forums or anything... it is kind of feedback.
> 
> Thanks for this marvellous language,
> Marco
> 
> 
> 
> *** Problem: clumsy static class methods
> 
> In order to create a static method we have to use a the builtin
> staticmethod(function):
> 
> class C (object):
>     def f(arg1, arg2, ...): ...
>     f = staticmethod(f)
> 
> Why? The speciality of a "static" method is: It has no access to any
> instance vars. The following class is easier to read and understand
> what a static method is about... as a positive side-effect: self is
> not available and it can't be used!
> 
> 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
> 
> There is no need for the builtin... as I understand it: the builtin is
> a workaround...
> 
> 
> 
> *** Problem: clumsy properties for classes
> 
> property( [fget[, fset[, fdel[, doc]]]]) 
> 
> class C(object):
>     def getx(self): return self.__x
>     def setx(self, value): self.__x = value
>     def delx(self): del self.__x
>     x = property(getx, setx, delx, "I'm the 'x' property.")
> 
> 
> I don't like this one either. It is not necessary because it describes
> something that should be clear by looking at the class/code. A
> convention would make the syntax clearer and more intuitive and by
> looking at the definition of a method you would know: This is a
> getter, setter or deleter. My proposal:
> 
> all getters start with __get__
> all setters start with __set__
> all deleters start with __del__
> 
> If someone uses:
> 
> prop.x = 5
> 
> Python checks whether the var 'x' exists on prop. If it does - it is
> set. If it doesn't exist Python checks for '__set__x' if it doesn't
> exist either... a AttributeError is raised:
> 
> 
> class PropertyExample(object):
>     """A demonstration class for the property idea.
> 
>     This class is used afterwards as follows:
>     prop = PropertyExample()
>     prop.x = 5 # __set__x(self, 5) is called behind the scenes
>     print prop.x # __get__x(self) is called behind the scenes
>     del prop.x # __del__x(self) is called behind the scenes"""
> 
>     def __init__(self):
>         self.__x = None
>         
>     def __del__x(self):
>         del self.__x
>     def __get__x(self):
>         return self.__x
>     def __set__x(self, value):
>         self.__x = value
> 
> 
> 
> *** Problem: Many builtins are not necessary
> 
> Many builtins are not necessary. To name a few: min / max / len
> 
> This functions should be defined on the class:
> 
> ["I", "like", "Python"].len()
> "I".len()
> {1:"I", "2":"like", 3:"Python"}.len()
> (1,2,3,4).len()
> 
> "Throwing away" this builtins would flatten the alreay flat learning
> curve once more (you don't have to learn that many builtins) ... these
> functions belong to the class and they are naturally expected there.
> One weakness of a language as (Visual)Basic, PHP, ... is its payload
> of available functions... Python's OO helps here to diminish the need
> for lots of functions.
> 
> 
> *** Problem: tuples are not necessary
> 
> Throw them away in the long run - for now make them depracted. It is
> hard to argue in favour of tuples. There might to 2 reason:
> 
> 1. It is MUCH faster than a list
> 2. We can't live without an immutable list
> 
> Cons:
> 
> 1. I don't think that tuples deliver a big performance gain.
> 2. Python makes so many "soft" conventions (eg.: don't use
> vars/methods with 2 leading underscores) but when it comes to tuples
> the immutable issue is very important... why? I hope the tuples will
> disappear in P3K.
> 
> 
> *** Problem: builtins list() dict() ...
> 
> A list, a dictionary, a str, an int, a float are builtin functions...
> 
> myList = list()
> myDict = dict()
> myString = str(45)
> 
> The list-function instantiates a new list... it is actually nothing
> but an overloaded List class. Why are the handed in as functions? In a
> OO environment it should be more the instatiation of a class rather
> than a function and classes start with an uppercase letter:
> 
> myList = List()
> myDict = Dict()
> myString = String(45)

I agree with you in all but that tuples are not
necessary. Lists are the ones that are actually a
hack for speed! :-)

In fully functional languages you would operate on your
list with something like:

lst=[1,2]
lst=lst.append(3)
lst=lst.sort()
lst=lst.reverse()
lst=lst.insert(2,3)

count=lst.append(3).sort().reverse().len()

1_ Do not try this at home kids, it will not work :)

2_ Hmm, tuples could grow these methods. Would be
confusing as hell though. >:-}

3_ I prefer reading from left to right instead from right
to left (it makes the parenthesis less confusing too).
Compare to:

count=len(reversed(sorted(appended(lst,3)))).

Maybe I should learn Hebrew :-)
Or we could always change it to

$ lst|append -3|sort|reverse|len

(in the end all are just filter patterns :))

4_ If the python interpreter was smart enough sort()
could return a new list or sort in place depending on the
context: i.e.
lst=lst.sort() eq. lst.sort()
newlst=lst.sort() where lst is never used again eq.
lst.sort();newlst=lst;del lst, etc
but that would be against the pythons philosophy of
keeping the interpreter small, lean and simple.

Inmutable types are usually less "magical" than their
mutable counterpart.

For instance:

>>> lst1=[1,2]
>>> lst2=lst1
>>> lst2.append(3)
>>> lst1
[1, 2, 3]
>>> lst2
[1, 2, 3]
>>> tup1=(1,2)
>>> tup2=tup1
>>> tup2=tup2+(3,)
>>> tup1
(1, 2)
>>> tup2
(1, 2, 3)
>>> 

Do you think a newbie would expect that a modification
on one variable would have a effect on another?