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

David Ascher DavidA@ActiveState.com
Tue, 21 Aug 2001 12:01:18 -0700

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

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

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?

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?