Add support for pathlib.Path objects to arcpy

[ScottDavis]

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!

[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.

[chrismartinEsri]

The pathlib library was included with the standard library as of 3.4.  There has been a general push towards these object-orientated paths as they provide immense improvements to the standard os library tools.  I've found most tools (i.e. all the ones I've worked with) do not support Path objects and force me to cast them to string prior to executing the tool.  I believe the tools should handle this casting implicitly so the end user can use Path objects or string representations of paths without conflict.

[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.

[KoryKramer]

This is a related idea from customers: https://community.esri.com/t5/python-ideas/add-support-for-pathlib-path-objects-to-arcpy/idi-p/93311...

[ShaunWalbridge]

I agree that working with pathlib paths is a much nicer experience than plain strings and os.path anipulations. We are considering this work, and I will link to this in our internal issue, Python #1795. We 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. I think it also begs the question of getting pathlib objects back out where available, which is another level to this.

[KoryKramer]

Good update @ShaunWalbridge Given the status update on this one, could you or @Anonymous User update the customer idea to Under Consideration?

Thank you!

[ShaunWalbridge]

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.

[ShaunWalbridge]

@KoryKramerOK posted it as under consideration on the public issue as well.