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