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