Issue 274 in protobuf: Python generated protobufs are not hashable in 2.4.0a

[prot...@googlecode.com]

Status: New
Owner: ken...@google.com
Labels: Type-Defect Priority-Medium

New issue 274 by wbm...@gmail.com: Python generated protobufs are not
hashable in 2.4.0a
http://code.google.com/p/protobuf/issues/detail?id=274

What steps will reproduce the problem?
1. Create a protobuf object in python
2. Try to put it into a set or a map
3. Declare success/failure

What is the expected output? What do you see instead?
In 2.3.0, the protobuf objects were hashable, but in 2.4.0a it seems as
though this functionality has been removed.

What version of the product are you using? On what operating system?
2.4.0a

Please provide any additional information below.
This is clearly a conscious choice, since the message.py is throwing the
exception, but I'm surprised by the backward incompatibility (and the lack
of documentation surrounding the change). Is there a reason this was done?
Is some subclass supposed to override __hash__? Is there a flag I can set
somewhere to make messages hashable?

[prot...@googlecode.com]

Updates:
Status: WorkingAsIntended

Comment #1 on issue 274 by liuj...@google.com: Python generated protobufs

are not hashable in 2.4.0a
http://code.google.com/p/protobuf/issues/detail?id=274

Sorry we didn't mention this in document. Quote from our internal change
log:

Python proto2 API protobufs are no longer hashable.

They previously inherited object.__hash__(), which is not consistent
with their custom __eq__() and __ne__() methods. This is a simple fix.
Any code broken by this change was already broken in a more subtle manner.

If you want sets or mappings of protobufs, use their
SerializePartialToString() output, which /should/ be deterministic and
consistent for any particular build of a binary/PAR. Only use actual
SerializePartialToString() output however, _not_ pre-encoded protobufs read
from the disk/wire/etc! They may not be encoded consistently, so parse and
then re-encode them to be safe.

A proper __hash__() method for protobufs, consistent with __eq__() and
__ne__(), could be implemented in the future. It would have the caveat
that profobufs must not be modified while in use as keys. Given that
restriction, it might be best to leave protobufs as unhashable.

[prot...@googlecode.com]

Comment #2 on issue 274 by wbm...@gmail.com: Python generated protobufs are

not hashable in 2.4.0a
http://code.google.com/p/protobuf/issues/detail?id=274

Thanks for the clarification and the recommendation. I assumed there was a
good reason and it looks like now, even if I don't upgrade to 2.4.0 right
away I need to fix some potential bugs in my code.