test fails in ntpath.py when LocalPath has no len

[pytestbot]

Originally reported by: Jason R. Coombs (BitBucket: jaraco, GitHub: jaraco)

---

Consider this simple test:

def test_simple(tmpdir):
    import os
    os.path.join(tmpdir, 'foo')

Invoke that test on Windows in pytest 2.6.4, and you'll get a failure:

============================= test session starts ============================= platform win32 -- Python 3.4.2 -- py-1.4.26 -- pytest-2.6.4
collected 1 items

test_join.py F

================================== FAILURES =================================== _________________________________ test_simple _________________________________

tmpdir = local('C:\\Users\\jaraco\\AppData\\Local\\Temp\\pytest-19\\test_simple0')

    def test_simple(tmpdir):
        import os
>       os.path.join(tmpdir, 'foo')

test_join.py:3:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
c:\python\lib\ntpath.py:108: in join
    result_drive, result_path = splitdrive(path)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

p = local('C:\\Users\\jaraco\\AppData\\Local\\Temp\\pytest-19\\test_simple0')

    def splitdrive(p):
        """Split a pathname into drive/UNC sharepoint and relative path specifiers.
        Returns a 2-tuple (drive_or_unc, path); either part may be empty.

        If you assign
            result = splitdrive(p)
        It is always true that:
            result[0] + result[1] == p

        If the path contained a drive letter, drive_or_unc will contain everything
        up to and including the colon.  e.g. splitdrive("c:/dir") returns ("c:", "/dir")

        If the path contained a UNC path, the drive_or_unc will contain the host name
        and share up to but not including the fourth directory separator character.
        e.g. splitdrive("//host/computer/dir") returns ("//host/computer", "/dir")

        Paths cannot contain both a drive letter and a UNC path.

        """
        empty = _get_empty(p)
>       if len(p) > 1:
E       TypeError: object of type 'LocalPath' has no len()

c:\python\lib\ntpath.py:159: TypeError
========================== 1 failed in 0.07 seconds ===========================

Should LocalPath support join operations or should the tester expect to convert the LocalPath to a str before invoking join?

Probably the preferred usage is to use the .join() method on LocalPath, but that's less obvious.

---

• Bitbucket: https://bitbucket.org/pytest-dev/pytest/issue/651

[pytestbot]

Original comment by Jason R. Coombs (BitBucket: jaraco, GitHub: jaraco):

---

I've noticed other failures if I attempt to use a LocalPath, such as with an invocation of subprocess.Popen:

subprocess.Popen([tmpdir/'my_exe'])

That will fail with TypeError: argument of type 'LocalPath' is not iterable.

In general, it seems that a LocalPath is not a string, so can't be used in place of where a string path would be used.

[The-Compiler]

I think it's intentional that py.path objects are not interchangable with strings - you'll see the same with pathlib from the python 3.4 stdlib for example, except for some functions (like os.path.join) which were adjusted to take Path objects:

>>> os.stat(pathlib.Path('foo') / 'bar')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument should be string, bytes or integer, not PosixPath

So I think this can be closed if you agree, @jaraco 😄

[jaraco]

That seems reasonable, I guess. It's slightly surprising, and ugly, to have to cast a path to a str or unicode before making use of it, especially with the disparity between str and unicode across Python 2 and Python 3. I guess in many cases, people will be able to cheat by using simply str.

I guess my objection lies in the tradeoff. It seems like a pretty unfortunate tradeoff for py.path objects to be conveniently wrapped with methods but then not be usable by the most common functions with which they might be used.

But if that's the design of the authors, I'll roll with it. Thanks for the info.

And yes, please close.

[RonnyPfannschmidt]

@jaraco please keep in mind that path objects have all methods for path manipulation and file interaction, so one doesn't have to use the legacy functions of the stdlib

no making it a string is very intentional, but i guess we should document conversion a bit more

there are plans to create a pathlib based variant in future which should be more agreeable with the stdlib interaction

but thats a long term goal, nothing closeby