Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign up[WIP] Implement dict to receive Object as key #119
Conversation
codecov-io
commented
Oct 19, 2019
Codecov Report
@@ Coverage Diff @@
## master #119 +/- ##
=========================================
- Coverage 72.85% 72.2% -0.66%
=========================================
Files 60 60
Lines 11949 12057 +108
=========================================
Hits 8706 8706
- Misses 2709 2815 +106
- Partials 534 536 +2
Continue to review full report at Codecov.
|
|
Since Hash is not implemented properly in gpython, I'm going to implement a dict that takes an Object as a key first. So, even if an object representing the same value comes in as key, the value is not found correctly. This can break the test code, so instead of getting rid of StringDict, I will fully implement Dict and replace StringDict with Dict. |
|
I put some notes inline... Making a Dict is quite a dififcult thing to do (probably why I didn't do it originally!) Perhaps the thing to do to start with would be to make one with a simple internal structure which is just type keyValue {
key Object
value Object
}
type Dict struct {
kvs []keyValue
}And make that work. Yes it won't be very efficient if there are lots of keys, but it should enable us to get the interface right, then we can work on optimizing it. I note that in go1.14 the go team will expose the internal hashing function which would make implementing this much easier. |
| } | ||
|
|
||
| // String to object dictionary | ||
| // | ||
| // Used for variables etc where the keys can only be strings | ||
| type StringDict map[string]Object | ||
|
|
||
| type Dict struct { | ||
| keys map[Object]int |
This comment has been minimized.
This comment has been minimized.
ncw
Oct 21, 2019
Collaborator
I don't think this is the right representation alas...
Putting the Object as the key means that you are relying on how Go compares interfaces. It does this with a shallow compare. An interface is basically
- pointer to type
- pointer to data
so comparing two interfaces just compares the pointer to type and pointer to data - it doesn't compare the data.
This means that you could insert two objects eg py.String("hello") and py.String("hello") and these would both get inserted into the dictionary.
I think what we want as the key is
- python type
- hash of object
And the values need to be a []Object (because different objects can have the same hash).
This comment has been minimized.
This comment has been minimized.
HyeockJinKim
Oct 23, 2019
•
Author
Contributor
There is no hash implementation, so I've got Object as key now.
We only receive hash values as key values. so I'm going to get int as the key.
What do you think about this way?
type Dict struct {
keys map[int]int // int key
This comment has been minimized.
This comment has been minimized.
ncw
Oct 25, 2019
Collaborator
I think maybe we should try the really simple version first, then we can make it more efficient later
type dictEntry struct {
key Object
value Object
}
type Dict struct {
entries []dictEntry
}
This comment has been minimized.
This comment has been minimized.
sbinet
Oct 30, 2019
Member
@ncw, to be nit-picky, the way py.String is currently implemented, I believe this would work.
see:
https://play.golang.org/p/bDvOEmkim6r
(ie: py.String just contains values and no pointers.)
but ok with going with the KISS version first.
This comment has been minimized.
This comment has been minimized.
ncw
Oct 30, 2019
Collaborator
Indeed! The problem comes when the py.Object interface is satisfied with a pointer: https://play.golang.org/p/vf4dGmh0Gb4
HyeockJinKim commentedOct 19, 2019
Implement dict struct that takes Object as key
store key and value in array together so that dict is ordered
Issue #118