classification
Title: The results from os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path strings.
Type: enhancement Stage:
Components: Documentation, Library (Lib) Versions:
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: brett.cannon, docs@python, godaygo, pitrou, serhiy.storchaka
Priority: normal Keywords:

Created on 2019-07-26 07:23 by godaygo, last changed 2019-07-29 18:50 by brett.cannon.

Messages (8)
msg348475 - (view) Author: Kirill Balunov (godaygo) Date: 2019-07-26 07:23
In the documentation it is said that os.path.isdir(...) an Path(...).is_dir()are equivalent substitutes.
https://docs.python.org/3/library/pathlib.html#correspondence-to-tools-in-the-os-module

But they give different result for empty path strings:
>>> import os
>>> from pathlib import Path
>>> dummy = "" 
>>> os.path.isdir(dummy)
 False

Obviously it's not an equivalence, so either this should be noted in the documentation or corrected in the code.
msg348477 - (view) Author: Kirill Balunov (godaygo) Date: 2019-07-26 07:27
Forgot to write the result for Path variant:

>>> Path(dummy).is_dir()
 True
msg348478 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2019-07-26 07:34
It is because Path() == Path('') == Path('.').
msg348482 - (view) Author: Kirill Balunov (godaygo) Date: 2019-07-26 08:07
I understand the reasons, I only say that it does not correspond to my perception of their equivalence, because:

os.path.isdir('') != os.path.isdir('.')

while:

Path('').is_dir() == Path('.').is_dir()

and I can confirm that some libraries rely on os.path.isdir('') -> False behavior.
msg348495 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2019-07-26 15:47
I think you're reading "equivalence" too strictly here to mean "exactly the same semantics". In this instance it means "for similar functionality, the equivalent method is ..." (admittedly this might be a quirk of the use of the word "equivalent" in North American English).

But I can see why you would interpret it the way you do. Please feel free to propose a PR to clarify the phrasing.
msg348497 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2019-07-26 15:53
If "equivalent" is deceiving, perhaps replace it with "similary" or "roughly equivalent".  Feel free to post a PR with your preferred wording.
msg348528 - (view) Author: Kirill Balunov (godaygo) Date: 2019-07-26 21:24
I am reading "equivalence" too strictly (like "as a substitute"), because this is part of the documentation :) and I agree that in ordinary speech I would use it rather in the sense of “similar”.

In order to make sure, that everyone agrees only on that this requires only a documentation change? Because as for me, I think that it will better for `os.path.isdir` to raise `ValueError` or `DeprecationWarning` - `False` on empty string is not well defined behavior. But I'm fine to be alone with the last one.
msg348679 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2019-07-29 18:50
Changing the semantics of os.path.isdir() for something like this isn't worth breaking code; basically it's now a quirk of the function.
History
Date User Action Args
2019-07-29 18:50:44brett.cannonsetmessages: + msg348679
2019-07-26 21:24:58godaygosetmessages: + msg348528
2019-07-26 15:53:34pitrousetmessages: + msg348497
2019-07-26 15:47:18brett.cannonsettype: behavior -> enhancement

messages: + msg348495
nosy: + brett.cannon
2019-07-26 08:10:04xtreaksetnosy: + pitrou
2019-07-26 08:07:52godaygosetmessages: + msg348482
2019-07-26 07:34:09serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg348478
2019-07-26 07:27:13godaygosetmessages: + msg348477
2019-07-26 07:23:57godaygocreate