Thoughts about Python

[Marco Aschwanden]

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)

[Michael Hudson]

PP**********@sp ammotel.com (Marco Aschwanden) writes:

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)
See PEP 318 (and current discussion on python-dev).
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...
What's so special about self? I really don't like the idea of
argument names keying this kind of change in behaviour.
*** 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
You seem really fond of magic names...

By the way, Python 2.2 introduced the capacity for staticmethods and
properties and consciously decided not to add syntax for the same
until there was some experience in using these things. So it's known
that there is some discomfort here, but it's not yet clear (to me, at
least) what a good syntax *is*. I hope you're not too offended if I
say that your suggestion doesn't seem instantly wonderful.
*** Problem: Many builtins are not necessary
Pah. So what? If you want minimailty scheme is over there ====>
Many builtins are not necessary. To name a few: min / max / len

This functions should be defined on the class:
Says you!

[...]
*** Problem: tuples are not necessary
Says you! Here's a hint: hash([]).

[...] *** Problem: builtins list() dict() ...

A list, a dictionary, a str, an int, a float are builtin functions...

myList = list()
myDict = dict()
myString = str(45)

Pedantry: no they're not, they're builtin types.

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. I suggest you continue using Python for a few
more weeks and read your list again.

Cheers,
mwh

--
MARVIN: Oh dear, I think you'll find reality's on the blink again.
-- The Hitch-Hikers Guide to the Galaxy, Episode 12

[Duncan Booth]

PP**********@sp ammotel.com (Marco Aschwanden) wrote in
news:15******** *************** ***@posting.goo gle.com:

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.
I think you should spend a bit of time reading the PEPs and the python-dev
mailing list archives. A lot of what you say has been discussed previously,
and it would be good if you could take the earlier discussion on board and
then see where your thoughts lead you.

*** Problem: clumsy static class methods
This has been widely discussed elsewhere and various solutions have been
proposed.

*** Problem: clumsy properties for classes
As for static methods various ways to improve this have been suggested. You
should read the discussions on python-dev to see the various viewpoints.

*** 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()
The advantage of min and max as builtins are that they work on any
sequence. In particular they work on iterators. Having functions that apply
to an arbitrary sequence avoids a lot of potential code duplication.
"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.
There are other builtins I would throw away first. Note that you can't
actually throw any of these builtins away: one of Pythons great strengths
are the lengths it goes to to maintain backward compatibility. Some of the
less useful builtins are being relegated to backwaters of the
documentation, but they will remain as builtins for the foreseeable future.


*** 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
Forget the speed and memory difference. The main argument for tuples as a
separate type are to use as dictionary keys. How do you propose to handle
dictionary keys without tuples?

*** Problem: builtins list() dict() ...

A list, a dictionary, a str, an int, a float are builtin functions...
No they aren't. They are types, not 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)

So they don't follow your naming convention. If this is a big problem for
you, then add some new globals in your own programs. The type 'file' is
already aliased as 'open'. You can't remove the existing builtins (since
that would break the library), but there is nothing to stop you adding your
own either in the __builtin__ module, or as a separate module containing
your aliases.

FWIW, I agree that the builtins that exist aren't the best choice for type
names --- too often they collide with the 'obvious' variable names that
python newcomers choose and then they wonder why their call to 'str' blow
up when they used a variable 'str' a few lines earlier.

[Matthias]

Duncan Booth <[e-mail] > writes:

PP**********@sp ammotel.com (Marco Aschwanden) wrote in
news:15******** *************** ***@posting.goo gle.com:

*** 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()

The advantage of min and max as builtins are that they work on any
sequence. In particular they work on iterators. Having functions that apply
to an arbitrary sequence avoids a lot of potential code duplication.

Do you mean code duplication on the user side? Or code duplication in
Python's implementations ? In the latter case, it seems strange to
force inconsistent method/function usage on thousands of developers
just in order to save a couple of lines in Python's source code.

To me, Python's builtins are by far not a "problem", but I admit that
I never understood why astring.len() doesn't work.

[Duncan Booth]

Matthias <[e-mail]> wrote in
news:36******** *****@goya03.ti .uni-mannheim.de:

The advantage of min and max as builtins are that they work on any
sequence. In particular they work on iterators. Having functions that
apply to an arbitrary sequence avoids a lot of potential code
duplication.
Do you mean code duplication on the user side? Or code duplication in
Python's implementations ? In the latter case, it seems strange to
force inconsistent method/function usage on thousands of developers
just in order to save a couple of lines in Python's source code.

I mean code duplication on the user side. A function that operates on every
iterator or sequence type is far more useful than a protocol that more
often than not wouldn't be implemented.

To me, Python's builtins are by far not a "problem", but I admit that
I never understood why astring.len() doesn't work.

Because it would have to begin and end with two underscores (thats the
naming convention for special methods), and astring.__len__ () already does
what you want. But I think it is mostly for historical reasons.

