[
https://issues.apache.org/jira/browse/TINKERPOP-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18068458#comment-18068458
]
ASF GitHub Bot commented on TINKERPOP-3232:
-------------------------------------------
xiazcy opened a new pull request, #3359:
URL: https://github.com/apache/tinkerpop/pull/3359
https://issues.apache.org/jira/browse/TINKERPOP-3232
Originally thought of using HashableDict, but ended up with deserializing
into list instead due to potential hash collision and silent mutations of
nested objects. Given gremlin-go also uses lists to back its custom set type,
this wouldn't be an exclusion. Also this best preserves the inner data and
type, which is usually what users operate on.
However, I did keep a commit with the HashableDict.of() in case we favor
that solution instead. Note there could be an improvement to this, where we use
`frozenset` for `set` instead of `tuple` in the HashableDict implementation.
(I will add CHANGELOG entry after the decision is made on the approach.)
VOTE +1
> Support deserialization of a set that has a non hashable element
> ----------------------------------------------------------------
>
> Key: TINKERPOP-3232
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3232
> Project: TinkerPop
> Issue Type: Improvement
> Components: python
> Affects Versions: 3.8.0, 3.7.5
> Reporter: Ken Hu
> Priority: Blocker
>
> The set type in Python can only contain hashable types so it can't have
> "container" types that are commonly returned in Gremlin. This causes issues
> when trying to deserialize a Set that does contain these types as the set
> will throw a TypeError.
> Some potential solutions include:
> * Deserializing to list in these cases instead of set
> * Using the HashableDict type from util like what was done for Map
> An example query that can return such an error is:
> {code:java}
> g.V().valueMap().dedup(Scope.local)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
