Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
I still fail to see the rationale for removing these two methods. I believe there was a thread (in January 2008) with a decision to keep qsize() but to drop empty() and full(). That's something different: even if there was a decision, it doesn't mean that there was a rationale, and that the rationale was correct. I see that you proposed to remove the methods because they are unreliable. I still think this classification is incorrect: they are *not* unreliable. They do what they do correctly and reliably. Looking at the discussion (on python-3000), I don't see that an actual decision was made. You proposed it, there was a *lot* of objections. Guido proposed a compromise (without indicating whether he was in favor of the removal in the first place). There was then still opposition both to leaving qsize, and to change anything at all - and then you removed the methods. At this point, I do request that the patch is reverted completely (i.e. that the documentation is restored), and that the qualification not reliable! is removed from the doc strings of the methods, as it is factually incorrect. 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
[MvL] At this point, I do request that the patch is reverted completely (i.e. that the documentation is restored), and that the qualification not reliable! is removed from the doc strings of the methods, as it is factually incorrect. I would be happy to restore the documentation. You want the methods back and I think that's sufficient reason to bring it back. The not reliable wording in the docstrings was put there by Guido 16 years ago. http://svn.python.org/view/python/trunk/Lib/Queue.py?revision=3158view=markup Speak to him about this. I'm done with this thread. Raymond ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
I would be happy to restore the documentation. You want the methods back and I think that's sufficient reason to bring it back. Thanks! I'll look into the docstrings. 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
IIRC, that was the rationale for cmp() removal in 3.0.1. And indeed, that removal already caused a bug report and broke the efforts of SWIG to support Python 3.0. I disagree that our users are served by constantly breaking the API, and removing stuff just because we can. I can't see how removing API can possibly serve a user. What's wrong with empty() and full() in the first place? 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
[Martin v. Löwis] I disagree that our users are served by constantly breaking the API, and removing stuff just because we can. I can't see how removing API can possibly serve a user. Am not following you here. My suggestion was to remove the two methods in Py3.1 which isn't even in alpha yet. This is for a feature that has a simple substitute, was undocumented for Py3.0, and had long been documented in Py2.x as being unreliable. It's seems silly to me that an incomplete patch from a year ago would need to wait another two years to ever see the light of day (am presuming that 3.1 goes final this summer and that 3.2 follows 18 months later). That being said, I don't really care much. We don't actually have to do anything. It could stay in forever and cause no harm. Raymond ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
I don't mind whether its in or out, but as a language user I think it's best to minimise undocumented interfaces. According to that principle, if it's in, then it should also work as documented (and be documented), and be supported. If it's out then it should either be removed entirely or be marked private (i.e. leading underscore, unless I'm mistaking my style guidelines). Cheers, -T On Sat, Mar 7, 2009 at 10:19 AM, Raymond Hettinger pyt...@rcn.com wrote: [Martin v. Löwis] I disagree that our users are served by constantly breaking the API, and removing stuff just because we can. I can't see how removing API can possibly serve a user. Am not following you here. My suggestion was to remove the two methods in Py3.1 which isn't even in alpha yet. This is for a feature that has a simple substitute, was undocumented for Py3.0, and had long been documented in Py2.x as being unreliable. It's seems silly to me that an incomplete patch from a year ago would need to wait another two years to ever see the light of day (am presuming that 3.1 goes final this summer and that 3.2 follows 18 months later). That being said, I don't really care much. We don't actually have to do anything. It could stay in forever and cause no harm. Raymond ___ 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/tleeuwenburg%40gmail.com -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
I disagree that our users are served by constantly breaking the API, and removing stuff just because we can. I can't see how removing API can possibly serve a user. Am not following you here. My suggestion was to remove the two methods in Py3.1 which isn't even in alpha yet. Your proposal was also to add a warning for 3.0.2. This is what I primarily object to. This is for a feature that has a simple substitute, was undocumented for Py3.0, and had long been documented in Py2.x as being unreliable. The latter is not true. It was not documented as unreliable. Instead, it was correctly documented as not being able, in general, to predict the result of a subsequent put operation. In that sense, it is as unreliable as the qsize() method, which remains supported and documented. Interestingly enough, the usage of .empty() in test_multiprocessing is entirely safe, AFAICT. So whether the API is reliable or unreliable very much depends on the application (as is true for many multi-threading issues). It's seems silly to me that an incomplete patch from a year ago would need to wait another two years to ever see the light of day Right. So it might be better to revert the patch, and restore the documentation. I still fail to see the rationale for removing these two methods. 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
On Fri, Mar 6, 2009 at 7:19 PM, Martin v. Löwis mar...@v.loewis.de wrote: I disagree that our users are served by constantly breaking the API, and removing stuff just because we can. I can't see how removing API can possibly serve a user. Am not following you here. My suggestion was to remove the two methods in Py3.1 which isn't even in alpha yet. Your proposal was also to add a warning for 3.0.2. This is what I primarily object to. This is for a feature that has a simple substitute, was undocumented for Py3.0, and had long been documented in Py2.x as being unreliable. The latter is not true. It was not documented as unreliable. Instead, it was correctly documented as not being able, in general, to predict the result of a subsequent put operation. In that sense, it is as unreliable as the qsize() method, which remains supported and documented. Interestingly enough, the usage of .empty() in test_multiprocessing is entirely safe, AFAICT. So whether the API is reliable or unreliable very much depends on the application (as is true for many multi-threading issues). It's seems silly to me that an incomplete patch from a year ago would need to wait another two years to ever see the light of day Right. So it might be better to revert the patch, and restore the documentation. I still fail to see the rationale for removing these two methods. Regards, Martin I would tend to agree with Martin, while it might be nice to straightjacket the API into completely reliable calls (really, is there anything like that with threads?) empty and the like when used correctly work just fine. I think anyone using Queue with threads will generally understand that size/empty calls will only be reliable when put calls are completed. We can continue to warn them about the issues with using it with continual producers, but as martin points out, qsize suffers the same issue. -jesse ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
On Fri, Mar 6, 2009 at 5:17 PM, Raymond Hettinger pyt...@rcn.com wrote: I believe there was a thread (in January 2008) with a decision to keep qsize() but to drop empty() and full(). Based on our experiences so far, I think that of the two options we have, both of which are bad, it's better to keep things in 3.1 that we were planning to remove but forgot, than to make 3.1 have a whole slew of additional removals. We've removed cmp() in 3.0.1, and I think that was actually the right thing to do given its prominence and the clear decision to remove it, but for smaller stuff that didn't make the cut I think we should favor backwards compatibility over cleanup. -- --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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
[Guido van Rossum] Based on our experiences so far, I think that of the two options we have, both of which are bad, it's better to keep things in 3.1 that we were planning to remove but forgot, than to make 3.1 have a whole slew of additional removals. We've removed cmp() in 3.0.1, and I think that was actually the right thing to do given its prominence and the clear decision to remove it, but for smaller stuff that didn't make the cut I think we should favor backwards compatibility over cleanup. To some extent we get both by leaving them in the module but continuing to be left out of the docs. Raymond ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
On Wed, Mar 4, 2009 at 17:30, Raymond Hettinger pyt...@rcn.com wrote: Just noticed that the empty() and full() methods were still there. IIRC, we agreed to take them out (but leaving qsize() exposed). The docs entries and test cases were taken out, but the actual methods were accidentally left in. If so, the only thing to do is deprecate it in 3.1 for removal in 3.2. I recommend adding a warning to 3.0.2 and removing in 3.1. Waiting for more 3.x uptake doesn't serve our users well. IIRC, that was the rationale for cmp() removal in 3.0.1. Right, but that's because 3.0.1 was released within four months of 3.0.0. Who knows when 3.0.2 will be released. Having some users suddenly get a new deprecation for some code just because they upgraded their interpreter doesn't sound very backwards-compatible to me. This is true even for a PendingDeprecationWarning. -1 on tossing a warning into 3.0.2 and going +1 with the 3.1 deprecation. -Brett ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
On Thu, Mar 5, 2009 at 1:43 AM, Tennessee Leeuwenburg tleeuwenb...@gmail.com wrote: Hi Jesse, I'm not sure what the most appropriate thing to do is. I could: (a) leave any multiprocessing changes to you, (b) alter the functioning of the method queue_empty inside test_multiprocessing to test for emptiness in a different manner I'm happy to go ahead and try my hand at making the appropriate changes but I don't want to tread in areas of the code that other people have ownership of. It appears as though the only place in multiprocessing which uses the deprecated call is in the test_multiprocessing file. I also found a call to Queue.empty in wsgui.py. I don't see any authorship tags at the top of this file but the last commiter was Andrew Kuchling. Do I need to contact him regarding this or is it appropriate for me to make the appropriate modifications without consulting him? Apologies to anyone if I appear to be overly tentative OR overly pushy -- I am aware that some people take a great deal of personal ownership of their works, while others are impatient with a soft approach. Regards, -Tennessee I'm an equal opportunity patch employer: I'll take it from anyone. That being said, I would open a new issue on the tracker (bugs.python.org) outlining the issue (removing these/deprecating them) and add me to the +noisy. There you can upload patches as you create them, and we can all coordinate work and discussion there. For the multiprocessing support - the first step is to identify why it's being used and remove it (I'm head-deep in pycon talk prep, so I haven't been able to look) and then replace the code. Second, I need to make sure the multiprocessing.queue API does not have it's own APIs for these (mp.queue is a clone of queue.queue) and deprecate those. -jesse ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
Jesse Noller wrote: [...]I'll take it from anyone. And we can *quote* you on that? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Want to know? Come to PyCon - soon! http://us.pycon.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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
On Thu, Mar 5, 2009 at 2:27 PM, Steve Holden st...@holdenweb.com wrote: Jesse Noller wrote: [...]I'll take it from anyone. And we can *quote* you on that? regards Steve As long as it's not on a t-shirt, I should be OK. ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
2009/3/4 Raymond Hettinger pyt...@rcn.com: Just notices that the empty() and full() methods were still there. IIRC, we agreed to take them out (but leaving qsize() exposed). The docs entries and test cases were taken out, but the actual methods were accidentally left in. If so, the only thing to do is deprecate it in 3.1 for removal in 3.2. -- Regards, Benjamin ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
That code doesn't look t scary... is trying to add a DeprecationWarning something that I could try to learn how to do and try my hand at? Maybe if someone else would like to address that more quickly, they'd be able to keep me in the loop so I can start learning how Things are Done? It looks as though all that is required is to add a warn message indicating the planned removal? I'm not sure if it's better for me to have a go at things quietly or to be more interactive about getting to grips with the code... Cheers, -T On Thu, Mar 5, 2009 at 12:04 PM, Benjamin Peterson benja...@python.orgwrote: 2009/3/4 Raymond Hettinger pyt...@rcn.com: Just notices that the empty() and full() methods were still there. IIRC, we agreed to take them out (but leaving qsize() exposed). The docs entries and test cases were taken out, but the actual methods were accidentally left in. If so, the only thing to do is deprecate it in 3.1 for removal in 3.2. -- Regards, Benjamin ___ 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/tleeuwenburg%40gmail.com -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
Just noticed that the empty() and full() methods were still there. IIRC, we agreed to take them out (but leaving qsize() exposed). The docs entries and test cases were taken out, but the actual methods were accidentally left in. If so, the only thing to do is deprecate it in 3.1 for removal in 3.2. I recommend adding a warning to 3.0.2 and removing in 3.1. Waiting for more 3.x uptake doesn't serve our users well. IIRC, that was the rationale for cmp() removal in 3.0.1. Even in 2.x, these methods were documented as being unreliable and were removed from the 3.0 docs entirely. We discussed removing them and most of the work was done. Guido, any thoughts? Raymond ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
Hi all, just FYI... sorry for any list pollution I went ahead and tried adding a warning to my local checkout. The test suite raised a DeprecationWarning -- it appears those methods are currently in use by other Lib code: test_multibytecodec_support test_multiprocessing /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning: Queue.empty() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning: Queue.full() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning: Queue.empty() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning: Queue.full() is deprecated, and won't be in 3.2. DeprecationWarning) test_mutants test_netrc test_nis Regards, -T On Thu, Mar 5, 2009 at 12:30 PM, Raymond Hettinger pyt...@rcn.com wrote: Just noticed that the empty() and full() methods were still there. IIRC, we agreed to take them out (but leaving qsize() exposed). The docs entries and test cases were taken out, but the actual methods were accidentally left in. If so, the only thing to do is deprecate it in 3.1 for removal in 3.2. I recommend adding a warning to 3.0.2 and removing in 3.1. Waiting for more 3.x uptake doesn't serve our users well. IIRC, that was the rationale for cmp() removal in 3.0.1. Even in 2.x, these methods were documented as being unreliable and were removed from the 3.0 docs entirely. We discussed removing them and most of the work was done. Guido, any thoughts? Raymond ___ 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/tleeuwenburg%40gmail.com -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
Yup, I'd need to remove support in multiprocessing too. On Mar 4, 2009 8:39pm, Tennessee Leeuwenburg tleeuwenb...@gmail.com wrote: Hi all, just FYI... sorry for any list pollution I went ahead and tried adding a warning to my local checkout. The test suite raised a DeprecationWarning -- it appears those methods are currently in use by other Lib code: test_multibytecodec_support test_multiprocessing /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning: Queue.empty() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning: Queue.full() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning: Queue.empty() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning: Queue.full() is deprecated, and won't be in 3.2. DeprecationWarning) test_mutants test_netrc test_nis Regards, -T On Thu, Mar 5, 2009 at 12:30 PM, Raymond Hettinger pyt...@rcn.com wrote: Just noticed that the empty() and full() methods were still there. IIRC, we agreed to take them out (but leaving qsize() exposed). The docs entries and test cases were taken out, but the actual methods were accidentally left in. If so, the only thing to do is deprecate it in 3.1 for removal in 3.2. I recommend adding a warning to 3.0.2 and removing in 3.1. Waiting for more 3.x uptake doesn't serve our users well. IIRC, that was the rationale for cmp() removal in 3.0.1. Even in 2.x, these methods were documented as being unreliable and were removed from the 3.0 docs entirely. We discussed removing them and most of the work was done. Guido, any thoughts? Raymond ___ 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/tleeuwenburg%40gmail.com -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
Yup, I'd need to remove support in multiprocessing too. ahead and tried adding a warning to my local checkout. Thanks for quickly checking this out. Will be nice to get the API cleaned-up. Leaving out part of the clean-up was a mistake. Raymond ___ 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] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()
Hi Jesse, I'm not sure what the most appropriate thing to do is. I could: (a) leave any multiprocessing changes to you, (b) alter the functioning of the method queue_empty inside test_multiprocessing to test for emptiness in a different manner I'm happy to go ahead and try my hand at making the appropriate changes but I don't want to tread in areas of the code that other people have ownership of. It appears as though the only place in multiprocessing which uses the deprecated call is in the test_multiprocessing file. I also found a call to Queue.empty in wsgui.py. I don't see any authorship tags at the top of this file but the last commiter was Andrew Kuchling. Do I need to contact him regarding this or is it appropriate for me to make the appropriate modifications without consulting him? Apologies to anyone if I appear to be overly tentative OR overly pushy -- I am aware that some people take a great deal of personal ownership of their works, while others are impatient with a soft approach. Regards, -Tennessee On Thu, Mar 5, 2009 at 12:41 PM, jnol...@gmail.com wrote: Yup, I'd need to remove support in multiprocessing too. On Mar 4, 2009 8:39pm, Tennessee Leeuwenburg tleeuwenb...@gmail.com wrote: Hi all, just FYI... sorry for any list pollution I went ahead and tried adding a warning to my local checkout. The test suite raised a DeprecationWarning -- it appears those methods are currently in use by other Lib code: test_multibytecodec_support test_multiprocessing /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning: Queue.empty() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning: Queue.full() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:98: DeprecationWarning: Queue.empty() is deprecated, and won't be in 3.2. DeprecationWarning) /home/tjl/python3/lib/python3.1/queue.py:109: DeprecationWarning: Queue.full() is deprecated, and won't be in 3.2. DeprecationWarning) test_mutants test_netrc test_nis Regards, -T On Thu, Mar 5, 2009 at 12:30 PM, Raymond Hettinger pyt...@rcn.com wrote: Just noticed that the empty() and full() methods were still there. IIRC, we agreed to take them out (but leaving qsize() exposed). The docs entries and test cases were taken out, but the actual methods were accidentally left in. If so, the only thing to do is deprecate it in 3.1 for removal in 3.2. I recommend adding a warning to 3.0.2 and removing in 3.1. Waiting for more 3.x uptake doesn't serve our users well. IIRC, that was the rationale for cmp() removal in 3.0.1. Even in 2.x, these methods were documented as being unreliable and were removed from the 3.0 docs entirely. We discussed removing them and most of the work was done. Guido, any thoughts? Raymond ___ 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/tleeuwenburg%40gmail.com -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ Don't believe everything you think ___ 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
