8000 Deprecate the aliased constants in the top-level namespaces · Issue #13705 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Deprecate the aliased constants in the top-level namespaces #13705

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
Closed
eric-wieser opened this issue Jun 4, 2019 · 5 comments
Closed

Deprecate the aliased constants in the top-level namespaces #13705

eric-wieser opened this issue Jun 4, 2019 · 5 comments
Labels
04 - Documentation 07 - Deprecation
Milestone
2.0.0 release

Comments

@eric-wieser
Copy link
Member
eric-wieser commented Jun 4, 2019 •
edited
Loading

Continuing from #13696.

In the spirit of

There should be one-- and preferably only one --obvious way to do it.

I think we should deprecate (either via a warning, or via using the word "deprecated" in the docstring):

  • np.Inf, np.infty, np.Infinity, np.PINF - these are worse ways to spell np.inf, and the doc already recommends the latter
  • np.NINF - this is a worse way to spell -np.inf
  • np.NAN, np.NaN - these are worse ways to spell np.nan, and the doc already recommends the latter
  • np.NZERO, np.PZERO - these are weirdly capitalized compared to the other recommended constants, and are shorter as 0.0 and -0.0
@eric-wieser eric-wieser mentioned this issue Jun 4, 2019
Merged
@rgommers
Copy link
Member
rgommers commented Jun 4, 2019

I agree with the sentiment. I don't think they're used much, they are indeed worse, and clutter up the namespace.

The maintenance overhead of these is really low, so I would suggest to perhaps remove them only is we do a 2.0 release, but happy to see them deprecated (docs or warning, no preference) now.

@mattip
Copy link
Member
mattip commented Jun 7, 2019

Note this would require modifying __getattr__ for the module, much as #13525 did, but would check for the deprecated forms as the attr argument to the function, and so would only be available for python 3.7 and up.

@eric-wieser
Copy link
Member Author
eric-wieser commented Jun 7, 2019 •
edited
Loading

#6103 is the poster-child for __getattr__, this is some minor cleanup we could add on once the infrastructure in place. I might take a look at this set of issues once py 3.5 reaches EOL and I'm forced to upgrade my local installation

@rgommers rgommers added this to the 1.25.0 release milestone Mar 2, 2023
@charris charris modified the milestones: 1.25.0 release, 2.0.0 release May 24, 2023
@lucascolley
Copy link
Contributor
lucascolley commented Nov 12, 2023 •
edited
Loading

Can this be closed now following gh-24306?

@rgommers
Copy link
Member

Indeed, thanks @lucascolley

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
04 - Documentation 07 - Deprecation
Projects
None yet
Milestone
2.0.0 release
Development

No branches or pull requests
6 participants
@seberg @charris @rgommers @eric-wieser @mattip @lucascolley
0