[issue22980] C extension naming doesn't take bitness into account

Roundup Robot added the comment: New changeset 80fc40a9ae47 by Martin Panter in branch '3.5': Issue #22980: Skip a sysconfig test if _ctypes is not available. https://hg.python.org/cpython/rev/80fc40a9ae47 -- ___ Python tracker

[issue22980] C extension naming doesn't take bitness into account

Larry Hastings added the comment: It's fixed! So it's finally closed. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker

[issue22980] C extension naming doesn't take bitness into account

Roundup Robot added the comment: New changeset 1744d65705d0 by Yury Selivanov in branch '3.5': whatsnew/3.5: Describe changes in issue #22980 https://hg.python.org/cpython/rev/1744d65705d0 New changeset cfbcb3a6a848 by Yury Selivanov in branch 'default': Merge 3.5 (issue #22980, whatsnew/3.5)

[issue22980] C extension naming doesn't take bitness into account

Yury Selivanov added the comment: Larry, Matthias, Steve, Berker - I've mentioned this issue in the whatsnew (applied Larry's patch with some modifications to address comments from Steve and Matthias). Please review. -- ___ Python tracker

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: There's no dot before the debug marker on Windows. Otherwise, looks good to me. Thanks for writing this up. -- ___ Python tracker

[issue22980] C extension naming doesn't take bitness into account

Larry Hastings added the comment: Here's an attempt at a What's New section for this change. I expect it's wrong! Maybe someone can fix it. Maybe it's actually better than not having one at all. Can we maybe get a round or two of edits on this and get something in for 3.5 final?

[issue22980] C extension naming doesn't take bitness into account

Berker Peksag added the comment: Adding Yury since he and Elvis are working on Doc/whatsnew/3.5.rst and they might want to take a look at the latest patch. -- nosy: +berker.peksag, yselivanov ___ Python tracker

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: Only thing I'd add is that the extra tag is optional (on Windows at least), and Python will happily import extensions without it. But extensions with a mismatched tag won't be loaded. -- ___ Python tracker

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: thanks for the draft! I'm not sure how to describe this properly. The extension names are derived from https://wiki.debian.org/Multiarch/Tuples and this again is derived from the GNU triplets/quadruplets. there is no "cpu" and "os" part, depending on the

[issue22980] C extension naming doesn't take bitness into account

Larry Hastings added the comment: I'm leaving this open just because we're apparently waiting on some "What's New" docs. -- ___ Python tracker ___

[issue22980] C extension naming doesn't take bitness into account

Larry Hastings added the comment: I sure hope not. -- nosy: +larry ___ Python tracker ___ ___

[issue22980] C extension naming doesn't take bitness into account

Ned Deily added the comment: I think we should add something to the 3.5 What's New document about these changes and which platforms are affected. Otherwise is there anything left to do before closing? -- priority: normal - deferred blocker ___

[issue22980] C extension naming doesn't take bitness into account

Roundup Robot added the comment: New changeset 558335559383 by doko in branch 'default': - #22980: fix triplet configure test for more targets https://hg.python.org/cpython/rev/558335559383 -- ___ Python tracker rep...@bugs.python.org

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: I'm not trying to discredit any use cases, I just don't see them. so why do you see this on x86 for 32/64bit, but not for ARM soft-float/hard-float. The example given was pretty clear. All Linux distributions I know place the 32-bit and 64-bit versions of

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: I'm not sure I like the way the simple idea Antoine has now resulted in a complete mess across platforms. None of this is documented anywhere except on this ticket. Since the change is a major one for anyone creating installers, packagers or otherwise

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 16.04.2015 18:12, Nick Coghlan wrote: I can tell you exactly where these files need to live side by side: index servers. We currently paper over it on PyPI for Windows and Mac OS X by leveraging the implicitly defined ABI compatibility of the

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: Nick filed issue #23966 to document these changes. Yes, these tags should be documented, so that installers don't have to guess (currently they are only exposed in importlib.machinery.EXTENSION_SUFFIXES. What you describe as a simple idea is just another

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 16.04.2015 17:30, Matthias Klose wrote: Matthias Klose added the comment: Nick filed issue #23966 to document these changes. Yes, these tags should be documented, so that installers don't have to guess (currently they are only exposed in

[issue22980] C extension naming doesn't take bitness into account

