On Fri, Mar 21, 2014 at 9:27 PM, wrote:
>
>
>
> On Fri, Mar 21, 2014 at 9:01 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>>
>> On Fri, Mar 21, 2014 at 6:49 PM, wrote:
>>
>>>
>>>
>>>
>>> On Fri, Mar 21, 2014 at 8:46 PM, Charles R Harris <
>>> charlesr.har...@gmail.com> wrot
On Fri, Mar 21, 2014 at 9:01 PM, Charles R Harris wrote:
>
>
>
> On Fri, Mar 21, 2014 at 6:49 PM, wrote:
>
>>
>>
>>
>> On Fri, Mar 21, 2014 at 8:46 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Fri, Mar 21, 2014 at 6:26 PM, Alan G Isaac wrote:
>>>
The doc
On Fri, Mar 21, 2014 at 6:49 PM, wrote:
>
>
>
> On Fri, Mar 21, 2014 at 8:46 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>>
>> On Fri, Mar 21, 2014 at 6:26 PM, Alan G Isaac wrote:
>>
>>> The documentation of numpy.unique
>>> http://docs.scipy.org/doc/numpy/reference/generat
On Fri, Mar 21, 2014 at 8:46 PM, Charles R Harris wrote:
>
>
>
> On Fri, Mar 21, 2014 at 6:26 PM, Alan G Isaac wrote:
>
>> The documentation of numpy.unique
>> http://docs.scipy.org/doc/numpy/reference/generated/numpy.unique.html
>> does not seem to promise that return_index=True will always inde
On Fri, Mar 21, 2014 at 6:26 PM, Alan G Isaac wrote:
> The documentation of numpy.unique
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.unique.html
> does not seem to promise that return_index=True will always index the
> *first* occurrence of each unique item, which I believe is the
On Fri, Mar 21, 2014 at 8:26 PM, Alan G Isaac wrote:
> The documentation of numpy.unique
> http://docs.scipy.org/doc/numpy/reference/generated/numpy.unique.html
> does not seem to promise that return_index=True will always index the
> *first* occurrence of each unique item, which I believe is the
The documentation of numpy.unique
http://docs.scipy.org/doc/numpy/reference/generated/numpy.unique.html
does not seem to promise that return_index=True will always index the
*first* occurrence of each unique item, which I believe is the current behavior.
A promise would be nice.
Is it intended?
A
On Thu, Mar 20, 2014 at 11:27 PM, Chris Barker wrote:
> * I think there are more or less three options:
>1) a) don't have any timezone handling at all -- all datetime64s are UTC.
> Always
> b) don't have any timezone handling at all -- all datetime64s are
> naive
> (th
On Fri, Mar 21, 2014 at 5:31 PM, Chris Barker wrote:
> But this brings up a good point -- having time zone handling fully
> compatible ith datetime.datetime would have its advantages.
I don't know if everyone is aware of this, but Python stdlib has support
for fixed-offset timezones since versi
On Thu, Mar 20, 2014 at 6:32 PM, Alexander Belopolsky wrote:
> The difference comes down to I/O.
>
> It is more than I/O. It is also about interoperability with Python's
> datetime module.
>
Sorry -- I was using I/O to mean "converting to/from datetime64 and other
types" So that included dateti
On Thu, Mar 20, 2014 at 5:53 PM, Alexander Belopolsky wrote:
> I recall that it was at some point suggested that epoch be part of dtype.
> I was not able to find the reasons for a rejection,
>
I don't think it was rejected, it just wasn't adopted by anyone to write a
NEP and write the code...
I
On Thu, Mar 20, 2014 at 4:55 PM, Sankarshan Mudkavi
wrote:
> Yes 2) is indeed what I was suggesting. My apologies for being unclear, I
> was unsure of how much detail and technical information I should include in
> the proposal.
>
well, you need to put enough in that it's clear what it means. I
12 matches
Mail list logo
