M.-A. Lemburg wrote:
> 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 | ncoghlan at email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4