Eric Smith wrote: > Note that in > http://mail.python.org/pipermail/python-dev/2008-February/077062.html, > Guido advocates not adding the __bin__ machinery, which is what lead to > the simple implementation of bin() just calling PyNumber_ToBase and > relying on __index__. > > I don't think __bin__ should be added to 2.6. I don't see the point in > adding a feature in 2.6 that's implemented so differently in 3.0. It's > just asking for porting hassles. > > Instead, I think the approach used in 3.0 (r64451) should be used > instead. That is, if this feature exist at all. I'm -0 on adding > bin(), etc. to floats. The 3.0 approach means that non-float floating point types still can't be displayed properly by bin()/oct()/hex(). The current 2.6 approach means every such class has to implement its own equivalent of PyNumber_ToBase. Both are lousy solutions to a relative non-problem (IMO) that can easily be implemented using a separate display function for those applications which happen to need it. I'd prefer to see a proper PEP for this proposing a new slot that lets any class return an (integer_part, fraction_part) tuple of integers, and have PyNumber_ToBase take care of the actual string formatting. Introducing such a gratuitous incompatibility between 2.6 and 3.0 at this late stage of the process certainly seems highly undesirable to me. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
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