[Aahz]

In article <15************ **************@ posting.google. com>,
Marco Aschwanden <PP**********@s pammotel.com> wrote:

*** 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.

"Practicali ty beats purity"; if you're not familiar with that, start up
an interactive Python session and type "import this".

In this case, this means that Guido thinks that len() is such a common
usage that it works better as a function than a method.
--
Aahz (aa**@pythoncra ft.com) <*> http://www.pythoncraft.com/

"Do not taunt happy fun for loops. Do not change lists you are looping over."
--Remco Gerlich, comp.lang.pytho n

[Terry Reedy]

"Marco Aschwanden" <PP**********@s pammotel.com> wrote in message
news:15******** *************** ***@posting.goo gle.com...

I have collected those thoughts. I am sure there are many discussions
on the "problems" mentioned here.
Yes, there have been. Do read some if you are really interested.
*** Problem: clumsy properties for classes
The problem is currently under discussion. Your fix is based on thinking
'self' to be a keyword, which it is not, instead of a usage convention for
English language programmers. Python is not <language x>.
class c (object):
def staticMethod(ar g1, arg2, ...): pass
# self is not handed in... hence I can't use the instance vars
Yes it is and yes you can if this method called on an instance. You have
simply called the instance 'arg1' instead of 'self'.
def normalMethod(se lf, arg1, arg2, ...):
pass
If you follow this by normalMethod = staticmethod(no rmalMethod), then
'self' is *not* an instance.
Static methods are very rare. You left out a proposal for the more common
and more useful classmethod.

.... Many builtins are not necessary.
Many people agree.
To name a few: min / max / len
But people wildly disagree on which should be axed.
This functions should be defined on the class:
This syntax uniformatizing suggestion comes up about once a year. It
overlooks the fact that uniformity is lost as soon as a user writes a
sequence function (for instance, variance()). I know, we could abolish
functions and only have methods. But if you want that, choose a different
language.

Even more, It also overlooks the tremendous advantages of generic
programming with Python. If I write an iterable type, it can be used with
any sequence function, current or future. Conversely, if I write a
sequence (iterable) function, it can be used with any iterable object,
current or future -- without subclassing or access to source code. Your
proposed handcuff of requiring a specifc method for each type - function
combinatin leads to an M*N explosion of code and coding work.

Quiz: how would you rewrite map(len, ['abc', (1,2,3,4), [5,6]]) if len()
were a method?
classes start with an uppercase letter:
myList = List()

This appears to be a convention or rule you learned from another language.
Though some Python programmers follow it, tt is not part of Python.

Terry J. Reedy

[Terry Reedy]

"Matthias" <[e-mail]> wrote in message
news:36******** *****@goya03.ti .uni-mannheim.de...

Duncan Booth <[e-mail] > writes:

The advantage of min and max as builtins are that they work on any
sequence. In particular they work on iterators. Having functions that apply to an arbitrary sequence avoids a lot of potential code duplication.
Do you mean code duplication on the user side? Or code duplication in
Python's implementations ?

Python's generic programming saves user code.

Write a function taking an iterable argument and it can be used with any of
the countable infinity of possible iterable types, current and future. For
free, without having to subclass or otherwise attach the function as a
method to each.

Write an iterable type and it can be fed to any of the countable infinity
of possible sequence functions, written and yet to be written. For free,
without adding them all as methods, which is impossible anyway for future
functions.
In the latter case,
But it is both cases, so your consequent does not follow.
To me, Python's builtins are by far not a "problem", but I admit that
I never understood why astring.len() doesn't work.

Because there is currently no process to make generic functions accessible
(aliased) as specific methods. Possible (but not-serious) proposal: Add
interface objects with attribute __takes__ being a set of functions which
takes objects implementing that interface as a single argument. Give types
a set of interfaces called __implements__. If attribute look-up fails,
search __takes__ for interfaces in __implements__. But you now you have
to explicitly register objects with the sets, and you still have problems
with interfaces (virtual types) often being too narrow, too broad, and/or
too numerous and what to do with multiparameter functions. Isn't
len(astring) easier, as well as one char shorter?

Terry J. Reedy

[OKB (not okblacke)]

Duncan Booth wrote:

The advantage of min and max as builtins are that they work on any
sequence. In particular they work on iterators. Having functions
that apply to an arbitrary sequence avoids a lot of potential code
duplication.

Wouldn't subclassing be an appropriate solution? The most general
sequence class/type could define a len method and the others would
inherit it and override it if they have different length semantics. In
fact, Python already does this with the __len__ magic method. Having a
builtin function whose implementation is defined with a magically named
method seems an awkward design. Why not have just the method and do
away with the function?

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

[OKB (not okblacke)]

Terry Reedy wrote:

Quiz: how would you rewrite map(len, ['abc', (1,2,3,4), [5,6]]) if
len() were a method?

[ a.len() for a in ['abc', (1,2,3,4), [5,6]] ]

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown