Int64Index and Float64Index (and... ?) do not propagate name of passed index

[toobaz]

    In [8]: i = Index(range(3),name='foo')

    In [9]: Index(i)
    Out[9]: Int64Index([0, 1, 2], dtype='int64', name=u'foo')

    In [10]: pd.Int64Index(i)
    Out[10]: Int64Index([0, 1, 2], dtype='int64')

Float64Index as well
ideally move the tests to Base to test all index types.
See #12288.

[toobaz]

Related question: are the following behaviours, currently in master, desired?

• explicitly given datatype is respected in Int64Index but not in Float64Index:

  In [3]: Int64Index(np.arange(3, dtype=np.int32), dtype=np.int32).dtype
  Out[3]: dtype('int32')
  
  In [4]: Float64Index(np.arange(3, dtype=np.float32), dtype=np.float32).dtype
  Out[4]: dtype('float64')
  

• data dtype is not respected by default (even when it could be):

  In [5]: Int64Index(np.arange(3, dtype=np.int32)).dtype
  Out[5]: dtype('int64')
  

[jreback]

@toobaz no those are as expected, these by default will coerce to float64/int64 always (or raise an error if its impossible). we technically allow coercing to a smaller dtype size (e.g. 32bit).

I dont think its ever useful to have a Int64Index with a dtype of int32 (and break some things), IIRC I added it a while back for compat reasons. You can take this out and see what if anything breaks, and we can simply disallow (and cast as needed).

[toobaz]

Not sure I understood correctly: OK for coercing to 64 bits both floats and ints by default. But what about a different, explicit, coercion (i.e. dtype=np.float32)? I understand you're saying that supporting this may make sense for floats but not for ints, right? (the current behaviour is the opposite)

[jreback]

I am saying it exists for both now, but doesn't make sense for either. IIRC I added this for ints, but don't really remember why it was needed. Ideally we should just drop this support as its uncessary and confusing, coercing things like np.float32 -> float64 and similarly for ints.

[toobaz]

OK, so the dtype argument would become useless (at least for those two index types), right? Should it be deprecated? Or do we prefer to leave it for compatibility?

[jreback]

its for compatibility and assertions (IOW if you pass something and it cannot be coerced then you raise, this already happens now)

[toobaz]

So for instance in Int64Index with dtype=np.int32, I should check I can cast data to np.int32, just for the sake of asserting... and then store as np.int64 anyway?! Seems a bit awkward.

[jreback]

no I would simply cast to int64. I suspect some things might break currently if you change this. IIRC might be a platform issue, I don't remember.