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.
Currently, this is how the queue functions when it is empty:
When the queue is has data in it, the following is true:
It seems like the return values are slightly inconsistent. It makes sense that when peeking and
items == 1
a value is returned orNone
if there are no items in the queue, and whenitems > 1
a list is returned. What should be the behavior foritems == 0
?I propose that when
items == 0
, None is returned for bothpeek
andget
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.@Kriechi do you have any thoughts on this?
The text was updated successfully, but these errors were encountered: