Those APIs were all written long before there were sub-classes of types.
Understood. PyObject_Unicode certainly looked like an 'evolved' piece of code :)
But before we start hacking the function, we need a general picture of what we think is right.
Aye.
Note, BTW, that there is also a tp_str slot that serves as hook. The overall solution to this apparent mess should be consistent for all hooks (__str__, tp_str, __unicode__ and a future tp_unicode).
I imagine many people are like me, with __str__ being the only one of these hooks they use frequently (Helping out with the Decimal implementation is the only time I can recall using the slots for the numeric types, and I rarely need to deal with Unicode).
Anyway, they're heavy use suggests to me that __str__ and str() are likely to provide a good model for the desired behaviour - they're the ones that are likely to have been nudged in the most useful direction by bug reports and the like.
Regards, Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
