python gripes survey

[Colin J. Williams]

nnes wrote:
> 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().

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.