python gripes survey

[nnes]

Geoff Howland <ghowland at lupineNO.SPAMgames.com> wrote in message news:<7s6gkv031b940dsc522pbh5g30q4nj5vd1 at 4ax.com>...
> On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" <ryanlowe0 at msn.com>
> wrote:
> 
> 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
> http://ludumdare.com/

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().

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