python gripes survey

Colin J. Williams cjw at
Mon Aug 25 16:22:56 CEST 2003

nnes wrote:
> Geoff Howland <ghowland at> wrote in message news:<7s6gkv031b940dsc522pbh5g30q4nj5vd1 at>...
>>On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" <ryanlowe0 at>
>>Just to point some things out since I started the {} [] thread.  I was
>>trying to do something hacky, and while I wanted the [].len() type
>>calls for my team mates, I never had a problem with the current len()
>>and understand the reasoning behind it.  [].len() is more uniform, but
>>it also changes the requirements for the language in a duplicated
>>fashion, since the test for __len__() will always exist as well.
>>So while I think they may have been reasonable requests, Im not sure
>>theyre really pitfalls, and Im not sure they would even work out that
>>well on a large scale which is why I wanted to implement it and test
>>it out myself.
>>-Geoff Howland
> Can you post a link to that thread?
> I have never understood why python has [].count() or "".count() but
> len([]) and len("").
> Why not make len, sum, str, repr, etc just methods of the base object
> class with specific implementations for different types. Instead of
> doing len([]) we could do [].len().
> This is actually possible already in part. I think you can do
> [].__len__(). But I never understood the reasoning behind making these
> special __x__() methods instead of doing a plain x() and using it like
> obj.x().

Or why not make it plainer still, so that len, str etc become properties 
or attributes, without the need to add the redundant parentheses?

> The only case I can think of, where it would look kind of odd would be
> floating points like:
> niceoutput=2.3.str()
> Anyway since Pythonistas are smart, it can not be a wart of the
> language and must be some lack in my understanding :)
> awaiting-to-be-enlightened-yours
> Nestor

Colin W.

More information about the Python-list mailing list