Re: [Numpy-discussion] A proposal for dtype/dtypedescr in numpy objects

[Sebastian H. <ha...@ms...>]

Hi,
Following up: There was never any response to Francesc proposal !
I thought it sounded pretty good - as he argued: Still a good (late but 
acceptable) time to clean things up ! 
(I like just the fact that it removes the "ugly" doubling of having two: 
arr.dtype and arr.dtypecode )
Is this still on the table !?

- Sebastian Haase

 
On Thursday 05 January 2006 13:40, Francesc Altet wrote:
> Hi,
>
> In my struggle for getting consistent behaviours with data types, I've
> ended with a new proposal for treating them. The basic thing is that I
> suggest to deprecate .dtype as being a first-class attribute and
> replace it instead by the descriptor type container, which I find
> quite more useful for end users. The current .dtype type will be still
> accessible (mainly for developers) but buried in .dtype.type.
>
> Briefly stated:
>
> current             proposed
> =======             ========
> .dtypedescr     --> moved into .dtype
> .dtype          --> moved into .dtype.type
> .dtype.dtypestr --> moved into .dtype.str
>                     new .dtype.name
>
> What is achieved with that? Well, not much, except easy of use and
>
> type comparison correctness. For example, with the next setup:
> >>> import numpy
> >>> a=numpy.arange(10,dtype='i')
> >>> b=numpy.arange(10,dtype='l')
>
> we have currently:
> >>> a.dtype
>
> <type 'int32_arrtype'>
>
> >>> a.dtypedescr
>
> dtypedescr('<i4')
>
> >>> a.dtypedescr.dtypestr
>
> '<i4'
>
> >>> a.dtype.__name__[:-8]
>
> 'int32'
>
> >>> a.dtype == b.dtype
>
> False
>
> With the new proposal, we would have:
> >>> a.dtype.type
>
> <type 'int32_arrtype'>
>
> >>> a.dtype
>
> dtype('<i4')
>
> >>> a.dtype.str
>
> '<i4'
>
> >>> a.dtype.name
>
> 'int32'
>
> >>> a.dtype == b.dtype
>
> True
>
> The advantages of the new proposal are:
>
> - No more .dtype and .dtypedescr lying together, just current
>   .dtypedescr renamed to .dtype. I think that current .dtype does not
>   provide more useful information than current .dtypedesc, and giving
>   it a shorter name than .dtypedescr seems to indicate that it is more
>   useful to users (and in my opinion, it isn't).
>
> - Current .dtype is still accessible, but specifying and extra name in
>   path: .dtype.type (can be changed into .dtype.type_ or
>   whatever). This should be useful mainly for developers.
>
> - Added a useful dtype(descr).name so that one can quickly access to
>   the type name.
>
> - Comparison between data types works as it should now (without having
>   to create a metaclass for PyType_Type).
>
> Drawbacks:
>
> - Backward incompatible change. However, provided the advantages are
>   desirable, I think it is better changing now than later.
>
> - I don't specially like the string representation for the new .dtype
>   class. For example, I'd find dtype('Int32') much better than
>   dtype('<i4'). However, this would represent more changes in the
>   code, but they can be made later on (much less disruptive than the
>   proposed change).
>
> - Some other issues that I'm not aware of.
>
>
> I'm attaching the patch for latest SVN. Once applied (please, pay
> attention to the "XXX" signs in patched code), it passes all tests.
> However, it may remain some gotchas (specially those cases that are
> not checked in current tests). In case you are considering this change
> to check in, please, tell me and I will revise much more carefully the
> patch. If don't, never mind, it has been a good learning experience
> anyway.
>
> Uh, sorry for proposing this sort of things in the hours previous to a
> public release of numpy.