Nick Coghlan added the comment: I can tell you exactly where these files need to live side by side: index servers. We currently paper over it on PyPI for Windows and Mac OS X by leveraging the implicitly defined ABI compatibility of the CPython binary releases published on python.org, but

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: On 04/16/2015 05:56 PM, Marc-Andre Lemburg wrote: Marc-Andre Lemburg added the comment: On 16.04.2015 17:30, Matthias Klose wrote: Matthias Klose added the comment: Nick filed issue #23966 to document these changes. Yes, these tags should be

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 16.04.2015 18:53, Matthias Klose wrote: I'm disappointed that you discredit any other use case besides what you think as the typical use case as not real life use case. Maybe you are focused on x86 only, but if you've been to PyCon 2014, you should

[issue22980] C extension naming doesn't take bitness into account

Donald Stufft added the comment: Perhaps you can point me to some use cases where the triple platform tag is really useful. If I understand correctly (and ABI isn't my strong suite), it would be useful in the sense that you could utilize it to create a sort of fat wheel that included the

[issue22980] C extension naming doesn't take bitness into account

Ned Deily added the comment: Antoine's ticket is the first in two decades to request being able to install .so extension files side-by-side, so even if times and platforms change, people don't seem to have a big issues without this feature. That's exactly what PEP 3149 was supposed to

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 16.04.2015 19:44, Donald Stufft wrote: Donald Stufft added the comment: Perhaps you can point me to some use cases where the triple platform tag is really useful. If I understand correctly (and ABI isn't my strong suite), it would be useful in

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 16.04.2015 19:14, Marc-Andre Lemburg wrote: However, for plain .so files that you have on your system (which will mostly like not support more than 2-4 different architecture configurations running at the same time), I don't currently see a need to

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 16.04.2015 19:47, Ned Deily wrote: Ned Deily added the comment: Antoine's ticket is the first in two decades to request being able to install .so extension files side-by-side, so even if times and platforms change, people don't seem to have a big

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 16.04.2015 20:17, Donald Stufft wrote: Donald Stufft added the comment: Well, it's even more wasteful if you have to download 100MB wheels with all the different platforms when the dedicated wheel would just need 1.5MB. I think it's going to

[issue22980] C extension naming doesn't take bitness into account

Changes by Brett Cannon br...@python.org: -- nosy: -brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 16.04.2015 20:21, Ned Deily wrote: Ned Deily added the comment: No, PEP 3149 is about the Python ABI, following PEP 3147, which implements this for PYC files. The intent is to be able to have mutliple *Python* ABI/API versions installed

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 17.04.2015 00:51, Donald Stufft wrote: Since you need special support for such ZIP files (either using dlopen hacks or temporarily extracting them), you might as well deal with the platform dependencies in that handler. No need to force the platform

[issue22980] C extension naming doesn't take bitness into account

Donald Stufft added the comment: Whatever you do, you're still going to force all your main users to download things they don't need, so I don't see the argument of optimizing downloads or caches. pip caches downloads by default, many systems are starting to utilize that cache in order to

[issue22980] C extension naming doesn't take bitness into account

Donald Stufft added the comment: Well, it's even more wasteful if you have to download 100MB wheels with all the different platforms when the dedicated wheel would just need 1.5MB. I think it's going to vary greatly based on how many platforms you're attempting to support and how big your

[issue22980] C extension naming doesn't take bitness into account

Ned Deily added the comment: No, PEP 3149 is about the Python ABI, following PEP 3147, which implements this for PYC files. The intent is to be able to have mutliple *Python* ABI/API versions installed side-by-side, not multiple platform ABI versions :-) Well, for all practical purposes,

[issue22980] C extension naming doesn't take bitness into account

Nick Coghlan added the comment: Matthias's latest patch looks good to me - I'm filing a separate issue about the fact that the native and cross-platform build info isn't really exposed properly at the Python level, and is confusing in various ways. --

[issue22980] C extension naming doesn't take bitness into account

Roundup Robot added the comment: New changeset 11c4f3f936e7 by doko in branch 'default': - Issue #22980: Under Linux, GNU/KFreeBSD and the Hurd, C extensions now include https://hg.python.org/cpython/rev/11c4f3f936e7 -- ___ Python tracker

[issue22980] C extension naming doesn't take bitness into account

Roundup Robot added the comment: New changeset df6c73f0e375 by doko in branch 'default': - #22980: fix typo in Lib/test/test_sysconfig.py triplet test https://hg.python.org/cpython/rev/df6c73f0e375 -- ___ Python tracker rep...@bugs.python.org

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: now fixed on the trunk. opened a new issue #23969 for setting the SOABI on MacOSX. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980

[issue22980] C extension naming doesn't take bitness into account

Roundup Robot added the comment: New changeset 948745d0d9cf by doko in branch 'default': #22980: fix triplet configure test for powerpc-linux-gnu https://hg.python.org/cpython/rev/948745d0d9cf -- ___ Python tracker rep...@bugs.python.org

[issue22980] C extension naming doesn't take bitness into account

Roundup Robot added the comment: New changeset 32c24eec035f by Ned Deily in branch 'default': Issues #22980, 23969: For OS X, use PEP 3149-style file names for extension https://hg.python.org/cpython/rev/32c24eec035f -- ___ Python tracker

[issue22980] C extension naming doesn't take bitness into account

Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: -haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: updated patch and test case. Nick's suggestion to use platform.machine() for the test is wrong. This would test for the environment, not for the just built binary. Try to run a 32bit executable on a 64bit kernel, you'll see x86_64. Same thing with

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: On 04/13/2015 11:43 PM, Nick Coghlan wrote: Nick Coghlan added the comment: Maintaining the arch list can be delegated to the platform maintainers, but I agree a test would be valuable. I'd suggest a test in the platform module tests that cross-checks

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: thought about it, but we only change the SOABI name, and all tests should behave as before. And because we try to load extensions without the SOABI name, there is safe fallback. Still, we should somehow check that a non-empty triplet is included in the

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: here is the more general approach encoding the triplet into the extension name. This is tested with GCC and clang (clang at least on x86_64, x86, powerpc, powerpc64le, arm and aarch64. -- Added file: http://bugs.python.org/file38964/ma.diff

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: here is the more general approach encoding the triplet into the extension name. Thanks. Two comments: - is it possible to avoid the hardcoded list? Maintaining this will be a burden - it would be nice to have a test --

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: On 04/13/2015 11:01 PM, Antoine Pitrou wrote: Antoine Pitrou added the comment: here is the more general approach encoding the triplet into the extension name. Thanks. Two comments: - is it possible to avoid the hardcoded list? Maintaining this will

[issue22980] C extension naming doesn't take bitness into account

Nick Coghlan added the comment: Maintaining the arch list can be delegated to the platform maintainers, but I agree a test would be valuable. I'd suggest a test in the platform module tests that cross-checks the settings in SOABI. This will also be useful in defining an algorithm that

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: @barry, worth updating PEP 3149? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: Ad hoc introduction of the bitness is at least wrong or not helpful for x32 and ARM ilp32. Perhaps it's not helpful for those ABIs / architectures, but I don't see how it's worse than the status quo. -- ___

[issue22980] C extension naming doesn't take bitness into account

Matthias Klose added the comment: I plan to revert this fix and replace it with a more general solution, at least for POSIX based systems. Ad hoc introduction of the bitness is at least wrong or not helpful for x32 and ARM ilp32. (currently at PyCon, and would like to discuss this at the

[issue22980] C extension naming doesn't take bitness into account

Roundup Robot added the comment: New changeset 25356d34b79b by Antoine Pitrou in branch 'default': Issue #22980: Under Linux, C extensions now include bitness in the file name, https://hg.python.org/cpython/rev/25356d34b79b -- ___ Python tracker

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: I've pushed the patch for Linux. I'm keeping this issue open in case other platforms may (want to) benefit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: So, PEP 3149 claims EXT_SUFFIX will always contain the ABI tag, but configure.ac makes it Linux-specific (?!): AC_SUBST(EXT_SUFFIX) case $ac_sys_system in Linux*|GNU*) EXT_SUFFIX=.${SOABI}${SHLIB_SUFFIX};; *)

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: Here is a patch adding the bitness to the ABI tag under Linux. This is permitted by PEP 3149: Python implementations MAY include additional flags in the file name tag as appropriate. -- Added file: http://bugs.python.org/file38155/abi_bitness.patch

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: Could you explain what replacing the _d suffix with a d ABI flag would break ? It breaks consistency with python_d.exe and python35_d.dll, mainly, and those are not going to change (specifically, python.exe and python35.dll are not going to change, and so

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 16.12.2014 05:54, Steve Dower wrote: Nobody seemed too bothered by it, so I committed a slightly simpler change that only includes the most specific tag (that is, .cp35-win32.pyd or .pyd). We can always add another tag easily enough if it seems

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: I justified leaving out the ABI tag in an earlier post as well as in an email to distutils-sig, where two of the PEPs you mention were developed, and nobody had any comment. Cache tags don't include platform information and are worthless here. distutils uses

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 16.12.2014 14:38, Steve Dower wrote: Steve Dower added the comment: I justified leaving out the ABI tag in an earlier post as well as in an email to distutils-sig, where two of the PEPs you mention were developed, and nobody had any comment.

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: get_platform() will be difficult to reuse, for bootstrapping reasons (you need to know the allowed extensions as soon as the interpreter starts up, or at least as soon as the first extension module may be loaded). --

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: get_platform() will be difficult to reuse, for bootstrapping reasons ISTM that if you can't determine the value at compile time, then it doesn't matter to compilation enough to need to appear in the tag. As far as matching PEP 425 for the sake of matching it

Re: [issue22980] C extension naming doesn't take bitness into account

On 16.12.2014 21:28, Steve Dower wrote: Steve Dower added the comment: get_platform() will be difficult to reuse, for bootstrapping reasons ISTM that if you can't determine the value at compile time, then it doesn't matter to compilation enough to need to appear in the tag. Antoine has

[issue22980] C extension naming doesn't take bitness into account

Nick Coghlan added the comment: As far as PEP 425 goes, we handwaved a *lot* in order to be able to improve the user experience of the CPython Windows and Mac OS X binary installers by pairing them up with wheel files on PyPI. That handwaving is the key reason wheels for other platforms are

[issue22980] C extension naming doesn't take bitness into account

Roundup Robot added the comment: New changeset f70c16189876 by Steve Dower in branch 'default': #22980 Adds platform and version tags to .pyd files https://hg.python.org/cpython/rev/f70c16189876 -- nosy: +python-dev ___ Python tracker

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: Nobody seemed too bothered by it, so I committed a slightly simpler change that only includes the most specific tag (that is, .cp35-win32.pyd or .pyd). We can always add another tag easily enough if it seems useful, or roll this change back if it was a mistake.

[issue22980] C extension naming doesn't take bitness into account

STINNER Victor added the comment: Why not using on Windows the same naming scheme than Unix. It may be useful to also add the debug flag (d) in the name for example. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: Why not using on Windows the same naming scheme than Unix. It may be useful to also add the debug flag (d) in the name for example. Windows already puts the debug flag in the name, the fact that it's CPython is in the .pyd extension, and the version number is

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: Windows already puts the debug flag in the name, the fact that it's CPython is in the .pyd extension, and the version number is in the directory for all the standard sys.path locations. The version number would be useful for in-place builds (i.e. when

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: The version number would be useful for in-place builds (i.e. when developping) Ah, I see now how that would be useful (I haven't tried to deal with that before). I'll revise the patch to use/allow the version number. --

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: Added cp35 (and later cp36, etc.) to the tag, so now it looks similar to PEP 425 without the ABI tag (ironically, since there's fundamentally no difference between the Python version and the ABI). cp3 is also accepted for stable ABI extensions that still need a

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: What can I do to help move this along? It sounds like for Windows builds we could change _imp.extension_suffixes() from ['.pyd'] to ['.{}.pyd'.format(distutils.util.get_platform()), '.pyd'] and update distutils to produce the more specific name (I've got some

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: Le 06/12/2014 21:11, Steve Dower a écrit : I suspect any changes here would be completely separate from other platforms, but ISTM that we're looking at a similar change to handle the bitness/debug issue on Linux. I'm not volunteering to do that part :) I

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: The attached patch adds platform tags for .pyd files for win32, win-arm, win-amd64 and win-ia64, which are the known compilers in pyconfig.h and the potential return values from distutils.util.get_platform(). It also fixes a bug where the suffix would be

[issue22980] C extension naming doesn't take bitness into account

New submission from Antoine Pitrou: Currently, C extensions are named something like _helperlib.cpython-34dm.so. This doesn't take into account the bitness of the interpreter (32- vs. 64-bit), which makes it awkward to use the same working copy with two different interpreters (you have to

[issue22980] C extension naming doesn't take bitness into account

Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list

[issue22980] C extension naming doesn't take bitness into account

STINNER Victor added the comment: See also the PEP 3149. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: PEP 3149 says It is not currently clear that the facilities in this PEP are even useful for Windows. Well, it seems I have found a use for it :-) -- ___ Python tracker rep...@bugs.python.org

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: Ideally, we would use distutils.util.get_platform(). However, there are two cases where it relies on other modules: - the re module under CygWin - the sysconfig and _osx_support under OS X Of course, ideally we should be able to hardcode this into the compiled

[issue22980] C extension naming doesn't take bitness into account

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___ ___ Python-bugs-list mailing

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: As a side-note, it is interesting to note that Python currently wrongly identifies 32-bit builds under 64-bit Linux: Python 3.5.0a0 (default:64a54f0c87d7, Nov 2 2014, 17:18:13) [GCC 4.9.1] on linux Type help, copyright, credits or license for more

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: The MULTIARCH variable can help at least under Linux: import sysconfig sysconfig.get_platform() 'linux-x86_64' sysconfig.get_config_var('MULTIARCH') 'i386-linux-gnu' -- ___ Python tracker rep...@bugs.python.org

[issue22980] C extension naming doesn't take bitness into account

STINNER Victor added the comment: There is also platform.architecture(). I don't like its implementation, it relies on the external file program :-( -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980

[issue22980] C extension naming doesn't take bitness into account

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980 ___

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: I'm very much in favor of adding this for .pyds on Windows. I assume the hard part will be getting the details for Linux (doesn't bitness have to be compiled in there? For Windows it can be determined at compile-time...), but preferring an extension with the ABI

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: Note that there's a difference between the platform's architecture (which is what get_platform() returns) and the pointer size of the currently running Python executable. On 64-bit Linux, it's rather rare to have an application built as 32-bit

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: Note that there's a difference between the platform's architecture Yes, that's pointed out above. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: Nothing new should be necessary for pyc files under Windows: Python 3.4.2 |Continuum Analytics, Inc.| (default, Oct 22 2014, 11:51:45) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. import sys

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: I assume the hard part will be getting the details for Linux (doesn't bitness have to be compiled in there? For Windows it can be determined at compile- time...), but preferring an extension with the ABI tag and falling back on one without seems easy

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: I was more interested in source file resolution than bytecode caching. If Python 3.5 would prefer spam.cpython-35.py or spam.cpython-3.py over spam.py and Python 2 preferred spam.py, then I can more easily separate the code that won't parse in the alternative.

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 02.12.2014 19:02, Antoine Pitrou wrote: Sticking to bitness should be easy (although I wonder if it would be desirable for platforms with fat binaries - Ned?). If we can go the extra mile and include platform identification all the better, of course.

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: Fat binaries seem to exist under: - OS X: yes, that's why I was asking for Ned's advice - Linux: A proof-of-concept Ubuntu 9.04 image is available... enough said - DOS: perhaps MicroPython is interested :-) http://en.wikipedia.org/wiki/Fat_binary --

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: But since you pointed out cache-tag, should that distinguish for bitness as well? It seems to be 'cpython-34' for both 32-bit and 64-bit interpreters on Windows, which isn't really a problem now, but may become one if we start allowing/encouraging sharing

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 02.12.2014 19:40, Steve Dower wrote: I was more interested in source file resolution than bytecode caching. If Python 3.5 would prefer spam.cpython-35.py or spam.cpython-3.py over spam.py and Python 2 preferred spam.py, then I can more easily

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: Note that on Linux, 32-bit and 64-bit versions are typically placed into different directory trees By whom? Our standard installer doesn't (it uses ../lib/python-X.Y for all builds). Also, one of the problems (and actually the problem which triggered this

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: @Steve: IIRC, pyc files should be portable, so there's no need to differentiate between various bitnesses. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980

[issue22980] C extension naming doesn't take bitness into account

Steve Dower added the comment: @Antoine: You're right. I hereby withdraw all contributions to this thread after my first statement of support :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22980

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 02.12.2014 19:46, Antoine Pitrou wrote: Note that on Linux, 32-bit and 64-bit versions are typically placed into different directory trees By whom? Our standard installer doesn't (it uses ../lib/python-X.Y for all builds). By the system vendors.

[issue22980] C extension naming doesn't take bitness into account

Antoine Pitrou added the comment: Le 02/12/2014 19:59, Marc-Andre Lemburg a écrit : My main point was that we shouldn't start adding tags for e.g. PPC, Intel, ARM, etc. since platforms needing to support multiple such architectures will typically support fat builds anyway. How about

[issue22980] C extension naming doesn't take bitness into account

Marc-Andre Lemburg added the comment: On 02.12.2014 20:10, Antoine Pitrou wrote: Antoine Pitrou added the comment: Le 02/12/2014 19:59, Marc-Andre Lemburg a écrit : My main point was that we shouldn't start adding tags for e.g. PPC, Intel, ARM, etc. since platforms needing to support

[issue22980] C extension naming doesn't take bitness into account

STINNER Victor added the comment: Would it be possible to add something to the sys module, computed during the compilation, instead of having to rely on platform, sysconfig, struct or something else? Note: There is also the funnny x32 platform project :-) https://sites.google.com/site/x32abi/

[issue22980] C extension naming doesn't take bitness into account

Nick Coghlan added the comment: My initial thought is to add an abitags attribute to sys.implementation (plural so we can also indicate stable ABI support). If we define the algorithm clearly, then setuptools distlib could make it available on earlier Python versions. --

  1   2   >