[issue39517] runpy calls open_code with Path object
Maor Kleinberger added the comment: Great, thank you! -- ___ Python tracker <https://bugs.python.org/issue39517> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39517] runpy calls open_code with Path object
Maor Kleinberger added the comment: Hey there, the PR was approved a week ago, is there a reason it is not merged yet? -- ___ Python tracker <https://bugs.python.org/issue39517> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Maor Kleinberger added the comment: Hey there, it's been more than a week since I pushed the last changes, can anyone review them? -- ___ Python tracker <https://bugs.python.org/issue39622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39517] runpy calls open_code with Path object
Change by Maor Kleinberger : -- keywords: +patch pull_requests: +18060 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18699 ___ Python tracker <https://bugs.python.org/issue39517> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Change by Maor Kleinberger : -- versions: +Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Maor Kleinberger added the comment: I have pushed an update to my PR. While implementing the new solution I made the following list: Examples for code segments where KeyboardInterrupt must not be raised: - Between popping and running a handle from the ready queue (a handle is lost) - After running a handle and before a subsequent call_soon finished running (the handle that should have been added by call_soon is lost) - After a handle is popped from the _scheduled heap and added to the _ready queue (a handle is lost) Code segments where KeyboardInterrupt must be raised: - During the select call (can be achieved using signal.default_int_handler or signal.set_wakeup_fd) - During a running callback (can be achieved using signal.default_int_handler) I think that while the loop is running, the signal handler should not raise a KeyboardInterrupt by default, as there are at least 3 unsafe code segments, and more might be added in the future. Currently, the only two segments that have to be directly interrupted by a SIGINT are the ones listed above, and I think this behavior should be allowed explicitly. This is what I did in the new revision of my PR. -- ___ Python tracker <https://bugs.python.org/issue39622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Maor Kleinberger added the comment: While looking into this proposal, I realized that this will not wake up the loop from the select call. I think the safest solution would be to use the wakeup fd mechanism. An additional easy, but less secure solution would be to define an internal 'signal safe' context manager that will be used only in the critical parts. What do you think? -- ___ Python tracker <https://bugs.python.org/issue39622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Maor Kleinberger added the comment: Damn, good catch. How about the following idea - register a normal signal handler (using signal.signal) that does something like: def sigint_handler(): get_running_loop().interrupt() # in class BaseEventLoop def interrupt(self): # Might be a generally useful thread-safe way to interrupt a loop if self._is_inside_callback(): _thread.interrupt_main() # All this behavior is only relevant to the main thread anyway else: self._interrupted = True And inside BaseEventLoop._run_once() add the following check: # in class BaseEventLoop def _check_interrupted(self): # This will be called by BaseEventLoop._run_once() before calling select, # and before popping any handle from the ready queue if self._interrupted: raise KeyboardInterrupt -- ___ Python tracker <https://bugs.python.org/issue39622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Maor Kleinberger added the comment: After opening the PR, I see that add_signal_handler is not supported on non-unix event loop. After looking at the code, it seems there is no problem to implement it for other platforms, as it relies on signal.set_wakeup_fd() which seems to support all platforms. Should I open an enhancement issue for implementing add_signal_handler for all platforms? -- ___ Python tracker <https://bugs.python.org/issue39622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Maor Kleinberger added the comment: After digging into asyncio, I stumbled upon this particularly suspicious block in BaseEventLoop._run_once: https://github.com/python/cpython/blob/v3.9.0a3/Lib/asyncio/base_events.py#L1873 handle = self._ready.popleft() if handle._cancelled: continue if self._debug: ... handle._run() ... else: handle._run() As you can see, a callback is popped from the dequeue of ready callbacks, and only after a couple of lines that callback is called. The question arises, what happens if an exception is raised in between? Or more specifically, What happens to that callback if a KeyboardInterrupt is raised before it is called? Well, appparently it dies and becomes one with the universe. The chances of it happening are the highest when the ioloop is running very short coroutines (like sleep(0)), and are increased when debug is on (because more code is executed in between). This is how the bug we've been experiencing came to life: When SIGINT is received it raises a KeyboardInterrupt in the running frame. If the running frame is a coroutine, it stops, the exception climbs up the stack, and the ioloop shuts down. Otherwise, the KeyboardInterrupt is probably raised inside asyncio's code, somewhere inside run_forever. In that case, the ioloop stops and proceeds to cancel all of the running tasks. After cancelling all the tasks, asyncio actually reruns the ioloop so all tasks receive the CancelledError and handle it or just die (see asyncio.runners._cancel_all_tasks). Enter our bug; sometimes, randomly, the loop gets stuck waiting for all the cancelled tasks to finish. This behavior is caused by the flaw I described earlier - if the KeyboardInterrupt was raised after a callback was popped and before it was run, the callback is lost and the task that was waiting for it will wait forever. Depending on the running tasks, the event loop might hang on the select call (until a interrupted by a signal, like SIGINT). This is what happens in SleepTest.py. Another case might be that only a part of the ioloop gets stuck, and other parts that are not dependent on the lost call still run correctly (and run into a CancelledError). This behavior is demonstrated in the script I added to this thread, asyncio_bug_demo.py. I see two possible solutions: 1. Make all the code inside run_forever signal safe 2. Override the default SIGINT handler in asyncio.run with one more fitting the way asyncio works I find the second solution much easier to implement well, and I think it makes more sense. I think python's default SIGINT handler fits normal single-threaded applications very well, but not so much an event loop. When using an event loop it makes sense to handle a signal as an event an process it along with the other running tasks. This is fully supported by the ioloop with the help of signal.set_wakeup_fd. I have implemented the second solution and opened a PR, please review it and tell me what you think! -- Added file: https://bugs.python.org/file48906/asyncio_bug_demo.py ___ Python tracker <https://bugs.python.org/issue39622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Change by Maor Kleinberger : -- keywords: +patch pull_requests: +17992 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18628 ___ Python tracker <https://bugs.python.org/issue39622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39623] __str__ and __repr__ for asyncio.Task still omit arg values
Maor Kleinberger added the comment: Oh I just learned that since python3.8 you can name individual tasks. Sorry for the confusion :) It does seem like a good solution. -- ___ Python tracker <https://bugs.python.org/issue39623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39623] __str__ and __repr__ for asyncio.Task still omit arg values
Maor Kleinberger added the comment: > Not so easy to find a satisfactory generic approach. I agree, but wouldn't you agree that some information is better than no information? >Task has a name exactly for the purpose of distinguishing similar but >different tasks But in case the same task is run many times with different arguments, the task's name by itself doesn't provide very useful information... -- ___ Python tracker <https://bugs.python.org/issue39623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39557] ThreadPoolExecutor is busy-waiting when idle.
Maor Kleinberger added the comment: > If I understand the following code correctly, there seems to be a busy loop > waiting for the SimpleQueue.put to signal that an item was entered to queue. This is not a busywait. Actually, the loop you specified will never repeat more than twice. At the first iteration, the queue's lock is acquired. At the second iteration, the loop waits for the lock to be released (by trying to acquire the lock again, which is not busywait). The lock is only released when something is put into the queue, so at that point the loop exits and the function returns. Avraham, could you provide a minimal python script that will reproduce the CPU usage spike? -- nosy: +kmaork ___ Python tracker <https://bugs.python.org/issue39557> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Maor Kleinberger added the comment: I wrote a small script that checks the behavior of asyncio.sleep when called with small amounts of time (starting from 0). For each amount I checked 500 times whether SleepTest has stopped when interrupted with SIGINT. Below are the results: SLEEP TIME SIGINT FAILURE PERCENT 0 26.6% 1e-06 9.8% 2e-06 11.8% 3e-06 11.2% 4e-06 9.6% 5e-06 13.8% 6e-06 5.6% 7e-06 2.6% 8e-06 1.4% 9e-06 1.6% 1e-05 2.2% 1.1e-05 2.2% 1.2e-05 2.0% 1.3e-05 1.8% 1.4e-05 0.8% It is worth mentioning that the failure amount increased when my CPU was busier. Maybe it is because of false positives in my script (although I think I used relatively generous timeouts when waiting for the ioloop to start running and for the process to die after a SIGINT) and maybe it is because of the nature of the bug in asyncio. I didn't put a lot of effort into distinguishing between the two, as increasing the timeouts also made my CPU less busy. Anyway, there is definitely a weird behavior here, and I still think there is a specific piece of code in asyncio that's causing it. Maybe I'll look at the code a bit, or try to think of other ways to approach this. -- ___ Python tracker <https://bugs.python.org/issue39622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Maor Kleinberger added the comment: This behaved similarly on my machine, also ubuntu. But it also happened (less often) with small numbers, like sleep(0.01). Also, I tried it on my windows 10 and experienced another unexpected behavior - only when using sleep(0), Ctrl-C would not work *at all* from time to time. Most of the times it would stop the program immediately. This also happened when using 0.01 instead of 0. Unless 0.01 turns into 0 somewhere along the way, I'd suspect that there is a piece of code inside asyncio's core that doesn't handle interrupting correctly (both on linux and windows), and using sleep with small numbers just makes it much more probable for this piece of code to be running when the Ctrl-C signal is sent. I'll try to dig in more. -- ___ Python tracker <https://bugs.python.org/issue39622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39298] add BLAKE3 to hashlib
Change by Maor Kleinberger : -- nosy: +kmaork ___ Python tracker <https://bugs.python.org/issue39298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39517] runpy calls open_code with Path object
Maor Kleinberger added the comment: Not a direct solution, but I have offered that io.open_code should be changed to support pathlike objects: https://bugs.python.org/issue39691 -- nosy: +kmaork ___ Python tracker <https://bugs.python.org/issue39517> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39691] Allow passing Pathlike objects to io.open_code
New submission from Maor Kleinberger : As in many functions in python3, io.open_code should probably accept pathlike objects and not just path strings. Below is open_code's docstring: > Opens the provided file with the intent to import the contents. > This may perform extra validation beyond open(), but is otherwise > interchangeable with calling open(path, 'rb'). The second bit is not entirely true, as open accepts pathlike objects and open_code doesn't. Fixing this will help solve future bugs and existing bugs like https://bugs.python.org/issue39517 I'd be happy to open a pull request if it is agreed that this should be changed. -- components: Library (Lib) messages: 362292 nosy: kmaork priority: normal severity: normal status: open title: Allow passing Pathlike objects to io.open_code type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39691> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39622] KeyboardInterrupt is ignored when await asyncio.sleep(0)
Maor Kleinberger added the comment: On which OS did that happen? -- nosy: +kmaork ___ Python tracker <https://bugs.python.org/issue39622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39623] __str__ and __repr__ for asyncio.Task still omit arg values
Maor Kleinberger added the comment: > This could sometimes make the output verbose We could limit the length of the recursive __repr__ functions, and display partial reprs suffixed with ..., like in numpy for example. We can define that the maximum wanted length of a task repr would be, say, 80 characters, get the reprs of all task arguments, and if the sum length is more than the maximum we can trim the longest ones and suffix with a '...'. Maybe this restriction shouldn't be applied if python is built in debug mode. -- nosy: +kmaork ___ Python tracker <https://bugs.python.org/issue39623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39603] [security] http.client: HTTP Header Injection in the HTTP method
Maor Kleinberger added the comment: Hey, it's been a week since the last activity here... Amir, if you are not working on it I'd be glad to work on it as well :) -- nosy: +kmaork ___ Python tracker <https://bugs.python.org/issue39603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34775] pathlib.PurePath division raises TypeError instead of returning NotImplemented
Change by Maor Kleinberger : -- pull_requests: +17426 pull_request: https://github.com/python/cpython/pull/12361 ___ Python tracker <https://bugs.python.org/issue34775> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths
Maor Kleinberger added the comment: > Is this related to the weird paths I am seeing when getting different output > in venv compared to without venv This is probably not related, sounds like something caused by the venv implementation. On a different note, how do I get my PR reviewed? (https://github.com/python/cpython/pull/12361) -- ___ Python tracker <https://bugs.python.org/issue36305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths
Maor Kleinberger added the comment: Alright. And what is left to do with the current issue? -- ___ Python tracker <https://bugs.python.org/issue36305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths
Maor Kleinberger added the comment: What can we do in order to make progress here? -- ___ Python tracker <https://bugs.python.org/issue36305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths
Maor Kleinberger added the comment:
> Ah, I think I follow now. But I'm not sure what you mean by wanting it to
> "retain an initial '.' component" - how would you expect that to work in
> practice? p1.parts == ('.', 'c:a')? I suspect that could break existing code.
I've dealt with that in my PR by checking in the __str__ method if the path
could be misinterpreted, and if so prepending a './'.
> > The CreateProcessW case is a generalization of the case that we're used to
> > across various platforms, in which, for the sake of security, the "." entry
> > is excluded from PATH. In this case, the only way to run an executable in
> > the working directory is to reference it explicitly. For example (in Linux):
[...]
> > This would work if pathlib kept the initial "." component.
> Thanks, this is a really useful example, as it makes it clear that this is a
> general issue, not a platform-specific quirk.
In my opinion, this is a different problem, that its solution doesn't
necessarily belong in pathlib. Pathlib is responsible to parse, manipulate and
display paths correctly (which it fails to do with the case of Path('./a:b') ->
Path('a:b')). In contrast, in the case of CreateProcessW, both Path('./exec')
and Path('exec') are the *correct* paths to the executable. The ./ is not
necessary in that case to display the path correctly, but just to interact
correctly with CreateProcessW's interface.
> Having said all of this, I'm not at all sure how much it relates to the
> original description of this issue, which didn't mention initial './'
> components at all. Is the originally reported behaviour a *consequence* of
> not retaining './', or is it a separate problem? If the latter, then maybe
> "Pathlib should retain an initial './'" would be better raised as a separate
> bpo item (and PR)?
I completely agree that any change made to support retaining the initial './'
for process invocation should be made in a different bpo item and PR. I do
disagree though, that such change should be made, as like I wrote above, this
is only needed for CreateProcessW's interface, and isn't related to pathlib's
logic itself.
Maybe, a nice idea would be to open a separate PR that would add a utility for
dealing with executing paths. Something like Path.popen(cmd_args, **kwargs),
that will call Popen with a path prepended with a './' if needed.
--
___
Python tracker
<https://bugs.python.org/issue36305>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths
Maor Kleinberger added the comment: Alright, documentation is always good :) I'll be glad to add some, but could you please point me to the place in the code where you think it should go? (or just comment on the PR) -- ___ Python tracker <https://bugs.python.org/issue36305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths
Maor Kleinberger added the comment:
> OK, sure. My point is that "relative path to the current directory on
the drive with the specified letter" isn't a concept that matches how
"relative paths" are typically interpreted (most code interprets
"relative" as "relative to the CWD", and doesn't deal with the
possibility of per-drive CWDs).
In pathlib, each path object has a drive, a root and path parts. Seeing
pathlib's logic and tests (many tests are specifically testing the behavior of
drive-relative paths), I think pathlib completely supports drive relative
paths, with the exception of a few small bugs.
> > > I'm comfortable with WindowsPath("./b:a") returning WindowsPath("b:a")
> > I disagree with that as well. "./b:a" is explicitly a path relative to the
> > CWD (to a file named b:a). On the other hand, "b:a" should be (an is, in
> > most windows programs) interpreted as a drive relative path.
> Windows is inconsistent here - it can *also* be interpreted as a path
to a stream within a file. But it (virtually) never is.
I think that when parsing windows paths, pathlib should behave exactly like the
windows API does. This is crucial for interaction with the windows API itself
or with other applications that might use it. I don't see any other way to
parse windows paths other than according to the normal windows behavior.
Having said that, pathlib does a pretty good keeping the compatibility with the
windows API, except for the small cases I found and brought forward in this
issue report. From the information I gathered, when a path starts with one
letter followed by a colon, windows treats it as a drive and continues parsing
the rest of the path separately. That means that if you want to specify a path
to a file in the CWD, with a single-character name and a file stream, you must
precede the path with a "./" (See eryksun's comment on my PR before I fixed it
https://github.com/python/cpython/pull/12361#discussion_r266193727).
Here is an example for the behavior of the windows API in this case:
win32api.GetFullPathName('b:a') -> 'B:\\a'
win32api.GetFullPathName('./b:a') -> 'C:\\Users\\maor\\b:a'
> Also, in effect it means that Path(".") / some_path can return a
completely different location than some_path.
This behavior is completely normal. Should WindowsPath('C:\\f') /
WindowsPath('D:\\f2') return anything other than WindowsPath('D:/f2')?
> And I think the problem is that "drive-relative paths" are somewhat odd
> things that don't fit well in the POSIX-derived model that Python's path APIs
> follow.
As I wrote earlier, I think this is incorrect as the pathlib.Path class holds
the attributes _drv, _root and _parts, which allows it to fully support
drive-relative paths, by having a _drv and not having a _root.
> I'm happy to agree to differ on this point, though. If the new
behaviour is just a side-effect of fixing absolute() to match the
cases Eryk commented on, then that's fine - I just wouldn't describe
the particular ./b:c cases as "bug fixes", rather as "changes in the
behaviour of cases no-one should actually care about" :-)
I'm still that my case is convincing enough, but if not - does that require me
to make any changes in order to make progress with my PR?
> BTW, was there an actual use case for this issue, or was it simply a
theoretical concern?
I've had an annoying bug using pathlib, traced it to the first bug I've
presented in this issue, and discovered a few similar unhandled edge cases.
Again, the "bugginess" I set upon to fix (call it a bug or an undefined
behavior) is an incompatibility issue with the way paths are normally treated
in windows.
--
___
Python tracker
<https://bugs.python.org/issue36305>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths
Maor Kleinberger added the comment:
> (Note: I consider all of these to be *extremely* obscure corner cases)
One bug was enough for me :)
> [Note there is no absolute() method - I assume you mean resolve()]
Of course there is an absolute() method, I'm not sure what you are saying...
> it seems to me that 'b:a' is "absolute-ish" (drive-relative)
I think that is incorrect. As written here:
https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#fully-qualified-vs-relative-paths,
"If a file name begins with only a disk designator but not the backslash after
the colon, it is interpreted as a relative path to the current directory on the
drive with the specified letter."
In that case, WindowsPath('C:a').is_absolute() should return False, (as it does
today) and WindowsPath('C:a').absolute() should return a path on drive C:, with
'a' joined with the working directory in drive C:.
> I'm comfortable with WindowsPath("./b:a") returning WindowsPath("b:a")
I disagree with that as well. "./b:a" is explicitly a path relative to the CWD
(to a file named b:a). On the other hand, "b:a" should be (an is, in most
windows programs) interpreted as a drive relative path.
For example, the ntpath module handles these cases correctly. When located in
the directory C:\\d, this is the ntpath behavior:
ntpath.abspath('b:a') -> 'B:\\a'
ntpath.abspath('.\\b:a') -> 'C:\\d\\b:a'
In conclusion, I stand by my original fix offers. They are correct according to
windows' documentation and behavior.
--
___
Python tracker
<https://bugs.python.org/issue36305>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths
Maor Kleinberger added the comment:
Update after editing my PR - the bugs are:
1. WindowsPath('C:a').absolute() should return WindowsPath('C:\\d\\a') but
returns WindowsPath('C:a').
This is caused by flawed logic in the parse_parts method of the _Flavour class.
2. WindowsPath('./b:a').absolute() should return WindowsPath('C:\\d\\b:a') but
returns WindowsPath('b:a').
This is caused by the limited interface of parse_parts, and affects the
Path.absolute, Path.expanduser and Path.__rtruediv__ methods.
3. WindowsPath('./b:a').resolve() should return WindowsPath('C:\\d\\b:a') but
returns WindowsPath('b:a').
This is caused by missing logic in the resolve method and in Path.__str__
It'd be great if someone could review the PR so we can make progress with
fixing the bugs.
--
___
Python tracker
<https://bugs.python.org/issue36305>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths
Change by Maor Kleinberger : -- keywords: +patch pull_requests: +12328 stage: test needed -> patch review ___ Python tracker <https://bugs.python.org/issue36305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths
Maor Kleinberger added the comment: I agree. So I'll open a PR that will: 1. Make the .absolute method return correct values in these cases 2. Add a regression test for this behavior -- ___ Python tracker <https://bugs.python.org/issue36305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths
New submission from Maor Kleinberger :
The behavior of WindowsPath is undefined when used with drive paths,
specifically with no trailing slash:
WindowsPath('cc:').absolute() -> WindowsPath('C:/Users/maor/cc:')
WindowsPath('c:').absolute() -> WindowsPath('c:')
WindowsPath('c:').is_absolute() -> False
WindowsPath('c:') / 'p' -> WindowsPath('c:p')
WindowsPath('c:p').absolute() -> WindowsPath('c:p')
WindowsPath('c:p').is_absolute() -> False
--
components: Library (Lib)
messages: 337999
nosy: kmaork
priority: normal
severity: normal
status: open
title: Inconsistent behavior of pathlib.WindowsPath with drive paths
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue36305>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
