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)

[Greg Ewing (using news.cis.dfn.de)]

Marco Aschwanden wrote:

I know that tuples can be used as keys... but how many times do
you need tuples as dictionary keys (it would be simple to turn a list
into an immutable string if really needed ("::".join(["a","b"]).

Having used other languages where dictionary keys have to
be strings, I very much like the fact that I *don't* have to
do this in Python. Uniquely deriving a string from a non-flat
data structure is fraught with difficulties (e.g. in your example,
what if one of the list elements contains "::"? Or what if you
wanted to stringify [42, "elephant", myFunkyClassIns tance]?) You
end up having to carefully design a stringifying scheme for each
particular case. It's a big can of hassles that I can do without.

And using a tuple as a dict key is a more common thing to do than
you might think. It synergises with another feature of the Python
syntax, that commas (and not parentheses) are what generate tuples,
to give a very nice way of using a dict as a multi-dimensional table:

my_sparse_matri x = {}
my_sparse_matri x[17, 42] = 88

This works because '17, 42' is an expression yielding a
tuple, and tuples can be used as dict keys.

I hope you can see now that expecting Python programmers to
"simply" turn their lists into strings for use as dict
keys would *not* go down well in the Python community. :-)

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Greg Ewing (using news.cis.dfn.de)]

Marco Aschwanden wrote:

Well, yeah, this is true and isn't. It is true that there is no rule
how to name a class. To me a list / dict / string is a (basic) class
(you take about types - the manuals does also) but why introduce new
words, when the class-idiom is enough to explain everything.

Types and classes used to be very different things, but somewhere
around Python 2.1 or 2.2 a project was begun to unify the two
concepts, and nowadays the terms "type" and "class" are very
nearly synonymous. (There still exist what are now called "old-style
classes", but these are expected to disappear eventually, at which
time we will be able to stop talking about types at all and just
speak of classes.)

Before the type/class unification, builtins such as list and str
were functions. After the unification, it made sense to re-define
them as types/classes for compatibility, and for consistency the
new ones such as dict were named in the same style.

You're right that naming conventions (or lack thereof) in Python
leave something to be desired, but we're stuck with many of them
for historical reasons. Personally, I *like* that the most
fundamental built-in functions and classes have the shortest
and simplest names.

Your suggested convention (classes start with uppercase, functions
with lowercase) has its uses, and I tend to follow it in most of
the code that I write, but it has its drawbacks as well. A
counterargument often put forward is that users of a class usually
don't care whether something is really a class or whether it's
a factory function, and often you would like to be free to change
the implementation from one to the other without affecting client
code. With a naming convention that distinguishes classes from
functions, you can't do that.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Paul Prescod]

Greg Ewing (using news.cis.dfn.de ) wrote:

....
You're right that naming conventions (or lack thereof) in Python
leave something to be desired, but we're stuck with many of them
for historical reasons.
Not really. If "open" can be renamed "file" it could also have been
renamed File. To be honest I think that the real problem is that Guido
is allergic to caps. I don't know how None snuck in. ;)
Your suggested convention (classes start with uppercase, functions
with lowercase) has its uses, and I tend to follow it in most of
the code that I write, but it has its drawbacks as well. A
counterargument often put forward is that users of a class usually
don't care whether something is really a class or whether it's
a factory function, and often you would like to be free to change
the implementation from one to the other without affecting client
code. With a naming convention that distinguishes classes from
functions, you can't do that.

Changing from a function to a class is _always_ easy.

def open(filename, flags):
return File(filename, flags)

The trickier issue is having the class itself export the interface the
client code is used to.

Changing from a class to a function is never really very safe:

class myobject(File):
...

if isinstance(myob ject, File):
....

How can you change File to be just a function safely? But anyhow, why
would you want to?

Paul Prescod

[Greg Ewing (using news.cis.dfn.de)]

Paul Prescod wrote:

Changing from a class to a function is never really very safe:

class myobject(File):
...

if isinstance(myob ject, File):
....

How can you change File to be just a function safely?

You can't, obviously. This demonstrates that there *is*
an important distinction to be made between classes and
functions -- you can subclass one and not the other!

Arguments like this (and others, such as the capability-based
security model problems) are making me re-consider whether
having classes also be factory functions is really such
a good idea. There are two distinct ways of using classes
in Python:

1. As a base class
2. As a factory function

and these have different degrees of coupling to the
implementation. Use (1) requires it to really be a
class, whereas (2) only requires it to be a callable
object.

For use (1), there is an advantage in having classes
named differently from functions -- if it's named like
a class, you know it's a class and can therefore
subclass it.

But for use (2), it's a disadvantage, since if something
starts out as a factory function and later changes into
a (published) class, all code using it has to change.

The only way I can see of reconciling these is to adopt
the convention that whenever you publish a class Foo,
you also publish a factory function foo() that instantiates
Foo. Users of it are expected to use Foo when subclassing
and foo() when instantiating.

