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

[Guido van Rossum]

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

> One issue that came up is some of the lack of uniformity on what things
> are statements, methods and built-in functions.   In the long-term
> version of the type/class unification work, things like int() become
> class constructors, which makes beautiful sense.  The fact that int()
> calls __int__ methods fits nicely with type conversion mechanisms. 

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

> However, there are a few things which still seem oddballish:
> 
>   copy.copy(), copy.deepcopy(), len()
> 
> These basically call magic methods of their arguments (whether tp_slots
> or __methods__), and many languages implement them strictly as object
> methods.  

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.

> str() and repr() are a little weird -- I'm not sure which one will gain
> 'class constructor' status when the type/class unification work is done
> -- from the definition I'd say repr() should win, but the name is quite
> unfortunate given its new role...  Guido, thoughts?

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

> Summary: Should copy, deepcopy and len be added as object methods?  And
> if yes, how?  Not all objects are copyable or measurable.  Interfaces
> seem the right way to do this, but interfaces aren't in the plans so far
> that I know...
> 
> What about a stringification method?

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

--Guido van Rossum (home page: http://www.python.org/~guido/)