Comments (15)
I don't feel strongly about this, but for me the garbage-in-garbage-out principal applies to isabs()
, splitroot()
and normpath()
equally, and allows the C and Python implementations to produce different values for the same invalid input. If this freedom allows us to add (or retain) a faster and/or more idiomatic implementation then we should use it.
from cpython.
/:/
is a totally unusable path right? Not convinced this is worth fixing (yet).
from cpython.
Yeah, you're right. But, for this exact reason /:/foo
would be not an absolute path.
I've updated the bug report reflecting this.
from cpython.
/:/
is a totally unusable path right? Not convinced this is worth fixing (yet).
It's possible that a non-Microsoft filesystem on Windows might allow creating a directory named ":", but that's not explicitly supported by Microsoft. Still, I'd prefer to keep the implementation generic and in principle behave the same as checking for a drive and root via splitroot()
, but without the cost of splitroot()
.
>>> os.path.splitroot('/:/foo')
('', '/', ':/foo')
Also, pathlib.PurePath.is_absolute()
uses ntpath.isabs()
, so it has a similar issue:
>>> pathlib.Path('/:/foo').drive
''
>>> pathlib.Path('/:/foo').root
'\\'
But
>>> pathlib.Path('/:/foo').is_absolute()
True
from cpython.
Right now, I'm with @barneygale. Invalid paths are allowed to have invalid behaviour.
I got an upvote from Barney that it would be better to make isabs()
and splitroot()
consistent, and splitroot()
has the correct behavior. "/:" can never be a drive, and nothing in the Windows API will ever handle it as a drive. The system will try to resolve the path on the drive of the current working directory. Anyway, it isn't critical. It's an invalid path, and at best it's poorly supported by the VirtualBox shared-folder filesystem.
The choice made here should be consistent with whether nineteendo's other issue about calling normpath('/:)
gets fixed or closed as won't fix. If it doesn't matter here that "/:" can never be a drive, then it doesn't matter there either. We'd just let normpath()
handle "/:" as a drive.
from cpython.
Okay then, I'll phrase my preference as:
Expected: False, as
/:/foo
is not a valid absolute path
This means that if we had an isrelative
function, it could also return False. We're in a NaN type situation here, which gives us fairly complete freedom to return whatever we like, since the input is not-a-path. Typically is*
functions return False rather than raise, norm*
type functions do garbage-in-garbage-out, and anything that actually needs to resolve the path should raise.
This also means we can wontfix normpath
and fix this one, and it's perfectly consistent 😉
from cpython.
OK, I'm closing this. If you change your mind this can be re-opened.
from cpython.
Returning False
for "/:foo" is the correct behavior starting with 3.13. Barney fixed ntpath.isabs()
in the PR for #44626.
On Windows, "/:foo" is a rooted path, but it's not an absolute path. When a rooted path is opened directly, it's relative to the drive or UNC share of the current working directory. When a rooted path is the target path of a symlink, it's relative to the drive or UNC share of the opened path of the symlink.
Note that "/:foo" also happens to be invalid in practice, because ":" is reserved by Microsoft's filesystems as an illegal filename character. NTFS and ReFS use colon as the separator in file stream names (e.g. "filename:streamname:streamtype", such as "spam:eggs:$DATA").
from cpython.
Eh, why do the other functions need to handle it correctly then? If you follow the same logic, these wouldn't have been accepted.
from cpython.
Fun fact: You can actually create a directory named ":" on a USB stick on Linux, but Windows treats that as \uf022
(private use).
from cpython.
Fun fact: You can actually create a directory named ":" on a USB stick on Linux, but Windows treats that as
\uf022
(private use).
I guess you mean creating a directory named ":" in a Microsoft filesystem type (e.g. FAT32, NTFS), assuming the Linux driver is configured to allow it. In that case, maybe the driver on Linux is what translates the reserved character to the private use area, or maybe it's done at access time by the filesystem driver on Windows, but mostly likely not by the system I/O manager (i.e. system Io*
API) or Filesystem Runtime Library (i.e. system FsRtl*
API). It's probably the same for other reserved filesystem characters, such as \
, |
or one of the 5 wildcard characters *?<>"
.
The example I had in mind is the VirtualBox shared-folder filesystem, which is lenient about accessing names in the host filesystem (e.g. a Linux host running a Windows guest). But the shared-folder filesystem driver is also broken in many cases. For example, it can open a directory named ":" to set it as the current working directory of a process, but trying to open files in the directory causes the driver to fail with STATUS_OBJECT_PATH_SYNTAX_BAD
(0xC000003B). That's probably due to inconsistent use of the Filesystem Runtime Library.
from cpython.
I can confirm it's the Linux driver: \uf022
is treated as :
, but I wanted to try just in case it would work.
from cpython.
why do the other functions need to handle it correctly then? If you follow the same logic, these wouldn't have been accepted.
What other functions do you mean?
It's possible there was more logic at play there than what is guiding this one, or it's also possible that they were merged by different committers following different logic.
Right now, I'm with @barneygale. Invalid paths are allowed to have invalid behaviour.
from cpython.
What other functions do you mean?
Probably just ntpath.splitroot()
, which might have been accidentially fixed when the logic for handling the root was added.
from cpython.
I probably should've mentioned this sooner, but this also breaks the fallback implementation for ntpath.abspath()
:
>>> import ntpath
>>> ntpath.abspath("/:/foo"), ntpath._abspath_fallback("/:/foo")
('C:\\:\\foo', '/:\\foo')
Ideally these should behave the same, and I think here fixing ntpath.isabs()
and therefore the fallback implementation of ntpath.abspath()
has the lowest risk. The separator will then be fixed automatically, regardless of whether ntpath.normpath()
is fixed.
from cpython.
Related Issues (20)
- Make ZeroDivisionError message more precise when floor-dividing by zero HOT 7
- Popen.send_signal(sigint.SIGKILL) does not seem to work with Popen(*, shell=True)? HOT 4
- Make Python 3.13 coroutines work with multithreading automatically like Goroutines does and some like `go` keyword for later. HOT 1
- Test with the path protocol, not with pathlib.Path
- String module should have a string like printable but without whitespace HOT 10
- Version numbers not supported for shebang line virtual command /usr/bin/env python on windows HOT 7
- "No module named 'Cython'", but only when installing a package and only with pip 23.1 or later HOT 2
- pyrepl doesn't print result if any part came from paste HOT 2
- venv tutorial wrong/confusing about python version used HOT 8
- weird behavior of the import statement HOT 1
- Backport changes from python/cpython#119065 HOT 1
- Regular Expression: re.split behavior weird when have a sub pattern HOT 5
- "TypeError: catching classes that do not inherit from BaseException is not allowed" error when using generic in `except` block HOT 4
- Misleading sqlite3.Cursor.rowcount docs HOT 3
- New pyrepl gives a traceback on exit with "dumb" terminal HOT 11
- Unable to build to WASI HOT 8
- Inconsistent KeyboardInterrupt Handling in multiprocessing due to Context Manager Order
- difflib.py Differ.compare is too slow [for degenerate cases] HOT 36
- functools.partial does not re-set vector call.
- EnumType __call__ method description does not match the implementation HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cpython.