Skip to content
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.

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

[WIP] DEP: Deprecate is_pathlib_like #14093

Closed
wants to merge 4 commits into from

Conversation

hmaarrfk
Copy link
Contributor

This two liner change is part of
#14083

Before: (Master): 105±2ms
After: this branch: 102±1ms

Yes, 3ms, I know, but it adds up.

The only place I found is_pathlike_path is in core/memmap
https://github.com/numpy/numpy/blob/master/numpy/core/memmap.py#L272

@hmaarrfk hmaarrfk force-pushed the avoid_pathlib branch 2 times, most recently from bfce5ae to caf71db Compare July 24, 2019 01:19
numpy/compat/py3k.py Outdated Show resolved Hide resolved
@eric-wieser
Copy link
Member

Seems worth putting in, especially if we can fold in the cleanup from dropping 2.7 and 3.4

@hmaarrfk
Copy link
Contributor Author

dropping 2.7 and 3.4

Yeah, it is unclear how appropriate it is to do this stuff now, or later during your larger cleanup.

@seberg
Copy link
Member

seberg commented Jul 24, 2019

Do not hesitate to clean up if its is related to code you touch. Nobody started yet on a serious cleanup, but I think that does not need to stop us to do it in places where it makes life even easier maybe.

@hmaarrfk
Copy link
Contributor Author

Are we OK removing the is_pathlib_path from the compat? It seems like we can do without it.

@hmaarrfk
Copy link
Contributor Author

hmaarrfk commented Jul 24, 2019

Or should I just emit a warning.

With the lastest changes:

