The Python standard library and PEP8

[Emmanuel Surleau]

On Sunday 19 April 2009 21:46:46 Christian Heimes wrote:
> Emmanuel Surleau wrote:
> > First off, it's pretty commonplace in OO languages. Secondly, given the
> > number of methods available for the string objects, it is only natural to
> > assume that dir("a") would show me a len() or length() or size() method.
> > Having to use a function for such a mundane operation feels unnatural 
and
> > not OO.
>
> If you replace the term "OO" with "Java" in your posting, then I'm going
> to agree with you. Neither Java nor Python are pure object oriented
> languages. A while ago a friend of mine called Java a class centric
> programming language. I think that describes Java's coding philosophy
> very good. Python has a different coding philosphy. You can't assume
> that Java style development works with Python (and vice versa).

I don't know if it's "Java-style development" - you use a method to retrieve 
the length of a string in C++, Ruby or Javascript. Are you trying to say that 
having len() as a method/property is not object-oriented? The FAQ link in 
Gabriel Genellina's posting justifies the existence "len as a function" as 
historical. It does not seem to serve much purpose now. If there is a deeper 
reason why "len as a function" makes more sense than "len as a method", 
I'd be (genuinely) curious to hear it.

> Now to your rant about len(). Python class may implement several
> protocols with magic methods like __len__(), __iter__() or
> __getitem__(). The magic methods start and begin with two _. When a
> method implements the __len__() method then it supports len(). In Python
> readability counts. Try "import this" in a Python shell.

Not trying to attack you, but I'm not sure of what you're trying to say here. 
That len("a") is more readable than "a".len()?

> PEP 8 is a coding guideline for the standard library. It's not a law.
> Some modules are older than the PEP, other modules and libraries were
> developed outside the core and added later. We had a long discussion
> about PEP8'ing more code but eventually we decided against it. More
> chances would break too much 3rd party code.

I was not suggesting breaking. What's wrong with aliasing and marking as 
deprecated?

Also, given that Python 3000 breaks backward compatibility anyway, I don't 
see the point in not cleaning up the standard library completely and get rid 
of CamelCase once and for all.

Cheers,

Emm