Maor Kleinberger added the comment:
Great, thank you!
--
___
Python tracker
<https://bugs.python.org/issue39517>
___
___
Python-bugs-list mailing list
Unsub
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/issue39
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/is
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/issu
Change by Maor Kleinberger :
--
versions: +Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39622>
___
___
Python-bugs-list mailin
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
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
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
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
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
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/issu
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/issue39
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
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.
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
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
Change by Maor Kleinberger :
--
nosy: +kmaork
___
Python tracker
<https://bugs.python.org/issue39298>
___
___
Python-bugs-list mailing list
Unsubscribe:
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.
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 valida
Maor Kleinberger added the comment:
On which OS did that happen?
--
nosy: +kmaork
___
Python tracker
<https://bugs.python.org/issue39622>
___
___
Python-bug
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,
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.o
Change by Maor Kleinberger :
--
pull_requests: +17426
pull_request: https://github.com/python/cpython/pull/12361
___
Python tracker
<https://bugs.python.org/issue34
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 re
Maor Kleinberger added the comment:
Alright. And what is left to do with the current issue?
--
___
Python tracker
<https://bugs.python.org/issue36305>
___
___
Maor Kleinberger added the comment:
What can we do in order to make progress here?
--
___
Python tracker
<https://bugs.python.org/issue36305>
___
___
Python-bug
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 th
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
&
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"
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 sayi
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
Change by Maor Kleinberger :
--
keywords: +patch
pull_requests: +12328
stage: test needed -> patch review
___
Python tracker
<https://bugs.python.org/issu
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/is
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(
34 matches
Mail list logo
