-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Validate that 'name' attribute is set only if hashable #9193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
a few points:
@property
def name(self):
return self._name
@name.setter
def name(self, value):
try:
hash(value)
except TypeError:
raise TypeError('name must be hashable')
self._name = name |
Thanks. Makes sense to me. What next? Shall I try and make another commit on this branch while the Am 04.01.2015 um 20:51 schrieb Stephan Hoyer:
|
@dr-leo just make a new commit on this PR |
There was recently introduced a |
@joris: sorry, don't know how to use code from another PR in my own. @ALL: I've just committed what will hopefully do part of the trick. I've The test suite produces some failures: in test_series, line 1999, e.g., Still there are 13 failures and one error out of 8027 tests. At least Please let me know your views on the test results and what it would As this is my very first PR for a serious project, I am somewhat baffled Anyway, so far it has been fun to work on this and I've learnt quite a bit. Thanks. Leo Am 05.01.2015 um 23:44 schrieb Joris Van den Bossche:
|
def name(self, value): | ||
try: | ||
hash(value) | ||
except TypeError: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could replace this with just if not com.is_hashable(value):
.
@dr-leo The other PR is already merged, so you can just use the function it introduced directly. Trust me, this gets easier with practice :) |
I'm pretty sure the test failures you're getting is because |
Actually, that theory is wrong. None actually is hashable. |
OK, it looks like the trouble here is related to some strange business pandas does with overwriting |
needs a test to see if this survives pickling |
Got you. Should all be doable. On 13/01/2015, jreback [email protected] wrote:
|
On picling: There is already a testcase in test_series @411: So I don't see any need for another. On common.is_hashable: It returns False for NP.float64 (see below). This In [3]: import numpy as NP In [5]: f=NP.float64(3.14) In [8]: hash(f) In [9]: import pandas In [11]: from pandas.core.common import is_hashable In [12]: is_hashable(f) Am 13.01.2015 um 00:55 schrieb jreback:
|
@dr-leo what version of numpy are you running? I'm seeing a different result on numpy 1.9.1 |
np1.9.1, py34,32bit, win7 64bit. Am 15.01.2015 um 23:35 schrieb Stephan Hoyer:
|
Great! However, I am unfamiliar with rebase. To make things worse, I work with My hope was that you could simply merge my little PR branch into Leo Am 17.02.2015 um 03:23 schrieb Stephan Hoyer:
|
|
||
@name.setter | ||
def name(self, value): | ||
if is_hashable(value): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do if value is not None here as it's the most common case
needs a perf check |
|
||
def test_constructor_unhashable_name(self): | ||
def set_to_unhashable(s_): | ||
s_.name = {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs a test on the construcor as well
closing pls reopen if/when updated |
addresses part of issue #8263.