Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
On Tue, 24 Jun 2008, Nick Coghlan wrote: 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. I take issue only with your notion of returning a 'fraction_part integer'. How do you propose we do this? I suggest we add a third value, exponent, to the suggested return value. -- Cheers, Leif ___ 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
Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
On Tue, Jun 24, 2008 at 6:17 AM, Nick Coghlan [EMAIL PROTECTED] wrote: 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. I missed the decision, but it's been added, at least to 2.6. However, it was added after beta 1, so unless there was consensus about this, IMO it should be rolled back. The 3.0 approach means that non-float floating point types still can't be displayed properly by bin()/oct()/hex(). Nor can float, AFAICT from the current 3.0 tree. The current 2.6 approach means every such class has to implement its own equivalent of PyNumber_ToBase. But that's not supposed to be a burden -- any type purporting to implement some kind of integer should implement __index__ anyway. (Unless I misunderstand what you mean by equivalent of?) 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. I'd prefer not to see new features added at all, except for things that were being planned before the beta and specifically got permission to be added post-beta-1. Introducing such a gratuitous incompatibility between 2.6 and 3.0 at this late stage of the process certainly seems highly undesirable to me. Same here. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
Guido van Rossum wrote: The 3.0 approach means that non-float floating point types still can't be displayed properly by bin()/oct()/hex(). Nor can float, AFAICT from the current 3.0 tree. $ ./python Python 3.0b1+ (py3k:64491:64497M, Jun 24 2008, 07:14:03) [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2 Type help, copyright, credits or license for more information. bin(1.0) '0b1 * 2.0 ** 0' The current 2.6 approach means every such class has to implement its own equivalent of PyNumber_ToBase. But that's not supposed to be a burden -- any type purporting to implement some kind of integer should implement __index__ anyway. (Unless I misunderstand what you mean by equivalent of?) But apparently there's a desire to have bin(), oct(), and hex() support non-integer types. See above, and issue 3008. In 3.0, it's not possible to extend these to other types, because of the lack of __bin__, etc. The test for float is hard coded in PyNumber_ToBase(). Eric. ___ 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
Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
On Tue, Jun 24, 2008 at 10:07 AM, Eric Smith [EMAIL PROTECTED] wrote: Guido van Rossum wrote: The 3.0 approach means that non-float floating point types still can't be displayed properly by bin()/oct()/hex(). Nor can float, AFAICT from the current 3.0 tree. $ ./python Python 3.0b1+ (py3k:64491:64497M, Jun 24 2008, 07:14:03) [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2 Type help, copyright, credits or license for more information. bin(1.0) '0b1 * 2.0 ** 0' Oops. The current 2.6 approach means every such class has to implement its own equivalent of PyNumber_ToBase. But that's not supposed to be a burden -- any type purporting to implement some kind of integer should implement __index__ anyway. (Unless I misunderstand what you mean by equivalent of?) But apparently there's a desire to have bin(), oct(), and hex() support non-integer types. See above, and issue 3008. In 3.0, it's not possible to extend these to other types, because of the lack of __bin__, etc. The test for float is hard coded in PyNumber_ToBase(). There are lots of desires. This particular one goes straight against an earlier decision to simplify bin(), oct() and hex() by removing the __oct__ and __hex__ special methods and not adding __bin__. Certainly not something to be added without a PEP, certainly not after beta1 was released already. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
I'm curious why the addition of a new feature, past beta 1, was constrained entirely to a single tracker issue. Clearly not enough people were aware of it (or there wouldn't be the discussion about it here). Following the discussion in the issue tracker is really hard (since most of the discussion apparently refers to earlier versions). I also don't see any doc changes. If you want to keep the feature, at least write some documentation for it so everyone knows what is actually implemented, and why, without having to go to the source. --Guido On Tue, Jun 24, 2008 at 11:44 AM, Raymond Hettinger [EMAIL PROTECTED] wrote: bin(1.0) '0b1 * 2.0 ** 0' Oops. This was checked-in for Issue 3008 which has been under discussion and development for a while. It was intentionally held until after the beta was released so that the beta itself would be as stable as possible (in the final week and a half most of the bots were red and it made no sense to commit a feature request at that time). The patch allows a eval-able representation of a float that works across platforms and is not dependent of %.17g, atof() or ftoa() routines. The tool makes it much easier to examine or explain what floating point ops really do. It was invaluable in the development of math.sum(). I've spent several days of development time on this and would be really bummed if it got reversed-out at this point. The use of __bin__ is not essential to its implementation so that implementation detail can be changed if needed. Raymond -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
On Tue, Jun 24, 2008 at 8:05 PM, Guido van Rossum [EMAIL PROTECTED] wrote: Following the discussion in the issue tracker is really hard (since most of the discussion apparently refers to earlier versions). I also don't see any doc changes. I think there may also still be room for some additional discussion on the output format; while being eval-able is nice, one not-so-nice aspect of the representation is that nearby floats can have entirely distinct-looking representations; as in, for example: hex(126.38) '0x3f30a3d70a3d7 * 2.0 ** -43' hex(126.39) '0x1f98f5c28f5c29 * 2.0 ** -46' bin() suffers much less from this, but on balance I think I'd still prefer to see a non eval-able output that's normalized with respect to the most-significant bit instead of the least. I realize that (a) this has little to do with implementation details and use or not of __bin__, and (b) I should have said this in the issue tracker a few days ago. Mark ___ 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
Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
I think there may also still be room for some additional discussion on the output format; If so, I think the change should be reverted, and the feature deferred to 2.7/3.1. Regards, Martin ___ 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
Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
[Mark Dickinson] I think there may also still be room for some additional discussion on the output format; [Martin v. Löwis] If so, I think the change should be reverted, and the feature deferred to 2.7/3.1. It looks like pretty much every aspect of this change was discussed / reviewed insufficiently. +1 on rolling back and taking the time to get it right. -1 on rushing it in. Since it's (potentially) a pretty small feature I might be convinced to accept it in beta2, but I don't want the fact that it was committed to force our hand. Raymond, if you care about this feature, please roll it back so we can have a proper discussion without pressure. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 24, 2008, at 4:13 PM, Guido van Rossum wrote: [Mark Dickinson] I think there may also still be room for some additional discussion on the output format; [Martin v. Löwis] If so, I think the change should be reverted, and the feature deferred to 2.7/3.1. It looks like pretty much every aspect of this change was discussed / reviewed insufficiently. +1 on rolling back and taking the time to get it right. -1 on rushing it in. Since it's (potentially) a pretty small feature I might be convinced to accept it in beta2, but I don't want the fact that it was committed to force our hand. Raymond, if you care about this feature, please roll it back so we can have a proper discussion without pressure. FWIW, I concur. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSGFrlnEjvBPtnXfVAQITxwP/T16pGX+aTV5O/lhmwYWDtv8bA0S2l+Kl 6paSWTz8HHD0cpAhMAKKN7XqnJ6A0uIebCEJSPFdir8Jl0AMSbBZq88l+D93eoC0 eiqryogRTUzwrs2zC3A/nMjpNe21MErQNUEqmpU7XgdOpBRFQF8UMOnRIoSV8ggx SKwy+cRHnEk= =olIq -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk: Include/object.h Lib/test/test_sys.py Misc/NEWS Objects/intobject.c Objects/longobject.c Objects/typeobject.c Python/bltinmodule.c
I thought there was a discussion of this earlier, and the idea was to leave the prior implementation, because that's how it's implemented in 3.0. bin() is a new feature in 2.6, so there's no particular need to make it work like hex() and oct(). Recall that in 3.0, __bin__, __oct__, and __hex__ don't exist. Instead, you use __index__ for integer conversions. That's how bin() worked in 2.6 until this checkin. But now that I look for it, I can't find the original discussion. raymond.hettinger wrote: Author: raymond.hettinger Date: Fri Jun 20 06:18:15 2008 New Revision: 64424 Log: Make bin() implementation parallel oct() and hex() so that int/long subclasses can override or so that other classes can support. ___ 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
