[issue39658] Include user scripts folder to PATH on Windows

[fireattack]

Change by fireattack :


--
nosy: +fireattack

___
Python tracker 
<https://bugs.python.org/issue39658>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42929] On Windows, shutil.move doesn't raise FileExistsError if dst exists like os.rename

[fireattack]

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/issue42929>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42929] On Windows, shutil.move doesn't raise FileExistsError if dst exists like os.rename

[fireattack]

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() semantics" to mean it will follow 
os.rename()'s behavior.

According to https://docs.python.org/3/library/os.html#os.rename

"On Windows, if dst exists a FileExistsError is always raised."

However, their behaviors are not the same.

For os.rename, it does raise FileExistsError if dst exists.
For shutil.move, it silently overwrites dst.

It's either a bug in behavior of shutil.move, or the documentation need to be 
updated.

--
components: Library (Lib)
messages: 385083
nosy: fireattack
priority: normal
severity: normal
status: open
title: On Windows, shutil.move doesn't raise FileExistsError if dst exists like 
os.rename
type: behavior
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue42929>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40093] ThreadPoolExecutor with wait=True shuts down too early

[fireattack]

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 work.

--

___
Python tracker 
<https://bugs.python.org/issue40093>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36541] Make lib2to3 grammar better match Python, support the := walrus

[fireattack]

Change by fireattack :


--
nosy: +fireattack

___
Python tracker 
<https://bugs.python.org/issue36541>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40093] ThreadPoolExecutor with wait=True shuts down too early

[fireattack]

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)
```

This will print "test" after 3 seconds just fine.

Now, if you do:

```
import concurrent.futures
import time

def test():
time.sleep(3)
ex.submit(print, 'ex-print')
print('test') #this is not printed

ex = concurrent.futures.ThreadPoolExecutor(max_workers=10)
ex.submit(test)
```

Not only it doesn't print "ex-print", it does NOT even print "test" any more. 
And this is no error.

--

___
Python tracker 
<https://bugs.python.org/issue40093>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40093] ThreadPoolExecutor with wait=True shuts down too early

[fireattack]

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 import sleep

def wait_on_future():
sleep(1)
f2 = executor.submit(pow, 5, 2)
print(f2.result())
executor.shutdown(wait=True) #Uncomment/comment this makes no difference

executor = ThreadPoolExecutor(max_workers=100)
f = executor.submit(wait_on_future)
```

This shows no error, but f2.result() is still not printed (`result()` has 
built-in wait). Actually, f2 is not executed at all (you can change pow to 
other func to see that).

Please notice this example is modified from an example from the official 
documentation: https://docs.python.org/3/library/concurrent.futures.html 

In that example, the comment says "This will never complete because there is 
only one worker thread and it is executing this function.", which is correct. 
But this is kinda misleading because it implies it will work if you increase 
the number of the worker. However, it will NOT work if you increase the number 
of worker, but also add a small delay, like shown above.

The point is, I failed to find a way to keep executor from main thread alive to 
accept future/job from a child thread if there is a delay. I tried 
shutdown/nothing/with/as_completed they all fail in similar fashion.

--

___
Python tracker 
<https://bugs.python.org/issue40093>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40093] ThreadPoolExecutor with wait=True shuts down too early

[fireattack]

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 = ThreadPoolExecutor(max_workers=100)
f = executor.submit(wait_on_future)
executor.shutdown(wait=True)
```

When debugging, it shows "cannot schedule new futures after shutdown":

Exception has occurred: RuntimeError
cannot schedule new futures after shutdown
File "test2.py", line 7, in wait_on_future
f2 = executor.submit(pow, 5, 2)

According to https://docs.python.org/3/library/concurrent.futures.html, 
`shutdown(wait=True)` "[s]ignal the executor that it should free any resources 
that it is using when the currently pending futures are done executing". But 
when f2 is being submitted, f is not done yet, so executor shouldn't be shut 
down.

--
components: Library (Lib)
messages: 365194
nosy: fireattack
priority: normal
severity: normal
status: open
title: ThreadPoolExecutor with wait=True shuts down too early
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue40093>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28686] py.exe ignored PATH when using python3 shebang

[fireattack]

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/issue28686>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28686] py.exe ignored PATH when using python3 shebang

[fireattack]

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).

According to https://docs.python.org/3/using/windows.html#shebang-lines, 
`#!/usr/bin/python` should use the default python, not just python 2.

