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:

    spam.cp35m-win_amd64.pyd

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

To be clear, this would mean:

    spam.cp35dm-win_amd64.pyd

instead of

    spam_d.cp35m-win_amd64.pyd