[ 
https://issues.apache.org/jira/browse/THRIFT-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669317#action_12669317
 ] 

Chad Walters commented on THRIFT-162:
-------------------------------------

I have already proposed that we disallow non-basic types as map keys because 
there are several languages for which this is actually problematic (in fact, I 
thought that we had reached general agreement on that but perhaps I am 
mistaken).

The C++ case you present w.r.t. comparators can be worked around, I believe, 
but these others cannot.

I realize I haven't been able to participate as much as I would have liked over 
the past 6 months but I really strongly believe that we should be striving for 
interoperability as one of the foremost goals. Thrift has taken this approach 
in the past -- for example, the decision to support only signed integer types. 
At the least, I'd suggest we try to have a broad discussion about this, since 
it seems like a key decision.

> Thrift structures are unhashable, preventing them from being used as set 
> elements
> ---------------------------------------------------------------------------------
>
>                 Key: THRIFT-162
>                 URL: https://issues.apache.org/jira/browse/THRIFT-162
>             Project: Thrift
>          Issue Type: Bug
>          Components: Compiler (Python), Library (Python)
>            Reporter: Esteve Fernandez
>            Priority: Minor
>         Attachments: thrift_py_hash.patch
>
>
> Let Foo be a Thrift structure:
> struct Foo {
>  1: i32 bar
> }
> If you want to use it properly as a set element or a as a dictionary key, the 
> autoegenerated Python code will complain about not being hashable:
> >>> f1 = Foo()
> >>> f1.bar = 1
> >>> f2 = Foo()
> >>> f2.bar = 1
> >>> f1 == f2
> True
> >>> set([f1]) & set([f2])
> set([])
> >>> d = {}
> >>> d[f1] = 2
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> TypeError: unhashable instance
> Since Thrift structures already implement __eq__ and __ne__, they should 
> implement __hash__ as well. The attached patch tries to mimic the behaviour 
> of the Java compiler, including a HashCodeBuilder class written in Python.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to