Change by fireattack :
--
nosy: +fireattack
___
Python tracker
<https://bugs.python.org/issue39658>
___
___
Python-bugs-list mailing list
Unsubscribe:
fireattack added the comment:
Sorry, I should link https://docs.python.org/3/library/shutil.html#shutil.move
for latest doc. But the content is the same.
--
___
Python tracker
<https://bugs.python.org/issue42
New submission from fireattack :
According to https://docs.python.org/3.8/library/shutil.html#shutil.move
"If the destination already exists but is not a directory, it may be
overwritten depending on os.rename() semantics."
I interpret "depending on os.rename() sem
fireattack added the comment:
>Yes, you are right. This is a feature of the ThreadPoolExecutor.
So is there any way to make the Executor actually wait and accept new job(s)
after a while? I tried as_completed(), wait(), none seem to w
Change by fireattack :
--
nosy: +fireattack
___
Python tracker
<https://bugs.python.org/issue36541>
___
___
Python-bugs-list mailing list
Unsubscribe:
fireattack added the comment:
Here is another more bizarre showcase of the issue I come up with.
If you do:
```
import concurrent.futures
import time
def test():
time.sleep(3)
print('test')
ex = concurrent.futures.ThreadPoolExecutor(max_workers=10)
ex.submit(test
fireattack added the comment:
Hi gaoxinge, thanks for the reply.
I assume what you mean is that while shutdown will wait, it won't accept any
new job/future after it is called.
That makes sense, but this still doesn't work:
```
from concurrent.futures import ThreadPoolExecutor
from time
New submission from fireattack :
Example
```
from concurrent.futures import ThreadPoolExecutor
from time import sleep
def wait_on_future():
sleep(1)
print(f.done()) # f is not done obviously
f2 = executor.submit(pow, 5, 2)
print(f2.result())
sleep(1)
executor
fireattack added the comment:
More interestingly, I can't reproduce the same bug on my another Win 7 machine
with similar setup.
--
___
Python tracker
<https://bugs.python.org/issue28
fireattack added the comment:
Just copy/paste a related issue reported in issue39785:
When run a python script with "#!/usr/bin/python" shebang with py.exe, it will
always use python2 instead of python3 on Win 10, despite the default being set
to py3 already (so does the PATH).
fireattack added the comment:
Interestingly, I can't seem to reproduce this bug on my another Win7 machine
with similar setup.
--
___
Python tracker
<https://bugs.python.org/issue39
Change by fireattack :
--
title: usr/bin/python doesn't use default python (3) on Windows ->
#!/usr/bin/python shebang doesn't use default python (3) on Windows
___
Python tracker
<https://bugs.python.org/issu
fireattack added the comment:
I've searched and found some related issue, but none is specific for this.
For example, Segev Finer mentioned that "[..] "#!/usr/bin/python" which will
prefer Python 2" in issue 34274 but didn't mention
New submission from fireattack :
STR
1. Install both Py2 and 3.
2. Make sure Py3 is the default.
3. (Optional) Make sure only Python3 is in path, not Python2.
Run the following script from CMD:
```
#!/usr/bin/python
import platform
print(platform.python_version())
```
What expected
fireattack <human.p...@gmail.com> added the comment:
Well, since it affects Python's site's functionality, I thought it's
appropriate to report here (with components: documentation). I followed the
instruction here: https://docs.python.org/3/bugs.html#documentation-bugs
It is not Sphinx
New submission from fireattack <human.p...@gmail.com>:
Problem
This is a regression bug/flaw in Sphinx's doctools.js, a JS file used in its
base template, and therefore got inherited to Python 3's documentation website.
Python 2's documentation website is not affected because it's
fireattack added the comment:
Any update on this?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15809>
___
___
Python-bugs-list
17 matches
Mail list logo
