➜
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2016-06-05 11:19 by acue, last changed 2022-04-11 14:58 by admin. This issue is now closed.
| Messages (3) | |||
|---|---|---|---|
| msg267407 - (view) | Author: Arno-Can Uestuensoez (acue) | Date: 2016-06-05 11:19 | |
I am currently finishing a file system library and use 'os.path.normpath' for canonical input into match-operations. So already found Issue26329 - IEEE-1003.1-Chap 4.2 and written a comment. But I guess this issue should be handled seperately. Now have to deal by myself with the eventual prefix 'file://' for input, and guess it should be supported. I did not found a statement on this case, so issue this for clarification. The 'os.path.normpath' call simply replaces subsequent os.sep, when they are not leading as 1003.1 states. But how should the following examples be handled: file:////a => /a OR //a ??? file://///a => /a OK file:///a => /a OK |
|||
| msg267408 - (view) | Author: Steven D'Aprano (steven.daprano) *  |
Date: 2016-06-05 11:47 | |
"file://a" is a valid relative file path, for a directory called "file:" and a file called "a", so normpath should return "file:/a". |
|||
| msg267412 - (view) | Author: Georg Brandl (georg.brandl) * |
Date: 2016-06-05 12:11 | |
`os.path` does not handle URIs of any type, so this behavior is correct as Steven says. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:58:32 | admin | set | github: 71415 |
| 2016-06-05 12:11:02 | georg.brandl | set | status: open -> closed nosy: + georg.brandl messages: + msg267412 resolution: not a bug |
| 2016-06-05 11:47:30 | steven.daprano | set | nosy:
+ steven.daprano messages: + msg267408 |
| 2016-06-05 11:19:28 | acue | create | |