[issue43745] ssl.OPENSSL_VERSION still reporting 1.1.1i on windows 3.8.9/3.9.4
Bill Collins added the comment: Confirmed, thanks! -- ___ Python tracker <https://bugs.python.org/issue43745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43745] ssl.OPENSSL_VERSION still reporting 1.1.1i on windows 3.8.9/3.9.4
Bill Collins added the comment: The embeddable dists for 3.9.4 have updated, but the 3.8.9 packages are still showing the builds from April 2nd. -- ___ Python tracker <https://bugs.python.org/issue43745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43745] ssl.OPENSSL_VERSION still reporting 1.1.1i on windows 3.8.9/3.9.4
Bill Collins added the comment: Thanks for the quick action on this! I've downloaded the new 3.8.9/3.9.4 installers, but they are unable to run over my existing 3.8.9/3.9.4 installs; "Unable to install python 3.9.4 (64-bit) due to an existing install." This is probably fine as I can just uninstall/reinstall (I hope), so just FYI. I've upgraded my 32-bit install from 3.9.2 to the new 3.9.4 installer without issue. Are you able to also update the embeddable packages please? -- ___ Python tracker <https://bugs.python.org/issue43745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43745] ssl.OPENSSL_VERSION still reporting 1.1.1i on windows 3.8.9/3.9.4
New submission from Bill Collins : >>> import sys,ssl >>> sys.version '3.9.4 (tags/v3.9.4:1f2e308, Apr 4 2021, 13:27:16) [MSC v.1928 64 bit (AMD64)]' >>> ssl.OPENSSL_VERSION 'OpenSSL 1.1.1i 8 Dec 2020' I may well be holding it wrong, but something seems off. -- components: Windows messages: 390303 nosy: Bill Collins, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: ssl.OPENSSL_VERSION still reporting 1.1.1i on windows 3.8.9/3.9.4 type: security versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37654] 2to3 no-ops on embeddable distribution
New submission from Bill Collins : Firstly, I'd acknowledge that expecting 2to3 to work on the embeddable distribution might be the problem, but the mode of failure is silent and delayed. The problem is that 2to3 loads fix names by searching for files in a package that end in '.py' (https://github.com/python/cpython/blame/master/Lib/lib2to3/refactor.py#L30) which isn't much use on the embeddable distribution where everything is pre-comipled. So, installing an sdist package that relies on 2to3 will succeed, but any attempt to then actually use the installed package will fail. I'm not sure whether the correct behavior here might be to 1. Fix 2to3 to load from pyc files (explicitly enabling 2to3 based installation on embeddable) 2. Fix 2to3 to fail when no converters are found (or similar; explicitly *disabling* 2to3 based installation on embeddable). Or something else entirely. -- components: 2to3 (2.x to 3.x conversion tool) messages: 348304 nosy: Bill Collins priority: normal severity: normal status: open title: 2to3 no-ops on embeddable distribution type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37641] Embeddable distribution pyc filenames show build machine location
New submission from Bill Collins : pyc files within the embeddable zip are compiled with their filename as the temporary directory in which they are compiled. Thus, stack traces will appear as (e.g.) D:\obj\windows-release\37win32_Release\msi_python\zip_win32\image.py, which is a little surprising and not obvious that it's actually from email/mime/image.py. We currently work around this by updating the pyc files before shipping to be relative paths to Lib/; however, fixing this upstream would appear to be as simple as passing through the dest from _write_to_zip to _py_temp_compile (https://github.com/python/cpython/blob/21a92f8cda525d25a165b773fbe1bfffd303a000/PC/layout/main.py#L302) to be passed into _compile_one_py -- components: Build, Installation, Windows messages: 348235 nosy: Bill Collins, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Embeddable distribution pyc filenames show build machine location type: enhancement versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37641> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
