Re: [Python-Dev] C API for gc.enable() and gc.disable()
Martin v. Löwis martin at v.loewis.de writes: I'd like to see in an experiment whether this is really true. Right, all those ideas should be implemented and tried out. I don't really have time to spend on it right now. Also, what's missing is a suite of performance/efficiency tests for the garbage collector. ___ 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
[Python-Dev] Py3k DeprecationWarning in stdlib
Hi Devs, Today, I saw the Py3k beta 1 announcement, so I thought Well, I gotta do my duty and try to migrate my own code base to see if I can uncover any problems. I'm just at the step where I run my test suite with the -3 flag, and I noticed something peculiar: I get DeprecationWarning from stdlib code (namely, difflib, logging and unittest). Is it something to be expected or should I create tickets for those? I'm sure that the stdlib on the 3k side is fixed, but shouldn't the 2.6 side be fixed as well? Sorry if this question is already answered somewhere else, I searched for an answer but I couldn't find it. Additionally, one thing that strikes me as strange is how hard it is to find a Migration guide on the website. I had to dig in the PEP 3000 to find the brief bullet list telling me to run py26 with the -3 flag. Virgil Dupras ___ 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] Py3k DeprecationWarning in stdlib
Virgil Dupras wrote: Hi Devs, Today, I saw the Py3k beta 1 announcement, so I thought Well, I gotta do my duty and try to migrate my own code base to see if I can uncover any problems. I'm just at the step where I run my test suite with the -3 flag, and I noticed something peculiar: I get DeprecationWarning from stdlib code (namely, difflib, logging and unittest). Is it something to be expected or should I create tickets for those? I'm sure that the stdlib on the 3k side is fixed, but shouldn't the 2.6 side be fixed as well? I'd say so, yes. If tracker issues don't exist yet, please create them. The focus for the first beta was really on getting all the syntax and API changes stable - the remaining time between the first beta release and the first release candidate will focus on cleaning up issues like this. Sorry if this question is already answered somewhere else, I searched for an answer but I couldn't find it. Additionally, one thing that strikes me as strange is how hard it is to find a Migration guide on the website. I had to dig in the PEP 3000 to find the brief bullet list telling me to run py26 with the -3 flag. Probably because nobody has stepped up to write a migration HOWTO yet... 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] Py3k DeprecationWarning in stdlib
On Tue, Jun 24, 2008 at 12:34 PM, Nick Coghlan [EMAIL PROTECTED] wrote: Probably because nobody has stepped up to write a migration HOWTO yet... I'm not much of a writer, but once I'm finished with the migration, I'll do it (if it hasn't been done then). It's about time I try to learn reST... Virgil Dupras ___ 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
[Python-Dev] Python Windows Installers
Hello all, I'm just doing some housekeeping on a Windows install, and notice that the 'Publisher' of my Python 2.4 and 2.5 installs is shown as Martin v. Lowis. Whilst I *personally* find this very reassuring I wonder if this is intended / ideal? All the best, Michael Foord ___ 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 Windows Installers
Michael Foord wrote: Hello all, I'm just doing some housekeeping on a Windows install, and notice that the 'Publisher' of my Python 2.4 and 2.5 installs is shown as Martin v. Lowis. Whilst I *personally* find this very reassuring I wonder if this is intended / ideal? Just to clarify, this is on Windows Vista and shown in the Control Panel Programs and Features (what used to be Add/Remove Programs). Installers were from Python.org. Michael Foord All the best, Michael Foord ___ 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/fuzzyman%40voidspace.org.uk ___ 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] Py3k DeprecationWarning in stdlib
On Tue, Jun 24, 2008 at 5:34 AM, Nick Coghlan [EMAIL PROTECTED] wrote: I'd say so, yes. If tracker issues don't exist yet, please create them. The focus for the first beta was really on getting all the syntax and API changes stable - the remaining time between the first beta release and the first release candidate will focus on cleaning up issues like this. I wonder if we could just 2to3 (with fixers that create incompatibilities disabled) over the whole stdlib and see what happens. -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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] Py3k DeprecationWarning in stdlib
Benjamin Peterson wrote: On Tue, Jun 24, 2008 at 5:34 AM, Nick Coghlan [EMAIL PROTECTED] wrote: I'd say so, yes. If tracker issues don't exist yet, please create them. The focus for the first beta was really on getting all the syntax and API changes stable - the remaining time between the first beta release and the first release candidate will focus on cleaning up issues like this. I wonder if we could just 2to3 (with fixers that create incompatibilities disabled) over the whole stdlib and see what happens. Just running the unit test suite with -3 would probably be a better starting point. 2to3 makes a lot of extra changes that we don't particularly care about. 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] Py3k DeprecationWarning in stdlib
On Tue, Jun 24, 2008 at 8:08 AM, Nick Coghlan [EMAIL PROTECTED] wrote: Benjamin Peterson wrote: On Tue, Jun 24, 2008 at 5:34 AM, Nick Coghlan [EMAIL PROTECTED] wrote: I'd say so, yes. If tracker issues don't exist yet, please create them. The focus for the first beta was really on getting all the syntax and API changes stable - the remaining time between the first beta release and the first release candidate will focus on cleaning up issues like this. I wonder if we could just 2to3 (with fixers that create incompatibilities disabled) over the whole stdlib and see what happens. Just running the unit test suite with -3 would probably be a better starting point. 2to3 makes a lot of extra changes that we don't particularly care about. Right, which is why I suggest running a few fixers (ie fix_has_key) and then tearing the test suite apart. -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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
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] Py3k DeprecationWarning in stdlib
The same generic warning against sweeping changes applies here though. You have to manually review each change. The stdlib and especially the test suite is likely to break if you just let 2to3 run over it, even just a single fixer like fix_has_key. On Tue, Jun 24, 2008 at 6:11 AM, Benjamin Peterson [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 8:08 AM, Nick Coghlan [EMAIL PROTECTED] wrote: Benjamin Peterson wrote: On Tue, Jun 24, 2008 at 5:34 AM, Nick Coghlan [EMAIL PROTECTED] wrote: I'd say so, yes. If tracker issues don't exist yet, please create them. The focus for the first beta was really on getting all the syntax and API changes stable - the remaining time between the first beta release and the first release candidate will focus on cleaning up issues like this. I wonder if we could just 2to3 (with fixers that create incompatibilities disabled) over the whole stdlib and see what happens. Just running the unit test suite with -3 would probably be a better starting point. 2to3 makes a lot of extra changes that we don't particularly care about. Right, which is why I suggest running a few fixers (ie fix_has_key) and then tearing the test suite apart. -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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/guido%40python.org -- --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 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
[Python-Dev] setitimer, getitimer wrapper (issue2240)
Hello, It has been some time since some discussion happened on http://bugs.python.org/issue2240, and I intended to compose this email several days ago but just did it now. This is an attempt to find someone who might have some information/idea that could help solving the current problem regarding the setitimer/getitimer wrapper under FreeBSD (and maybe somewhere else?). The current problem is that the virtual and prof itimers, in some occasions, may never finish, and as I remember from talking with Trent Nelson, the problem showed up when running all the tests but not when running the test_signal alone. So, that is it.. any solutions ? :) Regards, -- -- Guilherme H. Polo Goncalves ___ 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 Windows Installers
I'm just doing some housekeeping on a Windows install, and notice that the 'Publisher' of my Python 2.4 and 2.5 installs is shown as Martin v. Lowis. Whilst I *personally* find this very reassuring I wonder if this is intended / ideal? I certainly intended it: the field really is called the author file in MSI, and is (was) intended to indicate the manufacturer of the MSI, see http://msdn.microsoft.com/en-us/library/aa367808(VS.85).aspx That Vista calls it publisher is somewhat ambiguous. In any case, bug #1737210 complained about it, and I changed it to Python Software Foundation. I can't retroactively change it for the releases you are looking at. 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 Windows Installers
Martin v. Löwis wrote: I'm just doing some housekeeping on a Windows install, and notice that the 'Publisher' of my Python 2.4 and 2.5 installs is shown as Martin v. Lowis. Whilst I *personally* find this very reassuring I wonder if this is intended / ideal? I certainly intended it: the field really is called the author file in MSI, and is (was) intended to indicate the manufacturer of the MSI, see http://msdn.microsoft.com/en-us/library/aa367808(VS.85).aspx That Vista calls it publisher is somewhat ambiguous. In any case, bug #1737210 complained about it, and I changed it to Python Software Foundation. I can't retroactively change it for the releases you are looking at. No problem. I was more concerned about future releases. All the best, Michael Foord Regards, Martin -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.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
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] Py3k DeprecationWarning in stdlib
On Tue, Jun 24, 2008 at 11:42 AM, Guido van Rossum [EMAIL PROTECTED] wrote: The same generic warning against sweeping changes applies here though. You have to manually review each change. The stdlib and especially the test suite is likely to break if you just let 2to3 run over it, even just a single fixer like fix_has_key. So be it. We'll go over each module individually as with #3189. -- Cheers, Benjamin Peterson There's no place like 127.0.0.1. ___ 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] Py3k DeprecationWarning in stdlib
Benjamin Peterson wrote: On Tue, Jun 24, 2008 at 11:42 AM, Guido van Rossum [EMAIL PROTECTED] wrote: The same generic warning against sweeping changes applies here though. You have to manually review each change. The stdlib and especially the test suite is likely to break if you just let 2to3 run over it, even just a single fixer like fix_has_key. So be it. We'll go over each module individually as with #3189. We need to be especially careful with the unit test suite itself - changing the test code to avoid the warning will normally be the right answer, but when the code is actually setting out to test the deprecated feature we need to suppress the warning in the test suite instead. I should have a decent amount of Python time available later this week/weekend, so I should be able to help with this once I get the updated docs for special method lookup knocked over as well as checking in the somewhat related fix for the following 2.5 behaviour: print unicode(Exception) type 'exceptions.Exception' print unicode(u\xa3) £ print unicode(Exception(u\xa3)) Traceback (most recent call last): File stdin, line 1, in module UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in position 0: ordinal not in range(128) (The idea being to get that last line printing the same thing as the second line, just as unicode(Exception(A)) produces the answer uA, but without breaking the current behaviour of the first line) 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] Py3k DeprecationWarning in stdlib
On 10:05 pm, [EMAIL PROTECTED] wrote: We need to be especially careful with the unit test suite itself - changing the test code to avoid the warning will normally be the right answer, but when the code is actually setting out to test the deprecated feature we need to suppress the warning in the test suite instead. This is a dangerous road to go down. If you suppress warnings in the test suite, you might suppress additional warnings which should actually be reported. Or, if the API gets modified in some way that the warning is supposed to be emitted but isn't any longer, it will be silent. It's easy to accidentally suppress too much or not enough. The way we've dealt with this in Twisted is adding an 'assertWarns' method so that we can invoke an API that is supposed to generate a warning, and (A) that warning and only that *specific* warning will not be emitted, and (B) if the API stops emitting the warning in the future, the test will fail and we will notice. It's also nice to have this facility in the test harness itself, so that you don't run the additional risk of accidentally (and silently) leaving warning suppression in place for subsequent tests. ___ 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] Py3k DeprecationWarning in stdlib
On Tue, 24 Jun 2008 23:03:33 -, [EMAIL PROTECTED] wrote: On 10:05 pm, [EMAIL PROTECTED] wrote: We need to be especially careful with the unit test suite itself - changing the test code to avoid the warning will normally be the right answer, but when the code is actually setting out to test the deprecated feature we need to suppress the warning in the test suite instead. This is a dangerous road to go down. If you suppress warnings in the test suite, you might suppress additional warnings which should actually be reported. Or, if the API gets modified in some way that the warning is supposed to be emitted but isn't any longer, it will be silent. It's easy to accidentally suppress too much or not enough. The way we've dealt with this in Twisted is adding an 'assertWarns' method so that we can invoke an API that is supposed to generate a warning, and (A) that warning and only that *specific* warning will not be emitted, and (B) if the API stops emitting the warning in the future, the test will fail and we will notice. It's also nice to have this facility in the test harness itself, so that you don't run the additional risk of accidentally (and silently) leaving warning suppression in place for subsequent tests. It would be *extra* nice to have this facility added to the standard library, since assertWarns in Twisted is broken by changes in Python 2.6 (ie, our tests for warnings all fail with [EMAIL PROTECTED]). For now, we will probably address this by switching to a different warning API. In the long term, it'd be better for us, other Python developers, and the standard library if there were an API in the standard library which facilitated testing of warnings. Jean-Paul ___ 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/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
Issue 3008 has been re-opened for more commentary. Raymond - Original Message - From: Guido van Rossum [EMAIL PROTECTED] 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. ___ 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/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c
I don't want the discussion in the issue. I want to have it right here. While I think it's fine to have some function that reveals the binary representation of floats, I don't think that overlaying this on hex/oct/bin is worth the problems it causes. This API appears to be purely for educational purposes; why not implement something in pure Python using the struct module that reveals the lay-out of the floating-point value? (There are also several things wrong with the specific patch, apart from its lack of docs; #1 is the introduction of an externaly visible symbol that doesn't start with _Py.) --Guido On Tue, Jun 24, 2008 at 8:20 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: Issue 3008 has been re-opened for more commentary. Raymond - Original Message - From: Guido van Rossum [EMAIL PROTECTED] 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
