-
-
Notifications
You must be signed in to change notification settings - Fork 18.6k
BUG: Regression in chained getitem indexing with embedded list-like from 0.12 (GH6394) #6396
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
BUG: Regression in chained getitem indexing with embedded list-like from 0.12 (GH6394)
This bug is active in 0.13.1 since February (I mean that's when 0.13.1 was released). Don't you think breaking something simple as python test_read.py
/Users/maye/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/scipy/io/idl.py:180: UserWarning: warning: empty strings are now set to '' instead of None
warnings.warn("warning: empty strings are now set to '' instead of None")
0.13.1
Traceback (most recent call last):
File "test_read.py", line 7, in <module>
print df.UVIS[0]
File "/Users/maye/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/pandas-0.13.1-py2.7-macosx-10.6-x86_64.egg/pandas/core/series.py", line 493, in __getitem__
return self._constructor(result,index=[key]*len(result)).__finalize__(self)
File "/Users/maye/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/pandas-0.13.1-py2.7-macosx-10.6-x86_64.egg/pandas/core/series.py", line 220, in __init__
raise_cast_failure=True)
File "/Users/maye/Library/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/pandas-0.13.1-py2.7-macosx-10.6-x86_64.egg/pandas/core/series.py", line 2600, in _sanitize_array
raise Exception('Data must be 1-dimensional')
Exception: Data must be 1-dimensional |
Ok, to be fair, this might be just my highly unusual data. The IDLSAV files are the weirdest creatures. Having 2D numpy arrays per dataframe cell now. |
this is a real special case that is not recommend in any event. To be honest I think we should ban this type of thing, but too late for that. 0.14.0 should be coming shortly anyhow |
Should we work on a better IDLSAV importer? |
what do you do with the after getting the weird scipy object? |
file = 'FUV2005_195_19_52_08_UVIS_011EN_ICYEXO001_PRIME.sav'
tmp = readsav(file)
df = pd.DataFrame.from_records(tmp['datastruct2']) Explanation: the dictionary of readsav has 3 keys, but only the first key contains all the data. |
that's just an odd structure (but maybe you WANT to keep the data like that). |
that's true, I don't know how they created those files. But I could swear I saw exactly the same symptom before: 1 key useful, 2 keys just looking like the end markers of a stone-age C or FORTRAN structure. BTW, wouldn't it be cool if these github issue discussion box could be iPython notebook cells? ;) |
It prob would pay to make these IDL into a useful python object (not just read it in), but allow manipulation of multiple of them (maybe this already exists somewhere)... this is what I do when I have multiple 'things' that are related, separate the bits that are computation/vectorizable into Frames/Panels, etc. and wrap them in objects that are nice |
u mean to write a wrapper class that provides access to the data? Yes, for my case I'm planning to do that. I was just wondering if my case is maybe a standard case of an old saving format of IDL and if newer created structures are all more sane, like the one you found there. Have to understand how this was created. Ah, there might be a version string hidden inside somewhere.. |
yep that's what I mean |
closes #6394