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(fu nction):
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(ar g1, arg2, ...):
# self is not handed in... hence I can't use the instance vars
pass
def normalMethod(se lf, 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 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(fu nction):
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(ar g1, arg2, ...):
# self is not handed in... hence I can't use the instance vars
pass
def normalMethod(se lf, 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)
Comment