[issue44070] Regression with relative paths in sys.path in python 3.8.10
James Saryerwinnie added the comment: > What's the actual scenario that this broke? I only noticed this because a project that I work on (https://github.com/aws/chalice/) started failing CI for seemingly unrelated changes. A specific test run is here: https://github.com/jamesls/chalice/runs/2529906754. This didn't actually break the framework itself, just the tests for the framework. Chalice imports your application to figure out what resources to deploy to AWS, so the functional tests need to setup/teardown misc. applications and re-import them fresh for each test. Turns out the GitHub action I was using switched their Python 3.8 from 3.8.9 to 3.8.10 so I started looking into why this failed. My takeaway from this is to stop using relative imports in sys.path (I don't recall us having a specific reason to do this other than it worked). I figured I'd file an issue as I'm not actually sure if this consequence was intentional (I only saw bpo-43105 mentioned in the changelog), and was surprised this behavior changed in a patch release. -- ___ Python tracker <https://bugs.python.org/issue44070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44070] Regression with relative paths in sys.path in python 3.8.10
New submission from James Saryerwinnie :
There was a change in behavior in Python 3.8.10 when using relative paths in
sys.path. It appears that the paths are now converted to absolute paths that
are cached and can cause import errors in some cases.
Repro:
$ cat repro.sh
#!/bin/bash
python --version
mkdir -p /tmp/repro/{A,B}/testproject
echo "msg = 'from A'" > /tmp/repro/A/testproject/app.py
echo "msg = 'from B'" > /tmp/repro/B/testproject/app.py
python -c "
import sys, os, shutil
os.chdir('/tmp/repro/A')
sys.path.append('testproject')
import app
print(app)
print(app.msg)
os.chdir('/tmp/repro/B')
shutil.rmtree('/tmp/repro/A')
del sys.modules['app']
import app
print(app)
print(app.msg)
"
rm -rf /tmp/repro
On Python 3.8.9 I get:
$ ./repro.sh
Python 3.8.9
from A
from B
On Python 3.8.10 I get:
$ ./repro.sh
Python 3.8.10
from A
Traceback (most recent call last):
File "", line 12, in
ModuleNotFoundError: No module named 'app'
I haven't confirmed this (I can't work out the frozen bootstrap stuff), but
this might be caused by https://bugs.python.org/issue43105, whose patch does
seem to be converting paths to absolute paths.
--
components: Library (Lib)
messages: 393212
nosy: James.Saryerwinnie
priority: normal
severity: normal
status: open
title: Regression with relative paths in sys.path in python 3.8.10
type: behavior
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44070>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29288] Lookup Error while importing idna from a worker thread
James Saryerwinnie added the comment:
I ran into this as well also using the embedded distribution for windows
(https://docs.python.org/3/using/windows.html#the-embeddable-package).
socket.getaddrinfo() will encode unicode hostnames using idna and trigger this
error if you call this function in threads:
PS C:\Users\Administrator\Downloads\python-3.7.3-embed-amd64> cat .\repro.py
import threading
import socket
def task():
try:
socket.getaddrinfo('www.google.com', 443)
except Exception as e:
print("FAIL: %s" % e)
raise
threads = []
for i in range(50):
t = threading.Thread(target=task)
threads.append(t)
for t in threads:
t.start()
for t in threads:
t.join()
print("DONE")
PS C:\Users\Administrator\Downloads\python-3.7.3-embed-amd64> .\python.exe
.\repro.py
FAIL: unknown encoding: idna
FAIL: unknown encoding: idna
Exception in thread Thread-5:
Traceback (most recent call last):
File
"D:\obj\Windows-Release\37amd64_Release\msi_python\zip_amd64\threading.py",
line 917, in _bootstrap_inner
File
"D:\obj\Windows-Release\37amd64_Release\msi_python\zip_amd64\threading.py",
line 865, in run
File ".\repro.py", line 7, in task
socket.getaddrinfo('www.google.com', 443)
File "D:\obj\Windows-Release\37amd64_Release\msi_python\zip_amd64\socket.py",
line 748, in getaddrinfo
LookupError: unknown encoding: idna
FAIL: unknown encoding: idna
Exception in thread Thread-4:
Traceback (most recent call last):
File
"D:\obj\Windows-Release\37amd64_Release\msi_python\zip_amd64\threading.py",
line 917, in _bootstrap_inner
File
"D:\obj\Windows-Release\37amd64_Release\msi_python\zip_amd64\threading.py",
line 865, in run
File ".\repro.py", line 7, in task
socket.getaddrinfo('www.google.com', 443)
File "D:\obj\Windows-Release\37amd64_Release\msi_python\zip_amd64\socket.py",
line 748, in getaddrinfo
LookupError: unknown encoding: idna
Exception in thread Thread-6:
Traceback (most recent call last):
File
"D:\obj\Windows-Release\37amd64_Release\msi_python\zip_amd64\threading.py",
line 917, in _bootstrap_inner
File
"D:\obj\Windows-Release\37amd64_Release\msi_python\zip_amd64\threading.py",
line 865, in run
File ".\repro.py", line 7, in task
socket.getaddrinfo('www.google.com', 443)
File "D:\obj\Windows-Release\37amd64_Release\msi_python\zip_amd64\socket.py",
line 748, in getaddrinfo
LookupError: unknown encoding: idna
DONE
Confirmed that adding u''.encode('idna') fixes this issue.
--
nosy: +James.Saryerwinnie
___
Python tracker
<https://bugs.python.org/issue29288>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6700] inspect.getsource() returns incorrect source lines
James Saryerwinnie added the comment:
I confirmed the issue in tip. One of the issues with the original patch is
that it modifies the tokeneater method used by getblock which won't work
if the first token is any of the special cased tokens in the original patch
('@', 'def', 'class'). I've added additional tests that show where the
original patch fails.
An alternative approach is to check in getsourcelines whether or not we're
dealing with a traceback or frame object in the module scope, and if so,
return the lines of the entire module. I've attached an updated patch
that implements this along with additional tests.
--
nosy: +James.Saryerwinnie
Added file: http://bugs.python.org/file30344/issue6700.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6700
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