--
nosy: +fireattack

___
Python tracker 
<https://bugs.python.org/issue28686>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39785] #!/usr/bin/python shebang doesn't use default python (3) on Windows

[fireattack]

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/issue39785>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39785] #!/usr/bin/python shebang doesn't use default python (3) on Windows

[fireattack]

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/issue39785>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39785] usr/bin/python doesn't use default python (3) on Windows

[fireattack]

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 why it would/should.

--

___
Python tracker 
<https://bugs.python.org/issue39785>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39785] usr/bin/python doesn't use default python (3) on Windows

[fireattack]

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:

3.8.1

What happened: 

2.8.5

According to https://docs.python.org/3/using/windows.html#shebang-lines, 
`#!/usr/bin/python` should use the default python. My environment is set to 
default to py3, and I don't even have python2 in my PATH. 

C:\Users\ikena\Desktop>py --version
Python 3.8.1

C:\Users\ikena\Desktop>python --version
Python 3.8.1

C:\Users\ikena\Desktop>where python
C:\Users\ikena\AppData\Local\Programs\Python\Python38\python.exe
C:\Users\ikena\AppData\Local\Microsoft\WindowsApps\python.exe

--
components: Windows
messages: 362892
nosy: fireattack, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: usr/bin/python doesn't use default python (3) on Windows
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue39785>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31668] "fixFirefoxAnchorBug" function in doctools.js causes navigating problem in Py3 doc in Chrome

[fireattack]

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's bug per se, since it has nothing to do with its software; 
just an ancient problematic script in template got copied here. 

It is not a Chrome bug, since that script was not intended to apply to Chrome 
to begin with.

But anyway, if anyone found it's not the right place, feel free to close it.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31668>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31668] "fixFirefoxAnchorBug" function in doctools.js causes navigating problem in Py3 doc in Chrome

[fireattack]

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 based on an older 
version of Sphinx.

There is a function in doctools.js:

/**
* workaround a firefox stupidity
* see: https://bugzilla.mozilla.org/show_bug.cgi?id=645075
*/
fixFirefoxAnchorBug : function() {
if (document.location.hash)
window.setTimeout(function() {
document.location.href += '';
}, 10);
}


This function was supposed to fix an anchor bug in Firefox (see comment). It 
*used to* have a condition of $.browser outside, so it will only be applied to 
Firefox; but it was removed in JQuery so it was removed here as well. 
Therefore, this function now applies to all the browsers. Unfortunately, it 
causes navigating problem in Chrome now, when you use back and forward.

The problem STR (Chrome only):

1. Open a link with hash (anchor), e.g. 
https://docs.python.org/3/library/stdtypes.html#text-sequence-type-str
2. Scroll away from the anchor position.
3. Click any external link (means the link that is not an anchor of current 
page).
4. Hit "back" button in the browser.

What happened:

When you navigating back, it doesn't go to your previous position. Instead, it 
goes to the anchor's location.

What it should do:

It should go to your previous position.

Ironically, it won't cause this problem in Firefox, despite it's supposed to be 
a fix for (a different) anchor bug in Firefox.

Comments

I reported it to Sphinx as well: 
https://github.com/sphinx-doc/sphinx/issues/3549 but didn't get any response so 
far.

Please keep in mind the Firefox anchor bug mentioned above will only happen if 
the anchor is assigned with . From my observation we don't really 
use  in HTML, so I don't think this workaround function is really 
necessary here to begin with.

--
assignee: docs@python
components: Documentation
messages: 303576
nosy: docs@python, fireattack
priority: normal
severity: normal
status: open
title: "fixFirefoxAnchorBug" function in doctools.js causes navigating problem 
in Py3 doc in Chrome
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31668>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15809] 2.7 IDLE console uses incorrect encoding.

[fireattack]

fireattack added the comment:

Any update on this?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15809>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com