The Python standard library and PEP8

[Stephen Hansen]

> > Also, my code sample was itself a trick question.  Python has *dynamic*
>  > object orientation (just as the blurb says), and square() will work
> > on any object with a __mul__() method (through the ``*`` syntax), just as
> > len() works on any object with a __len__() method.  So my code
> > demonstrates the way Python's programming styles interleave with each
> > other (throw in a listcomp to complete the set).
>
> This is what Carl Banks was saying below (that getting the length of
> something was generic operation)... Well, I suppose it sorts of make sense.
> I
> had the feeling that Python had been moving from a more procedural kind of
> language to a more object-oriented one (by having the "everything be an
> object"). But I'm beginning the see the logic in having a len() function
> (as
> opposed to a design wart).


I don't think Python is moving in any direction that pushes it more towards
one paradigm or another; it's moving simply from less-Pythonic to
more-Pythonic. Early on in the 2.x series that did include a number of major
enhancements which sought to unify the difference between types and classes
and this was a win for object-oriented programming, but that isn't at all
the general goal.

Python has also included in recent releases a number of advantages and tools
to support a more functional approach, including the numerous additions to
the functools modules and itertools modules and the various capabilities
that iterators and generators have brought to the language.

The question of, "Why is the length of a sequence not a method of
sequences?" is a very common question. The thread has previously linked to
the FAQ, but there's also the effbot page at
http://effbot.org/pyfaq/why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list.htm

Python doesn't just allow, or support, but encourages you to address the
problems you are faced with in a way which works both for you and for the
problem at hand. There's times when object oriented is just not the right
answer; times when simple procedural is all you need; and times when a
functional approach is better. Python chooses not to make a decision on
which is right or wrong; the language is object-oriented in that it supports
and encourages you to program in an object oriented fashion if you choose
to.

Guido basically sees "what is the length of <x>" as an operation and not a
method of a particular class; true a class can set that behavior as it
wishes, but as with several other things determining the length of a thing
was seen as a fundamental operation. That's why Python has str(object)
instead of calling object.toStr() like you would have to with Java. There's
many other examples-- even more recently, as the generator.next() method has
become next(generator), for example. To try to pidgeon-hole what's right
with Python's design with what you perceive to be The Right Way in
OO-Languages is flawed.

Python is about a more practical approach to problems then a theoretical
purity adhering some design principle; what is "Pythonic" is not definable
in any mathematical or analytical sense by any compsci major skilled in all
of the theories of design. Its more a gut feeling, and its goals aren't
about "Correctness". Its about getting the job done, its about making the
job approachable, intutiive and comprehensible, and its about getting back
to the job later an easy thing to pick up.

Python 3.0 included a number of backwards incompatible changes, but they
were all (in theory) done for reasons of benefiting the /usage/ of the
language and the /experience/ of the process. "Clean" is a terribly dirty
word when talking of this, really. "Why not clean ..." you ask -- the answer
is: how do YOU define clean, and what do YOU have to do to accomodate clean,
and why should everyone else change to be clean in your perspective?

Making Python "cleaner" by making this operation more Object-Orienteded by
maing it a method is a highly suspect proposition: why is it cleaner to be
more object oriented? In Python terms, "clean" is defined more as Pythonic
-- which is a very complex ideal, admittedly. Its an ideal which says its
even OK to have completely different coding styles in the standard library,
because its more important to keep consistancy with local code then global
policy and its more important to not change something "just cuz" then it is
to change something to provide some real benefit to usage or clarity.

Is "something.len()" really anymore clear then "len(something)"?

To the OO-purist, maybe. But the world is bigger.

--S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090419/cb7c6e8d/attachment-0001.html>