Now, if you change the implementation so that Foo is
no longer a class, code which subclasses Foo will break --
there's no avoiding that. But code which only instantiates,
using foo(), will keep working.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Rainer Deyke]

Sean Ross wrote:

"""
obj.freeze -> obj

Prevents further modifications to obj. A TypeError will be raised if
modification is attempted. There is no way to unfreeze a frozen
object. See also Object#frozen? .
"""

An interesting idea. This would also allow other mutable types such as
dictionaries to be used as dictionary keys. I'm not sure if I like it, but
I am sure that I am not happy with the current list/tuple situation.

An alternate approach would be for the dictionary to lock the key objects
when they are inserted and unlock them when they are removed. Another would
be for dictionaries to keep a private copy of their keys.
--
Rainer Deyke - ra*****@eldwood .com - http://eldwood.com

[Joe Mason]

In article <c1************ *@ID-169208.news.uni-berlin.de>, Greg Ewing (using news.cis.dfn.de ) wrote:

Having used other languages where dictionary keys have to
be strings, I very much like the fact that I *don't* have to
do this in Python. Uniquely deriving a string from a non-flat
data structure is fraught with difficulties (e.g. in your example,
what if one of the list elements contains "::"? Or what if you
wanted to stringify [42, "elephant", myFunkyClassIns tance]?) You
end up having to carefully design a stringifying scheme for each
particular case. It's a big can of hassles that I can do without.

TCL-style strings provice a good universal escaping mechanism for this,
as long as you're consistent.

Joe

[Marco Aschwanden]

"Mike C. Fletcher" <mc******@roger s.com> wrote in message news:<ma******* *************** **************@ python.org>...

I can see that tuples have their utility as a dict key. And from other
postings as well, I conclude: Tuples as dictionary keys are common
practice and are therefore here to stay.

Thanks,
Cheers,
Marco

[Marco Aschwanden]

co**********@ph ysics.mcmaster. ca (David M. Cooke) wrote in message news:<qn******* ******@arbutus. physics.mcmaste r.ca>...

At some point, PP**********@sp ammotel.com (Marco Aschwanden) wrote:

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?

Maybe I don't get the point here: Why do dictionaries need tuples to
work? I know that tuples can be used as keys... but how many times do
you need tuples as dictionary keys (it would be simple to turn a list
into an immutable string if really needed ("::".join(["a","b"]).

Simple, yes. Practicable, no. Wrong, certainly. For instance, I have a
lot of use cases where I use tuples of numbers -- (3, 4, 20.0101), eg.
It'd be a *hack* to convert that into a string, and the representation
would not be unique. This ain't Perl.

tup = (3, 4, 20.0101)
stringified = str(tup)
stringified

'(3, 4, 20.010100000000 001)' # 8o)
What is not unique about this string?
Okay, I can think of cases where this approach is problematic -
foremost when sorting is involved.
It is also a bit complicated to retrieve the values from the string
(it has to be "split"ted or "eval"ed back to a tuple or list).
If this pattern would be seldom used... but it seems, that everybody
except me uses this dicts as keys.

And yes, luckily this is not Perl.

Cheers,
Marco

[Marco Aschwanden]

> >*** 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.
Thanks! Now I know where my thinking went wrong... self is "another"
soft Python contract. This was now a real enlightment! I intermingled
Java's <this> with Python's <self>. They are not the same and <self>
is not "automatic" .
Quiz: how would you rewrite map(len, ['abc', (1,2,3,4), [5,6]]) if len()
were a method?

The quiz is already (and very elegantly and better readable) solved
with a comprehension list. The OO-technique used is called
polymorphism... 8o).

Thanks for the hint on <self> is not "system var".
Cheers,
Marco

[Marco Aschwanden]

> > *** Problem: tuples are not necessary

Frankly, there is very little in any programming language that is
necessary. Back when I brushed up against computability theory,
I found that all programs can be written in a language with one operation:
a combination of subtract and conditional branch. That's hardly
practical, though. The question is whether a feature serves a useful
purpose.
I once read an interesting article that a programming language can be
reduced to 4 instructions: (1) input (2) output (3) if-then (4) goto.
All other commands / functions are built upon those 4 "basic ideas".

I would say: Python struggles for a maximum functionalty by preserving
optimal "simplicity ". And it does a good job at that! That's why I
like it so much.

I am not a reductionist. And I am not asking to create a reduced
Python. I had just the feeling that to learn about all specialities of
tuples is not worth the hassle... obviously I was wrong and you bring
some more aspects in favour tuples further down below:
Tuples serve two distinct purposes. One is as a cheap version
of a C struct: that is, a data structure in which each element
serves a conceptually different purpose.

The other is as a structure that is immutable so it can be used
as a key in a dict.

One thing to understand about this is that immutability is key:
dicts depend on having a hash key that is somehow derived
from the content of the object, and if the content of a key
changes that key will probably simply be unlocatable: it will be
filed in the dict under the old rather than the new hash code.

Cheers,
Marco