You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like the return values are slightly inconsistent. It makes sense that when peeking and items == 1 a value is returned or None if there are no items in the queue, and when items > 1 a list is returned. What should be the behavior for items == 0?
I propose that when items == 0, None is returned for both peek and get operations, rather than an empty list.
This means that peek can return 3 types of values: None, a value, and a list. get can return 4 types of values: None, a value, a list, and an Empty exception. That seems like a lot of different return types.
Yes this is a very tricky issue. Considering #9, returning None is also troublesome...
I guess we first have to prohibit None from being used as item value. Then we can use it as return value.
#16 fixes #9 without prohibiting None. I leave it up to the user to figure out if the None is from the queue or because there is nothing in the queue. If the user wants to distinguish, they can check the size of the queue.
Activity
Kriechi commentedon Dec 14, 2016
Yes this is a very tricky issue. Considering #9, returning
Noneis also troublesome...I guess we first have to prohibit
Nonefrom being used as item value. Then we can use it as return value.philipbl commentedon Dec 14, 2016
#16 fixes #9 without prohibiting None. I leave it up to the user to figure out if the
Noneis from the queue or because there is nothing in the queue. If the user wants to distinguish, they can check the size of the queue.Kriechi commentedon Dec 14, 2016
Checking the size and calling
getorpeekhas an inherent race condition - if the user doesn't use our internal mutex.