Thoughts about Python

Marco Aschwanden PPNTWIMBXFFC at spammotel.com
Tue Feb 24 12:11:20 CET 2004


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)



More information about the Python-list mailing list