SilentGhost added the comment:
I'm closing this bug as fixed as TypeError is being raised on Linux on 3.7.2 (I
think it was fixed for all platforms, due to work on path-like interface in
3.6). I don't think it's worth implementing this in 2.7 at this stage.
--
nosy: +SilentGhost
Martin Panter added the comment:
I always assumed that None was a unwise value to pass to the “os.path”
functions. Indeed, at the top of the documentation page it says they only
accept bytes or (text) string parameters. Although returning a consistent error
might be a sensible addition.
Serhiy Storchaka added the comment:
It's because None quacks as empty string.
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22587
___
Kevin Keating added the comment:
I agree that None is an unwise value to pass in. Of the four different abspath
implementations, though, one will treat None (or any falsey value) as an empty
string, while the other three will raise an exception unless passed an actual
str or bytes object. I
Antoine Pitrou added the comment:
+1 for raising TypeError, but I think this should only be changed in 3.5, since
we don't want to break code in a bugfix release.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
New submission from Kevin Keating:
On Windows, os.path.abspath() treats None as if it were an empty string, so
os.path.abspath(None) returns the current working directory. On Linux,
os.path.abspath(None) raises an AttributeError. With macpath, abspath(None)
raises a TypeError. I've seen
Kevin Keating added the comment:
I just realized that even the behavior of ntpath.abspath() is inconsistent
across platforms. On Windows, ntpath.abspath(None) returns the current working
directory. On other OSs, ntpath.abspath(None) raises a TypeError. There are
two different abspath
