> 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/m
[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 t
>> 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 th
[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 t
On Fri, Mar 6, 2009 at 5:17 PM, Raymond Hettinger 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 i
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.
Okay, that's fine. Seemed prudent but it isn't essential.
This is for a feature
that has a
On Fri, Mar 6, 2009 at 7:19 PM, "Martin v. Löwis" 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 th
>> 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
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
[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.
> 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
removin
On Thu, Mar 5, 2009 at 2:27 PM, Steve Holden 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
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/
_
On Thu, Mar 5, 2009 at 1:43 AM, Tennessee Leeuwenburg
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
On Wed, Mar 4, 2009 at 17:30, Raymond Hettinger 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.
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 t
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
_
Yup, I'd need to remove support in multiprocessing too.
On Mar 4, 2009 8:39pm, Tennessee Leeuwenburg 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 a
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/pyt
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
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 a
2009/3/4 Raymond Hettinger :
> 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 d
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.
Raymond
___
Python-Dev m
23 matches
Mail list logo
