### Re: [Numpy-discussion] __numpy_ufunc__

HI Stephan, Indeed, `__array_ufunc__` is None would be for classes that interact with arrays only as if they were any other numeric type, and thus have no use for ufuncs, but may need normal operations (astropy's `Unit` class is a reasonably good example). Your example also makes clear that,

### Re: [Numpy-discussion] Fortran order in recarray.

Hi Stephan, thanks for the note. The progress over last two years wasn't impressive IMO, but I hope you'll manage. As you suggest, I'll have a look at xarray too, as I see xarray.Dataset. I was sure that it doesn't work with non-homogeneous data at all, clearly I need to refresh my opinion.

### Re: [Numpy-discussion] Fortran order in recarray.

> 22 февр. 2017 г., в 20:39, josef.p...@gmail.com написал(а): > > > > On Wed, Feb 22, 2017 at 11:57 AM, Alex Rogozhnikov >> wrote: > Hi Matthew, > maybe it is not the best place to discuss problems of pandas, but to show > that

### Re: [Numpy-discussion] Fortran order in recarray.

On Wed, Feb 22, 2017 at 8:57 AM, Alex Rogozhnikov < alex.rogozhni...@yandex.ru> wrote: > Pandas may be nice, if you need a report, and you need get it done > tomorrow. Then you'll throw away the code. When we initially used pandas as > main data storage in yandex/rep, it looked like an good idea,

### Re: [Numpy-discussion] Fortran order in recarray.

On Wed, Feb 22, 2017 at 11:57 AM, Alex Rogozhnikov < alex.rogozhni...@yandex.ru> wrote: > Hi Matthew, > maybe it is not the best place to discuss problems of pandas, but to show > that I am not missing something, let's consider a simple example. > > # simplest DataFrame > x =

### Re: [Numpy-discussion] __numpy_ufunc__

On Wed, Feb 22, 2017 at 6:31 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > It seems to me entirely logical (but then it would, I suggested it > before...) that we allow opting out by setting `__array_ufunc__` to > None; in that case, binops return NotImplemented and ufuncs raise >

### Re: [Numpy-discussion] Fortran order in recarray.

Hi Matthew, maybe it is not the best place to discuss problems of pandas, but to show that I am not missing something, let's consider a simple example. # simplest DataFrame x = pandas.DataFrame(dict(a=numpy.arange(10), b=numpy.arange(10, 20))) # simplest indexing. Can you predict results

### Re: [Numpy-discussion] Numpy Development Queries

Ashwin, I don't know your background but perhaps it is similar to mine. I use numpy extensively in my day job and starting contributing to numpy a few months ago. From using numpy, I found some things that I thought should be added/improved. I researched them and the associated numpy code

### Re: [Numpy-discussion] Fortran order in recarray.

Alex, Can you please post some code showing exactly what you are trying to do and any issues you are having, particularly the "irritating problems with its row indexing and some other problems" you quote above? On Wed, Feb 22, 2017 at 10:34 AM, Robert McLeodwrote: > Just

### Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 16:30 GMT+01:00 Kiko: > > > 2017-02-22 16:23 GMT+01:00 Alex Rogozhnikov : > >> Hi Francesc, >> thanks a lot for you reply and for your impressive job on bcolz! >> >> Bcolz seems to make stress on compression, which is not of much

### Re: [Numpy-discussion] Fortran order in recarray.

Just as a note, Appveyor supports uploading modules to "public websites": https://packaging.python.org/appveyor/ The main issue I would see from this, is the PyPi has my password stored on my machine in a plain text file. I'm not sure whether there's a way to provide Appveyor with a SSH key

### Re: [Numpy-discussion] Fortran order in recarray.

2017-02-22 16:23 GMT+01:00 Alex Rogozhnikov: > Hi Francesc, > thanks a lot for you reply and for your impressive job on bcolz! > > Bcolz seems to make stress on compression, which is not of much interest > for me, but the *ctable*, and chunked operations look very

### Re: [Numpy-discussion] __numpy_ufunc__

Hi All, I'd very much like to get `__array_ufunc__` in, and am willing to do some work, but fear we need to get past the last sticking point. As I noted in Chuck's PR [1], in python 3.6 there is now an explicit language change [2], which I think is relevant: ``` It is now possible to set a

### Re: [Numpy-discussion] Fortran order in recarray.

Hi Alex, 2017-02-22 12:45 GMT+01:00 Alex Rogozhnikov: > Hi Nathaniel, > > > pandas > > > yup, the idea was to have minimal pandas.DataFrame-like storage (which I > was using for a long time), > but without irritating problems with its row indexing and some other >

### Re: [Numpy-discussion] Could we simplify backporting?

Hi Ralf, Yes, good to think about other policies. For astropy, we do the decision by labelling with the bug-fix branch (with a policy that it really should fix a bug), and inserting text in that release's bug-fix notes (we really should automate that part...). Then, backporting is done shortly

### Re: [Numpy-discussion] Fortran order in recarray.

Hi Nathaniel, > pandas yup, the idea was to have minimal pandas.DataFrame-like storage (which I was using for a long time), but without irritating problems with its row indexing and some other problems like interaction with matplotlib. > A dict of arrays? that's what I've started from

### Re: [Numpy-discussion] Could we simplify backporting?

On Wed, Feb 22, 2017 at 7:52 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Hi All, > > In gh-8594, a question came up how to mark things that should be > backported and Chuck commented [1]: > > > Our backport policy is still somewhat ad hoc, especially as I the only > one who has