What would be the use case for a duck-array to implement __array__ and
return a NumPy array? Unless I'm missing something, this seems
redundant and one should just use array/asarray functions then. This
would also prevent error-handling, what if the developer intentionally
wants a NumPy-like array
I just noticed that there is no obvious way to convert a timedelta64 to
seconds (or some other easy unit) as a number.
The stdlib datetime.datetime has a .total_seconds() method for doing that.
I think it's a handy thing to have.
Looking at StackOverflow (and others), I see people suggesting
Here are my thoughts on textual capitalization (at first, I thought you
wanted to raise money!):
We all agree that in code, it is "numpy". If you don't use that, it
throws an error. If, in text, we keep "numpy" with a forced lower-case
letter at the start, it is just one more oddball to
Trivial note:
On the subject of naming things (spelling things??) -- should it be:
numpy
or
Numpy
or
NumPy
?
All three are in the draft NEP 30 ( mostly "NumPy", I noticed this when
reading/copy editing the NEP) . Is there an "official" capitalization?
My preference, would be to use "numpy",
My answer to that: "NumPy". Reference: logo at the top of
https://numpy.org/neps/index.html .
In NEP-30 [1], I've used "NumPy" everywhere, except for references to
code, repos, etc., where "numpy" is used. I see there's one occurrence
of "Numpy", which was definitely a typo and I had not noticed
Thanks Joe, looks like everyone agrees:
In text, NumPy it is.
-CHB
On Mon, Sep 16, 2019 at 2:41 PM Joe Harrington wrote:
> Here are my thoughts on textual capitalization (at first, I thought you
> wanted to raise money!):
>
> We all agree that in code, it is "numpy". If you don't use that,
On Mon, Sep 16, 2019 at 1:46 PM Peter Andreas Entschev
wrote:
> What would be the use case for a duck-array to implement __array__ and
> return a NumPy array?
some users need a genuine, actual numpy array (for passing to Cyton code,
for example).
if __array__ is not implemented, how can they
On Mon, Sep 16, 2019 at 1:45 PM Peter Andreas Entschev
wrote:
> What would be the use case for a duck-array to implement __array__ and
> return a NumPy array? Unless I'm missing something, this seems
> redundant and one should just use array/asarray functions then. This
> would also prevent
got it, thanks.
I've fixed that typo in a PR I"m working on , too.
-CHB
On Mon, Sep 16, 2019 at 2:41 PM Ralf Gommers wrote:
>
>
> On Mon, Sep 16, 2019 at 1:42 PM Peter Andreas Entschev
> wrote:
>
>> My answer to that: "NumPy". Reference: logo at the top of
>>
OK -- I *finally* got it:
when you pass an arbitrary object into np.asarray(), it will create an
array object scalar with the object in it.
So yes, I can see that you may want to raise a TypeError instead, so that
users don't get an object array scalar when they wre expecting to get an
Joe Harrington writes:
> It's not an acronym, so that leaves the options of "Numpy" and
> "NumPy". It would be great, easy to remember, consistent for others,
> etc., if NumPy and SciPy were capitalized the same way and were
> pronounced the same (I still occasionally hear "numpee"). So, I
On Mon, Sep 16, 2019 at 2:27 PM Stephan Hoyer wrote:
> On Mon, Sep 16, 2019 at 1:45 PM Peter Andreas Entschev
> wrote:
>
>> What would be the use case for a duck-array to implement __array__ and
>> return a NumPy array?
>
>
> Dask arrays are a good example. They will want to implement
Here's a PR with a different dicsussion of __array__:
https://github.com/numpy/numpy/pull/14529
-CHB
On Mon, Sep 16, 2019 at 3:23 PM Chris Barker wrote:
> OK -- I *finally* got it:
>
> when you pass an arbitrary object into np.asarray(), it will create an
> array object scalar with the
Hi all,
I like the idea of having a new repo containing meeting minutes and docs.
Regards,
ZJ
On Sun, Sep 15, 2019 at 5:26 PM Ralf Gommers wrote:
> Hi all,
>
> We have had community calls for quite a while, the minutes of which are
> kept in https://github.com/BIDS-numpy/docs. That's quite
14 matches
Mail list logo
