I started writing some fixes for DataArray, but some others need discussion on whether they should be implemented as I describe. To this extent, please see issues at http://github.com/fperez/datarray/issues and comment on them, so that I'll know if I should implement these. Thanks, Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Hi Lluis, On Mon, Sep 6, 2010 at 12:17 PM, Lluís <xscript@gmx.net> wrote:
I started writing some fixes for DataArray, but some others need discussion on whether they should be implemented as I describe.
To this extent, please see issues at http://github.com/fperez/datarray/issues and comment on them, so that I'll know if I should implement these.
I'm afraid I'm completely bandwidth-saturated for the next 2-3 weeks, but at the same time I have no intention whatsoever in becoming the bottleneck on all of this. Ultimately I don't see datarray as *my* code, but rather as code we as a group will refine to make numpy better. Keith Goodman has been also helping out, but I'm wondering if it would be good if I add a few more people with commit rights to that repo, so that development can move forward? Ultimately it's the people who do the coding who matter, and right now I'm too busy on the ipython side to do anything on this front at all. Just let me know what you and the others (Keith, Skipper, Rob, etc) think and I'm more than happy to open the doors to make the process easier. Once numpy settles in its github home, I hope we'll just move this repo from my personal hosting over to the numpy organization one, but I want to do that after numpy makes the transition to give them a chance to 'settle in'. Cheers, f
Fernando Perez writes:
Just let me know what you and the others (Keith, Skipper, Rob, etc) think and I'm more than happy to open the doors to make the process easier.
Well, the pull requests I posted to your repository are for fairly trivial fixes (but some still need documentation and regression test updates). But some of the other features I posted on the issue tracker might need some previous discussion (I can recall the 'axis' vs 'axes' issue from the top of my head). Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
On Wed, Sep 8, 2010 at 5:00 AM, Lluís <xscript@gmx.net> wrote:
Well, the pull requests I posted to your repository are for fairly trivial fixes (but some still need documentation and regression test updates).
By the way Lluis, I replied to one of your requests (Keith merged the other one, thanks!) here: http://github.com/fperez/datarray/pull/23 Basically it currently breaks most tests, so we can't really go forward until it applies cleanly on trunk and actually works :) Cheers, f
Fernando Perez writes:
On Wed, Sep 8, 2010 at 5:00 AM, Lluís <xscript@gmx.net> wrote:
Well, the pull requests I posted to your repository are for fairly trivial fixes (but some still need documentation and regression test updates).
By the way Lluis, I replied to one of your requests (Keith merged the other one, thanks!) here:
How can I see which one got merged without checking one by one?
Basically it currently breaks most tests, so we can't really go forward until it applies cleanly on trunk and actually works :)
Yup, I know it brings havok to the tests, as the constructor interface is essentially different. I'll try to find some time at the beginning of next month to fix all missing bits on my pull requests. An yes, I saw you comment. On the naming issue... I thought that datarray module would be inside numpy, so the construction interface would be: numpy.datarray.array(...) User-friendly constructor with "inlined" contents. numpy.datarray.DataArray(...) Low-level contructor with uninitialized contents. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
On Wed, Oct 13, 2010 at 6:02 AM, Lluís <xscript@gmx.net> wrote:
Fernando Perez writes:
By the way Lluis, I replied to one of your requests (Keith merged the other one, thanks!) here:
How can I see which one got merged without checking one by one?
It was this one: http://github.com/fperez/datarray/commit/a66b871af0ac7d50ca7a4f4094875b58807... I added this unit test: http://github.com/fperez/datarray/commit/1015c1906f1c20de51f9f68c9ce9d605f23...
On Wed, Oct 13, 2010 at 6:02 AM, Lluís <xscript@gmx.net> wrote:
Yup, I know it brings havok to the tests, as the constructor interface is essentially different.
I'll try to find some time at the beginning of next month to fix all missing bits on my pull requests.
An yes, I saw you comment. On the naming issue... I thought that datarray module would be inside numpy, so the construction interface would be: numpy.datarray.array(...) User-friendly constructor with "inlined" contents. numpy.datarray.DataArray(...) Low-level contructor with uninitialized contents.
I see your point, but I think overriding the 'array' name is not very safe in the long run. Imagine reading a fragment of code using datarrays, you'd have to constantly look at the top for the import line, to see 'is this the 'array' from datarray or the numpy one? And if you need to use both (likely a very common scenario) you'd be aliasing one of them all the time. So let's avoid the naming collision from the beginning, rather than having everyone work around it always. Cheers, f
Fernando Perez writes:
On Wed, Oct 13, 2010 at 6:02 AM, Lluís <xscript@gmx.net> wrote:
I thought that datarray module would be inside numpy, so the construction interface would be: numpy.datarray.array(...) User-friendly constructor with "inlined" contents. numpy.datarray.DataArray(...) Low-level contructor with uninitialized contents.
I see your point, but I think overriding the 'array' name is not very safe in the long run. Imagine reading a fragment of code using datarrays, you'd have to constantly look at the top for the import line, to see 'is this the 'array' from datarray or the numpy one? And if you need to use both (likely a very common scenario) you'd be aliasing one of them all the time. So let's avoid the naming collision from the beginning, rather than having everyone work around it always.
Ah well, I don't usually import routines into my namespace, but full packages to avoid collisions and ease understanding of the source :) In fact, I looked into 'numpy.ma' to try to follow the same scheme. It does indeed have a 'numpy.ma.array', while 'numpy.ma.masked_array' seems just to be an alias for 'numpy.ma.MaskedArray'. In any case, I think you had one naming suggestion... could you type it again? Was it 'numpy.datarray.data_array'? Or perhaps something shorter? In any case, I do see your concerns. I'll fix all pending requests... when I have time. It's crazy right now, so I won't be having much time for at least two weeks. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
On Mon, Oct 18, 2010 at 7:58 AM, Lluís <xscript@gmx.net> wrote:
Ah well, I don't usually import routines into my namespace, but full packages to avoid collisions and ease understanding of the source :)
Good practice, though it's still (I think) best to avoid colliding with very common names in case someone uses the direct import approach (which is perfectly valid and idiomatic Python).
In fact, I looked into 'numpy.ma' to try to follow the same scheme. It does indeed have a 'numpy.ma.array', while 'numpy.ma.masked_array' seems just to be an alias for 'numpy.ma.MaskedArray'.
In any case, I think you had one naming suggestion... could you type it again? Was it 'numpy.datarray.data_array'? Or perhaps something shorter?
I lean towards hoping that numpy would expose at the top level the various *array() functions for the different array types: np.array() -> plain np.masked_array() np.data_array() np.record_array() That would make it easier for people to discover them, and would also encourage uniformization (when possible) of interfaces, signatures, etc. In teaching, it would also be easier to have a little chart explaining the various specializations the other types make over the basic one, and I think it would be more newbie-friendly to have this layout.
In any case, I do see your concerns. I'll fix all pending requests... when I have time. It's crazy right now, so I won't be having much time for at least two weeks.
Thanks, no worries. It's not like we're drowning in free time here :) Cheers, f
participants (4)
-
Fernando Perez -
Keith Goodman -
Lluís -
xscript＠gmx.net