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