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
--
http://mail.python.org/mailman/listinfo/python-list
