python gripes survey

[John Roth]

"nnes" <pruebauno at latinmail.com> wrote in message
news:d8778a53.0308241450.1a0d6645 at posting.google.com...
> 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

Mostly history. Python doesn't have a standard class that's
a base class for everything, although it's moving that way
with the object class in 2.2 So while it would have been
a nice idea for there to be an object.len() method inherited
by all classes, this wasn't (and still isn't) really possible.

The __method__ methods are implementation details;
they are (mostly) required private methods that are
used by the various operators and global functions.
The len() global function, for example, calls the
__len__() method.

I'm not sure what the ramifications of just
dumping the relevant global functions into the
type and object classes would be. I suspect that,
since old code isn't expecting most of them, you'd
get a strange mismash of methods that sometimes
work, sometimes don't, and sometimes are used
for unrelated purposes.

John Roth

>
> Nestor