[Python-Dev] Re: Structural pattern matching and mangling private names
Daniel Moisset wrote: > I might expect that in a "case D(something=__y)" you get the mangling for > __y, but I'm not sure what the implementation does now and I'm writing from > my phone Yes - that case does what you'd expect. Thanks for the reply. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3BALIBTV3ATAEC6G5ZJKAFBASZG4B5AP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Structural pattern matching and mangling private names
I don't remember this topic ever being discussed, but still I wouldn't expect that __something to be mangled, given that it refers to an attribute of an instance of D. I might expect that in a "case D(something=__y)" you get the mangling for __y, but I'm not sure what the implementation does now and I'm writing from my phone On Wed, 15 Jun 2022, 20:12 , wrote: > For this code: > > class C: > def f(self, x): > match x: > case D(__something=y): > return y > > It appears that the name "__something" isn't mangled. Under most other > circumstances I'd expect this to be mangled to "_C__something". Is this: > * intentional, > * accidental, but how that it's done it's the defined behaviour, > * or a defect? > > It doesn't seem like it's explicitly tested for in test_patma.py either > way. > > Thanks > David > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/LILLO3MBTVY6ZQT3VNUVXATEPS3ASGQF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/335CR2QTKIP6DLVDCIEAGRKKQW6EU6WK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Structural pattern matching and mangling private names
For this code: class C: def f(self, x): match x: case D(__something=y): return y It appears that the name "__something" isn't mangled. Under most other circumstances I'd expect this to be mangled to "_C__something". Is this: * intentional, * accidental, but how that it's done it's the defined behaviour, * or a defect? It doesn't seem like it's explicitly tested for in test_patma.py either way. Thanks David ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LILLO3MBTVY6ZQT3VNUVXATEPS3ASGQF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] IMPORTANT: Python 3.11.0b4 is blocked
Hi everyone, Today we are supposed to release Python3.11.0b4 but unfortunately, we have a bunch of release blockers: https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+label%3Arelease-blocker+label%3A3.11+ Please, if you are involved in the above issues check if they are resolved or if they are not released blockers. If they are not release blockers or you think we should defer them, please comment on why on the issue. Also, please, notice that the final decision to defer or not a blocker is made by the release management team. If you have some time to investigate, that will help a lot! Please, add me as a reviewer to any PR that needs to be merged to address these issues. Thanks for your help! Regards from sunny London, Pablo Galindo Salgado ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ORCYBRP432J36LXP32IDX6KLRE7Z646V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Python-Help] Unable to bootstrap Python 3 install
-cc:help (bcc) FWIW the thing to do to move this forward is to open a new PR. Patches attached to an email are lost like tears in the rain. What you describe of cross compilation where host and target triples appear the same but use different libraries is a valid cross compilation case. But doesn't surprise me that there are bugs given most people never have such a setup. Even in an "every build should be a cross build" world (which we sadly don't have) it being broken may not show up. -gps On Wed, Jun 15, 2022 at 8:28 AM Victor Stinner wrote: > Hi, > > While this problem is causing you a lot of troubles, I never had to > cross compile Python, and I guess that it's the case for most people. > Changing the Python build system and distutils is stressful since it > can break Python for the majority of users, rather than leaving the > minority of users with an old bug. So far, nobody was brave enough to > "break" the system for cross compilation. > > Moreover, as far as I know, cross compiling Python works for the > common case: different platform triplet. Only the corner case of the > same triple is causing troubles. > > https://github.com/python/cpython/issues/66913 doesn't explain how to > reproduce the issue, it only gives some info about what doesn't work. > I don't know how to reproduce the issue. Please comment the issue. > > To cross compile Python, I found these documentations: > > * https://docs.python.org/dev/using/configure.html#cross-compiling-options > * WASM: https://github.com/python/cpython/blob/main/Tools/wasm/README.md > > Currently, setup.py checks for: > > CROSS_COMPILING = ("_PYTHON_HOST_PLATFORM" in os.environ) > > Victor > > > On Tue, Jun 14, 2022 at 1:49 AM Dave Blanchard wrote: > > Here's what's happening. This is a very old problem reported ages ago > which has never been fixed. If I set the target arch to i686 (on an x86_64 > build system) Python will cross-compile and bootstrap just fine. But if the > host and build triple are the same, then the problem will occur. Python > seems to be ASSuming that if the build and host triple match (in this case, > both being 'x86_64-linux-gnu') therefore the host and build libraries are > binary-compatible--which is NOT actually the case when one is > cross-compiling to a different libc, for example. Actually it's kind of > brain dead how this is implemented. > > > > Some prior discussions/years-old bug reports: > > > > https://bugs.python.org/issue39399 > > https://bugs.python.org/issue22724 > > https://bugs.gentoo.org/705970 > > > > In those links, various hacks are attempted with various degrees of > success, but then Xavier de Gaye reworked the build system, apparently > fixing the problem with this pull request in Dec. 2019: > > > > https://github.com/python/cpython/pull/17420 > > > > Unfortunately he became annoyed in the comments, seemingly mostly due to > the lack of interest from Python to actually do anything about this > problem, and cancelled his pull request. His fix was never implemented, and > Python cross-compiling remains broken to this day. > > > > I downloaded his patches, made a minor fix or two, and merged them all > together into the one patch attached to this email. When applied to both my > build system and target Python, this problem seems to be resolved, for me > at least. I'll know more later tonight as I get further into the distro > build process. > > > > It's surprising to hear that cross-compiling Python would be any kind of > "unusual" thing, considering this is something that *always* has to be done > any time one is bootstrapping anything on a new or different system. It > surprises me further to see that Python actually requires the *minor* > version number to be the same for bootstrapping, also. So not only is > Python 3 essentially a different language from Python 2, each point release > is different and incompatible also. Amazing. > > > > I guess this shouldn't be surprising, after all of the other > questionable design decisions this project has made over the years. I > probably also shouldn't be surprised to see such an incredibly important > bug going unfixed after all this time. It's Python--by far the #1 biggest > annoyance and pain in the ass out of the 1,000+ packages on my distro, > ranking just above CUPS and Texlive. > > > > Dave > > > > > > On Mon, 13 Jun 2022 16:12:26 -0500 (CDT) > > Matthew Dixon Cowles wrote: > > > > > Dear Dave, > > > > > > > Hello, I'm trying to cross compile a new version of my Linux system > > > > with some upgraded packages, including a new Glibc. > > > > > > I've never had to do that and I am beginning to suspect, from the > > > lack of replies here better than this one, that nobody else here has > > > had to either. > > > > > > > I've hit a major snag with Python 3.7 (also tried 3.9 with same > > > > result) which makes it through the compile OK, but then bombs when > > > > running ensurepip at the end. > > > > > > If it were me, I'd set --with-ensurepip to no, d
[Python-Dev] Re: [Python-Help] Unable to bootstrap Python 3 install
Hi, While this problem is causing you a lot of troubles, I never had to cross compile Python, and I guess that it's the case for most people. Changing the Python build system and distutils is stressful since it can break Python for the majority of users, rather than leaving the minority of users with an old bug. So far, nobody was brave enough to "break" the system for cross compilation. Moreover, as far as I know, cross compiling Python works for the common case: different platform triplet. Only the corner case of the same triple is causing troubles. https://github.com/python/cpython/issues/66913 doesn't explain how to reproduce the issue, it only gives some info about what doesn't work. I don't know how to reproduce the issue. Please comment the issue. To cross compile Python, I found these documentations: * https://docs.python.org/dev/using/configure.html#cross-compiling-options * WASM: https://github.com/python/cpython/blob/main/Tools/wasm/README.md Currently, setup.py checks for: CROSS_COMPILING = ("_PYTHON_HOST_PLATFORM" in os.environ) Victor On Tue, Jun 14, 2022 at 1:49 AM Dave Blanchard wrote: > Here's what's happening. This is a very old problem reported ages ago which > has never been fixed. If I set the target arch to i686 (on an x86_64 build > system) Python will cross-compile and bootstrap just fine. But if the host > and build triple are the same, then the problem will occur. Python seems to > be ASSuming that if the build and host triple match (in this case, both being > 'x86_64-linux-gnu') therefore the host and build libraries are > binary-compatible--which is NOT actually the case when one is cross-compiling > to a different libc, for example. Actually it's kind of brain dead how this > is implemented. > > Some prior discussions/years-old bug reports: > > https://bugs.python.org/issue39399 > https://bugs.python.org/issue22724 > https://bugs.gentoo.org/705970 > > In those links, various hacks are attempted with various degrees of success, > but then Xavier de Gaye reworked the build system, apparently fixing the > problem with this pull request in Dec. 2019: > > https://github.com/python/cpython/pull/17420 > > Unfortunately he became annoyed in the comments, seemingly mostly due to the > lack of interest from Python to actually do anything about this problem, and > cancelled his pull request. His fix was never implemented, and Python > cross-compiling remains broken to this day. > > I downloaded his patches, made a minor fix or two, and merged them all > together into the one patch attached to this email. When applied to both my > build system and target Python, this problem seems to be resolved, for me at > least. I'll know more later tonight as I get further into the distro build > process. > > It's surprising to hear that cross-compiling Python would be any kind of > "unusual" thing, considering this is something that *always* has to be done > any time one is bootstrapping anything on a new or different system. It > surprises me further to see that Python actually requires the *minor* version > number to be the same for bootstrapping, also. So not only is Python 3 > essentially a different language from Python 2, each point release is > different and incompatible also. Amazing. > > I guess this shouldn't be surprising, after all of the other questionable > design decisions this project has made over the years. I probably also > shouldn't be surprised to see such an incredibly important bug going unfixed > after all this time. It's Python--by far the #1 biggest annoyance and pain in > the ass out of the 1,000+ packages on my distro, ranking just above CUPS and > Texlive. > > Dave > > > On Mon, 13 Jun 2022 16:12:26 -0500 (CDT) > Matthew Dixon Cowles wrote: > > > Dear Dave, > > > > > Hello, I'm trying to cross compile a new version of my Linux system > > > with some upgraded packages, including a new Glibc. > > > > I've never had to do that and I am beginning to suspect, from the > > lack of replies here better than this one, that nobody else here has > > had to either. > > > > > I've hit a major snag with Python 3.7 (also tried 3.9 with same > > > result) which makes it through the compile OK, but then bombs when > > > running ensurepip at the end. > > > > If it were me, I'd set --with-ensurepip to no, declare victory, and > > run ensurepip on the target machine. > > > > I haven't been able to find any very good evidence, but I wouldn't be > > surprised if the option to turn ensurepip off is there to help out > > with cross-compiling. For example, here it's being turned off for > > compiling to web assembly: > > > > https://t.ly/_ZE3 > > > > (alternatively: > > > > https://github.com/python/cpython/commit/ > > 9deb83468c56c7484645e6e3a6d0183cd6a0afd7 > > > > ) > > > > which looks to me a lot like what you're doing. > > > > What seems to be happening is that in Lib/esurepip/__init__.py is > > calling run_module() in Lib/runpy.py and that's calling >