Thoughts about Python

[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