I'm using Priority Queues and followed the Python documentation for a simple example.

From Queue documentation in Python 3.3
http://docs.python.org/3.3/library/queue.html
"
The lowest valued entries are retrieved first (the lowest valued entry is the one returned by sorted(list(entries))[0]). A typical pattern for entries is a tuple in the form: (priority_number, data).
"

Then I tried this simple code.

>>> pq = PriorityQueue()
>>> pq.put_nowait((0, {'a':1}))
>>> pq.put_nowait((0, {'a':2}))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.3/queue.py", line 187, in put_nowait
return self.put(item, block=False)
File "/usr/lib/python3.3/queue.py", line 146, in put
self._put(item)
File "/usr/lib/python3.3/queue.py", line 230, in _put
heappush(self.queue, item)
TypeError: unorderable types: dict() < dict()

Is this a normal behaviour? I'm not sure if this should be declared as a bug...

Instead of sticking to the first argument that indicates the priority, the heapq algorithm checks the second field and tries to order the dictionaries.

I solved this annoyance by adding a  third field, the object ID. Since the object ID is actually its address in memory, every object will have a different ID. Also, since the queue entries will have the same priority (zero), the id value is used to order the tuples in the heap queue.

>>> pq = PriorityQueue()
>>> a = {'a':1}
>>> b = {'a':2}
>>> pq.put_nowait((0, id(a), a))
>>> pq.put_nowait((0, id(b), b))

It is a bug of some sort.  A doc bug if nothing else.  This is probably due to the fact that everything was sortable in python2, and the doc and/or code hasn't been updated to account for the fact that many things aren't in Python3.

from the peanut gallery:

This looks right to me; you are seeing that PriorityQueue is trying to compare dicts, because that's how tuple comparison works: it is lexicographic. Since the first element of the two tuples that you are trying to insert have the same value, comparison of the two tuple reduces to comparing the second elements.

Your work around also looks good to me.

Hmm.  It's true that Python 3's comparison rules make PriorityQueue a bit less useful in its current form.

One possible workaround could be to introduce an optional "key" argument to the constructor that provides a callable used to map objects added to the queue to their priorities.  The default key would map each object to itself, as before, but for a use-case like this one the key could just be lambda x: x[0].

Example patch.  Items with equal priority are retrieved in LIFO order.

Hmm.  This looks like a duplicate of #7174.

Fixed patch.

I'm working on this one.  Expect a patch shortly.

btw, I have a related patch: http://bugs.python.org/issue17834 Chances of it being accepted aren't looking good right now though.

Related issues: issue4356, issue13742.

See also issue1185383, issue1904 and issue1162363.

Starting in Python 3.7, dataclasses made it trivially easy to work around this issue.  The PriorityQueue docs have a worked out example of how to do this: https://docs.python.org/3/library/queue.html#queue.PriorityQueue