8000 object array construction should require explicitly specifying dtype=object · Issue #5353 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

object array construction should require explicitly specifying dtype=object #5353

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
argriffing opened this issue Dec 7, 2014 · 12 comments
Open

object array construction should require explicitly specifying dtype=object #5353

argriffing opened this issue Dec 7, 2014 · 12 comments
Labels
62 - Python API Changes or additions to the Python API. Mailing list should usually be notified.

Comments

@argriffing
Copy link
Contributor

This possibility was raised by #5303 (comment) so I'm moving this topic to its own github issue. Problems like scipy/scipy#4239 among others could be softened by making this change although it could bring backwards compatibility issues.
@njsmith njsmith mentioned this issue Dec 26, 2014
Closed
@argriffing
Copy link
Contributor Author

Also #2091 (comment).

@njsmith njsmith mentioned this issue May 25, 2015
Closed
@mhvk
Copy link
Contributor
mhvk commented May 25, 2015

An intermediate solution, which I suggested in #5844, is an explicit opt-out mechanism, perhaps using __array__ = None. It has the advantage of being backwards compatible, and should have the result that ndarray binops return NotImplemented.

@mhvk mhvk mentioned this issue Jun 10, 2015
Open
@mhvk mhvk mentioned this issue Jul 13, 2015
Open
@argriffing
Copy link
Contributor Author

+1's from notes linked from a mailing list post:

object array coercion : everyone here agrees that actually making these things (= all the times asarray returns an object array when the input is not an object array and when dtype=object was not given explicitly) an error would be a good idea

@ahaldane
Copy link
Member

A while ago I wrote up some "documentation" of how object arrays might work ideally, which includes various special cases and this explicit dtype=object change. If it's of any interest to anyone I put it up here.

@mhvk
Copy link
Contributor
mhvk commented Jul 18, 2015

@ahaldane - thanks, at least for me that was very useful!

@njsmith
Copy link
Member
njsmith commented Jul 18, 2015

@ahaldane: any interest into evolving that into a NEP? (Like a PEP but for
numpy -- would need to be a bit clearer about what was new changes versus
current behavior and what kind of strategy would be used in getting from
here to there, then go to the mailing list for discussion. But that would
be the route to making it closer to reality :-))
On Jul 18, 2015 10:40 AM, "ahaldane" notifications@github.com wrote:

A while ago I wrote up some "documentation" of how object arrays might
work ideally, which includes various special cases and this explicit
dtype=object change. If it's of any interest to anyone I put it up here
https://gist.github.com/ahaldane/c3f9bcf1f62d898be7c7.

—
Reply to this email directly or view it on GitHub
#5353 (comment).

@ahaldane
Copy link
Member

@njsmith yeah that might be a good idea. I'll collect my thoughts for a bit and then I'll see if I can rework it into that format.

@argriffing argriffing mentioned this issue Oct 30, 2015
Closed
@charris
Copy link
Member
charris commented Aug 7, 2016 •
edited
Loading

We should probably get started on this. A deprecation in array creation would be a good place to start. We might have problems with array subclasses that override __new__.

@charris
Copy link
Member
charris commented Aug 7, 2016

PyArray_GetArrayParamsFromObject might be the place to start, but might be too low level. It isn't called from many places. We should also decide how this interacts with ufuncs, especially with the proposed __numpy_ufunc__. Might be worth adding a temporary __not_an_array__ or some such flag that would serve temporarily to disable automatic array conversion until it is made an error.

@ahaldane
Copy link
Member
ahaldane commented Sep 4, 2016

I'd be happy to try some work on this sometime soon. I'm travelling for a week, but I'll take a look afterwards.

@ahaldane
Copy link
Member

Followup:

I tried implementing the new behavior (and not just the depracation) to avoid automatic object coercion by a simple modification PyArray_GetArrayParamsFromObjectas you suggested.

It looks like a good solution! Only 9 tests fail, all of which are explicitly checking cases like variable-length lists.

Perhaps the solution is as simple as that. I haven't thought about __new__ or ufunc issues yet, although those should already have some test coverage. Ping me when you want to speed up implementation.

@ahaldane ahaldane mentioned this issue Feb 17, 2017
Closed
@shoyer shoyer mentioned this issue Feb 23, 2017
Merged
@shoyer shoyer mentioned this issue May 8, 2017
Closed
@ahaldane ahaldane mentioned this issue Dec 1, 2017
Open
@ahaldane ahaldane mentioned this issue Dec 2, 2017
Closed
@ahaldane ahaldane mentioned this issue Feb 19, 2018
Closed
@jsclose jsclose mentioned this issue Apr 2, 2018
Closed
@mhvk mhvk mentioned this issue Jul 18, 2018
Closed
@charris
Copy link
Member
charris commented Nov 17, 2018

Another topic for potential BIDS discussion. @stefanv Ping.

@TomAugspurger TomAugspurger mentioned this issue Dec 28, 2018
Merged
3 tasks
@ahaldane ahaldane mentioned this issue Mar 23, 2019
Open
@shoyer shoyer added the 62 - Python API Changes or additions to the Python API. Mailing list should usually be notified. label May 10, 2019
@mhvk mhvk mentioned this issue Jul 23, 2019
Closed
@mhvk mhvk mentioned this issue Aug 25, 2019
Merged
@taldcroft taldcroft mentioned this issue Sep 14, 2019
Open
@seberg seberg mentioned this issue May 25, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
62 - Python API Changes or additions to the Python API. Mailing list should usually be notified.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@charris @argriffing @njsmith @shoyer @mhvk @ahaldane
0