This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Arfrever, barry, brett.cannon, eric.snow, lemburg, ncoghlan, ned.deily, pitrou, python-dev, steve.dower, tim.golden, vstinner, zach.ware
Date 2014-12-16.21:26:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
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 a point there. Together with the problems I mentioned
with non-mainstream platforms, it would be better to use a compile
time definition of the platform tag as you've chosen for Windows.

PEP 425 unfortunately ignores the mentioned problems of get_platform().

> As far as matching PEP 425 for the sake of matching it goes, I'd rather keep using search path tricks than have ".cp35-cp35m-win_amd64.pyd" appear on every single one of my extension modules. Removing the "_d" suffix is very likely more disruptive than it's worth, especially since untagged pyds are still supported but the debug tag is still necessary. 'm' is always the case in Windows and is benign for a correct extension anyway, and AFAICT 'u' is totally unused.

You may have misread my comment. There's no need to add the Python
tag to the extension tag, only the ABI tag (with flags) and the
platform tag to determine bitness:


Could you explain what replacing the _d suffix with a "d" ABI flag
would break ?

To be clear, this would mean:


instead of

Date User Action Args
2014-12-16 21:26:51lemburgsetrecipients: + lemburg, barry, brett.cannon, ncoghlan, pitrou, vstinner, tim.golden, ned.deily, Arfrever, python-dev, eric.snow, zach.ware, steve.dower
2014-12-16 21:26:51lemburglinkissue22980 messages
2014-12-16 21:26:51lemburgcreate