Skip to content
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

API/BUG/CLN: Index/Series common dtype handling #12758

Closed
sinhrks opened this issue Mar 31, 2016 · 4 comments
Closed

API/BUG/CLN: Index/Series common dtype handling #12758

sinhrks opened this issue Mar 31, 2016 · 4 comments
Labels
Clean Dtype Conversions Unexpected or buggy dtype conversions
Milestone

Comments

@sinhrks
Copy link
Member

sinhrks commented Mar 31, 2016

Code Sample, a copy-pastable example if possible

Some inconsistencies there.

# OK: specifying int dtype with float value coerces to int (same as numpy)
pd.Series([1, 2, 3.5], dtype=int)
#0    1
#1    2
#2    3
# dtype: int64

# OK
pd.Index(np.array([1, 2, 3.5], dtype=int))
# Int64Index([1, 2, 3], dtype='int64')

# NG: If list is given, dtype is ignored
pd.Index([1, 2, 3.5], dtype=int)
# Float64Index([1.0, 2.0, 3.5], dtype='float64')

Expected Output

  • All list-like input should be handled by a consistent logic.
  • If dtype is specified, the result must be the specified dtype. Otherwise raise.
    • To do this, merge base Index creation and Series sanitizing logic to use same ndarray dtype handling.

output of pd.show_versions()

Current master.

@jreback
Copy link
Contributor

jreback commented Mar 29, 2017

cc @gfyoung

this is very much like #15187

this might even be closable now, can you have a look?

@gfyoung
Copy link
Member

gfyoung commented Mar 29, 2017

Similar, but not the same. This relates to how we coerce dtype in general (not the uint64 corner case). However, note that what @sinhrks is suggesting as the correct behavior contradicts what you were proposing in [12] of that issue you opened.

@gfyoung
Copy link
Member

gfyoung commented Mar 29, 2017

I think what might be best is to open one issue that combines all of these dtype casting issues if that works with everyone.

@gfyoung
Copy link
Member

gfyoung commented Mar 29, 2017

@jreback : Opened #15832, which includes this issue. I think we can close this one then.

@jreback jreback closed this as completed Mar 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Clean Dtype Conversions Unexpected or buggy dtype conversions
Projects
None yet
Development

No branches or pull requests

4 participants