(owl) mark@mark-xps ~/g/n/numpy avoid_pathlib|+1…1⚑ 1
$ grep is_pathlib_path . -R
./compat/py3k.py:           'integer_types', 'is_pathlib_path', 'npy_load_module',
./compat/py3k.py:def is_pathlib_path(obj):
./compat/py3k.py:    warn("The use of is_pathlib_path is deprecated. "

@hmaarrfk hmaarrfk force-pushed the avoid_pathlib branch 3 times, most recently from d281983 to 35c5026 Compare July 24, 2019 01:52
@hmaarrfk hmaarrfk changed the title MNT: Don't import pathlib for python >3.6 MNT: Don't import pathlib for python >=3.6 Jul 24, 2019
numpy/compat/py3k.py Outdated Show resolved Hide resolved
numpy/compat/py3k.py Outdated Show resolved Hide resolved
@hmaarrfk hmaarrfk force-pushed the avoid_pathlib branch 2 times, most recently from b9e9ab0 to 6e1ea7d Compare July 24, 2019 03:15
@charris charris changed the title MNT: Don't import pathlib for python >=3.6 MAINT: Don't import pathlib for python >=3.6 Jul 25, 2019
above, users are encouraged to use ``isinstance(obj, os.PathLike)``. For code
supporting Python 3.5, the snippet ``isinstance(obj,
numpy.compat.os_PathLike)`` can be used.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should now go into a file in doc/release/upcoming_changes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

@eric-wieser
Copy link
Member

eric-wieser commented Aug 25, 2019

Just two more requests here:

  • Please add a test to test_deprecations.py
  • Can you put the deprecation change, test, and release note in its own commit starting DEP instead of MNT? (or even better, its own PR - hiding deprecations in maintenance commits makes it easy for maintainers to not notice them)

@hmaarrfk
Copy link
Contributor Author

So you would like me to make the PR that removes the deprecations in 1.20 today?

@rgommers
Copy link
Member

@hmaarrfk no, please no PRs that we can't merge for the next year.

@hmaarrfk
Copy link
Contributor Author

Sorry it all makes sense now, you wanted everything contained in a single commit instead of splitting it up into 3.

@hmaarrfk hmaarrfk changed the title MAINT: Don't import pathlib for python >=3.6 DEP: Deprecate is_pathlib_like Aug 25, 2019
from pathlib import Path
# 2019-08-25, 1.18
warn("The use of is_pathlib_path is deprecated. "
"For Python 3.5, you should prefer using "
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In light of the new NEP, should this warning be revised? Should this whole PR be revised to just make is_pathlib_like the same as os_PathLike???

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

xref gh-14673

from pathlib import Path, PurePath
except ImportError:
Path = PurePath = None
from warnings import warn
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change breaks code that does

from numpy.compat import Path
if Path is None:
   ...

Do we care? This probably at least warrants a release note

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes we probably care. :(

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the only way to cleanup the namespace is to wait until python 3.7 is the only one you support, and then go all out with the deprecations using __getattr__. There is little sense giving warnings to users of python 3.7 + 3.8 only.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sense giving warnings to users of python 3.7 + 3.8 only.

Sure there is, it means that packages using CI across multiple versions can fix their code sooner :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, let's leave the slow import alone for now - we can still deprecate the function below.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If nothing else, a change to this file to remove the try / except now that pathlib is always available would be appreciated

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are also ALOT of places that have if/else statements like sys.version > (3, 6), want to remove all of those if else clauses?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets leave it at pathlib for this PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you remove all the >= (3, 5) (preferably just from this file), then we can merge this in time for 1.18 (which supports 3.5)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoa, didn't know you all were still going to support 3.5 ;) Not many changes in this case for now. Many if staements can be removed. I'll leave it till then.

@@ -12,7 +12,7 @@
import pytest

import numpy as np
from numpy.compat import Path
from pathlib import Path
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eric-wieser Do you want to keep changes like this? That modernize the test suite so as not to use our own compatibility layer?

I feel like if we remove these, we are no longer testing the compatibility layer, and it is as good as removing it (since bug will creep in that we won't be monitoring).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we want to test the compatibility layer, we should have a standalone test for that. I don't think the lack of that test should motivate us not to clean up our other tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but as it stands, there are no other tests dedicated for the compatibility layer.

I would prefer to wait unit you drop 3.5 support. then the only test becomes

assert os_PathLike == os.PathLike
[...]

@hmaarrfk hmaarrfk force-pushed the avoid_pathlib branch 2 times, most recently from 64b52e3 to a18b5ea Compare November 29, 2019 15:54
@@ -269,7 +269,7 @@ def __new__(subtype, filename, dtype=uint8, mode='r+', offset=0,
self.offset = offset
self.mode = mode

if is_pathlib_path(filename):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change isn't safe. because it uses resolve below instead of os_fspath - pathlike objects aren't required to implement resolve

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So os_PatgLike is a subset of pathlike?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pathlib.Path is a subset of os.PathLike , if that was what you were asking

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah i see

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In [1]: from pathlib import Path                                                

In [2]: import os.path                                                          

In [3]: os.path                                                                 
Out[3]: <module 'posixpath' from '/home/mark/miniconda3/envs/mcam_dev/lib/python3.7/posixpath.py'>

In [4]: os.path.abspath(Path())                                                 
Out[4]: '/home/mark/git/numpy'

should be ok I think

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently only in python 3.8 + https://bugs.python.org/issue9949

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're looking for filename = os_fspath(filename) in this branch - but that becomes a feature, so probably belongs in its own PR

@hmaarrfk hmaarrfk changed the title DEP: Deprecate is_pathlib_like [WIP] DEP: Deprecate is_pathlib_like Nov 29, 2019
@hmaarrfk
Copy link
Contributor Author

This isn't the "easy removal" I had anticipated. Due to many intricacies in the tests, I think I will have to revise this change from scratch. and maybe keep it to a "cleanup" instead of a "deprecation"

@@ -3,7 +3,7 @@
import numpy as np
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you backout the changes in this file and save them for a separate, ENH, PR? This is going beyond internal cleanup to (good!) behavior changes.

@eric-wieser
Copy link
Member

and maybe keep it to a "cleanup" instead of a "deprecation"

That is what I was trying to get at in #14093 (comment) - combining deprecation with cleanup is usually a bad idea, because one requires a lot of thinking to approve, but the latter is often very fast.

@mattip
Copy link
Member

mattip commented Jul 13, 2020

I am going to close. One of these changes was already merged elsewhere, and others should be split out into another PR. Please feel free to reopen and update.

@mattip mattip closed this Jul 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants