[Python-Dev] copy, len and the like as 'object' methods?

[David Ascher]

Guido van Rossum wrote:
> 
> > I just came back from teaching Python on a cruise ship attended by
> > mostly Perl folks.  It was an interesting experience teaching Python
> > with Randal in the audience =).
> 
> Tell us more...

Not much to tell.  Randal was polite in my class and didn't interrupt
too much =).  There were some interesting discussions between Paul
Prescod, Cameron Laird, Damian Conway, Mark-Jason Dominus, Randal and
myself about Perl 6, which is looking more and more like Python from
what I can tell.  The most interesting bit of knowledge I learned is
that the $, % and @ characters have a name -- they are sigils.  And
their use is going to change in Perl 6 to be consistent across contexts,
as they'll be bound with the variable.  Soon I may be able to say that
"If Python hadn't been around, Perl 6 would be my language of choice".
<snicker/>

> Except that __int__ is poorly defined -- sometimes it is used as a
> precision-losing number cast (e.g. int(3.5) returns 3), sometimes it
> is an exact conversion (e.g. int("3")).

Actually, that doesn't bother me -- the definition which works well is
"convert yourself to an integer".  The fact that the float object
decided to consider that as a truncation is possibly a bug in the float
object's decision, but __int__ is still 'convert to int, however you
(the type) see fit'.

> Yes, it's an old Python choice.  OO zealots don't like it much, but it
> has the advantage that you don't have to introduce methods right
> away.  Too late to change.

I wasn't suggesting that we change it.  Only that we add methods to the
objects, much like we added string methods but kept the string module.

> str() has won -- in part because of its name, in part because it is
> the "copy constructor", returning a string input unchanged.

Ah, subtle point I had missed.  

> I'd say leave it alone (we're getting enough complaints about
> "gratuitous" language changes as it is, and the changes we've
> committed to have very good reasons).

Again, I wasn't considering getting rid of old builtins.  We're going to
be adding new methods to all of the types anyway (since they'll derive
from object), so I was just suggesting that len or length be an alias
for __len__.

A minor issue at most.

Cheers,

--david