On 1/31/2012 3:10 PM, Raymond Hettinger wrote:
On Jan 29, 2012, at 6:11 PM, John O'Connor wrote:
On Sat, Jan 28, 2012 at 3:07 PM, Benjamin Peterson
mailto:benja...@python.org>> wrote:
But why would you want to pass a float? It seems like API abuse to me.
Agreed. Anything else seems meaning
I concur. This is very much a non-problem.
There is no need to add more code and slow
running time with superfluous type checks.
Raymond
What do you think about the following check from threading.py:
@@ -317,8 +317,6 @@
self._value = value
def acquire(self, blocking=True, time
On Jan 29, 2012, at 6:11 PM, John O'Connor wrote:
> On Sat, Jan 28, 2012 at 3:07 PM, Benjamin Peterson
> wrote:
>> But why would you want to pass a float? It seems like API abuse to me.
>>
>
> Agreed. Anything else seems meaningless.
I concur. This is very much a non-problem.
There is no ne
On 2012-01-31 00:23, Benjamin Peterson wrote:
2012/1/30 Nick Coghlan:
On Tue, Jan 31, 2012 at 8:11 AM, Matt Joiner wrote:
It's also potentially lossy if you incremented and decremented until integer
precision is lost. My vote is for an int type check. No casting.
operator.index() is built fo
2012/1/30 Nick Coghlan :
> On Tue, Jan 31, 2012 at 8:11 AM, Matt Joiner wrote:
>> It's also potentially lossy if you incremented and decremented until integer
>> precision is lost. My vote is for an int type check. No casting.
>
> operator.index() is built for that purpose (it's what we use these
On Mon, Jan 30, 2012 at 2:11 PM, Matt Joiner wrote:
> It's also potentially lossy if you incremented and decremented until integer
> precision is lost. My vote is for an int type check. No casting.
+1. Anything else is insane scope creep for something called "Semaphore".
--
--Guido van Rossum (
On Tue, Jan 31, 2012 at 8:11 AM, Matt Joiner wrote:
> It's also potentially lossy if you incremented and decremented until integer
> precision is lost. My vote is for an int type check. No casting.
operator.index() is built for that purpose (it's what we use these
days to restrict slicing to inte
It's also potentially lossy if you incremented and decremented until
integer precision is lost. My vote is for an int type check. No casting.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 2012-01-30 20:52, Guido van Rossum wrote:
TB, what's your use case for passing a float to a semaphore?
Semaphores are conceptually tied to integers. You've kept arguing a
few times now that the workaround you need are clumsy, but you've not
explained why you're passing floats in the first plac
TB, what's your use case for passing a float to a semaphore?
Semaphores are conceptually tied to integers. You've kept arguing a
few times now that the workaround you need are clumsy, but you've not
explained why you're passing floats in the first place. A "fractional
resource" just doesn't sound l
On 2012-01-30 01:46, Victor Stinner wrote:
But why would you want to pass a float? It seems like API abuse to me.
If something should be changed, Semaphore(arg) should raise a
TypeError if arg is not an integer.
Short version:
I propose the the change to be
-while self._value == 0:
On Sat, Jan 28, 2012 at 3:07 PM, Benjamin Peterson wrote:
> But why would you want to pass a float? It seems like API abuse to me.
>
Agreed. Anything else seems meaningless.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
>> import threading
>> s = threading.Semaphore(0.5)
>
> But why would you want to pass a float? It seems like API abuse to me.
If something should be changed, Semaphore(arg) should raise a
TypeError if arg is not an integer.
Victor
___
Python-Dev mailin
2012/1/28 T.B. :
> Hello python-dev,
>
> This is probably worth of a bug report: While looking at threading.py I
> noticed that Semaphore's counter can go below zero. This is opposed to the
> docs: "The counter can never go below zero; ...". Just try:
>
> import threading
> s = threading.Semaphore(
14 matches
Mail list logo
