[Numpy-discussion] [SciPy-Dev] NumPy/SciPy participation in GSoC 2013

[Nathaniel Smith]

On Tue, Apr 2, 2013 at 8:10 PM, Todd <toddrjen at gmail.com> wrote:
>
> On Tue, Apr 2, 2013 at 8:12 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>>
>>
>>
>>
>> On Mon, Apr 1, 2013 at 2:27 PM, Todd <toddrjen at gmail.com> wrote:
>>>
>>>
>>> There were a number of other ideas in this thread:
>>>
>>> http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065699.html
>>
>>
>> Thanks Todd. Your idea 5 is pretty much what Nathaniel just detailed out,
>> it's on the ideas page now. That should enable idea 1 as well. The other
>> idea that got some positive feedback was 3:
>> http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065710.html. If
>> you or someone else could make that a little more concrete, we can put that
>> up.
>>
>
> For 3:
>
> With structured arrays, you can access them by name (key) in a manner
> identical to dictionaries:
>
> y = x['f']
>
> It also has a method for accessing the list of names (keys):
>
> x.dtype.names
>
> This should be maintained for backwards-compatibility, but these methods
> should also be added:
>
> x.keys -- returns a list of field names
> x.values -- returns a list of views into the array, one for each structure
> x.items -- returns a list of tuple containing name/structure pairs (the
> structures being a views)
> x.iterkeys/itervalues/iteritems -- returns an iterable over the
> corresponding objects (should not be available in python 3)
> x.viewkeys/viewvalues/viewitems -- the same as the corresponding item, since
> they always return views (should not be available in python 3)
> x.has_key -- tests if a field name is present (should not be available in
> python 3, should use "key in x.keys()")
> x.get -- get a field by name, returning a default array (an empty array by
> default) if not present
> x.update -- copy values into the matching key from another structured array,
> a dict, or list of key/value tuples.  Unlike dicts this will only work for
> keys that are already present.
>
> Documentation should probably be updated to have these as the default ways
> of interacting with structured arrays, with the old methods deprecated.
> "Names" should also probably be renamed "keys" for compatibility with dicts.

I'm concerned that this will be 1 week of coding + 2 months of arguing
over whether it's actually a good idea to add all these methods to
every ndarray, whether it makes sense to have "views" for ndarrays,
what should be done with "in", can/should we really rename "names",
etc. Maybe I'm just pessimistic, but it isn't as much a slam-dunk
obviously-the-right-thing improvement as some things. (Also I have no
idea what the other comment about compact dicts that Ralf referred to
above meant.) Handling such debates is a super-important part of OSS
coding, but probably the worst thing to put on the critical path of a
GSoC project.

(Actually I guess I may be guilty of this myself, if anyone is worried
about that dtype proposal speak up now... I think it can be done
without serious compatibility breaks.)

-n