Add support for pathlib.Path objects to arcpy

1219
7
04-09-2020 09:20 AM
ScottDavis
Occasional Contributor

pathlib seems to be the preferred method for working with system paths in Python 3. We've started using it in place of `os.path` in our office recently and really like it. However, we've run into problems with using it with arcpy. For example:

workspace = pathlib.Path('C:\some path') \ 'anotherfolder' \ 'connection.sde'
with arcpy.EnvManager(workspace=workspace):
    pass‍‍‍‍‍‍

Throws this error: "RuntimeError: Object: Error in accessing environment <workspace>"

To work around this, we end up wrapping all of our Path object with str(). For example:

workspace = str(pathlib.Path('C:\some path') \ 'anotherfolder' \ 'connection.sde')
with arcpy.EnvManager(workspace=workspace):
    pass‍‍‍‍‍‍‍‍‍

It would be great if arcpy (Pro version) handled these Path objects natively!

Tags (2)
7 Comments
GISTeam4

This would be much appreciated. Going into Python 3 we want to make good use of the new stuff like Pathlib and f-strings.

BlakeTerhune

When using a path created from pathlib, arcpy.da.SearchCursor() returns

RuntimeError: 'in_table' is not a table or a featureclass

If the path is formatted with str() it works fine. Hopefully there's a way the cursor, and anything else that's relevant, can accept native objects from pathlib. Please see this relevant post Using pathlib with SearchCursor

JoeBorgione

@BlakeTerhune - having read you other post earlier, what is the advantage of pathlib?

BlakeTerhune

@JoeBorgione I found a nice summary here. Also see the official documentation that compares the path related tools from os module.

ShaunWalbridge
Status changed to: Under Consideration

Working with pathlib paths is a much nicer experience than plain strings and os.path anipulations. We are considering this work, but do estimate this to be a larger change, because of the number of different places that we currently explicitly pass only strings and expect the objects to be strings without further inspection.

BlakeTerhune

Thank you for the consideration @ShaunWalbridge! :smiling_face_with_smiling_eyes:

EthanSchaefer

It seems to me that one (partial?) solution would be to wrap each function/method so that any passed object with a __fspath__ method is converted to the result of calling that method. This is essentially the same logic behind os.fspath(), which returns arbitrary strings unchanged, even if they couldn't possibly represent a path. Of course, it sequences of paths must also be covered, that could be accommodated, too. But if there are more complicated scenarios that I haven't anticipated, they may be harder to support.

Incidentally, the basic approach I outlined is how I deal with this problem (at an abstract level) when generating scripts on the fly and passing them via propy.bat.