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 steve.dower
Recipients Arfrever, barry, brett.cannon, eric.snow, lemburg, ncoghlan, ned.deily, pitrou, python-dev, steve.dower, tim.golden, vstinner, zach.ware
Date 2015-01-10.18:29:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1420914592.3.0.0643997714008.issue22980@psf.upfronthosting.co.za>
In-reply-to
Content
> 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 there's no point changing the debug versions any more than with _d).

It would also break consistency with untagged PYDs, which are still supported but still need to distinguish between debug and release builds. Currently the accepted suffixes are "_d.cp35-{plat}.pyd" and "_d.pyd". While we could start requiring at least "cp3d" as the API tag, that would break a lot of development environments for no gain.

So basically, I see compelling reasons for allowing the platform in the name, good enough reasons for the version, but not good enough reasons for changing the existing debug tag (and no reason for the m flag at all).
History
Date User Action Args
2015-01-10 18:29:52steve.dowersetrecipients: + steve.dower, lemburg, barry, brett.cannon, ncoghlan, pitrou, vstinner, tim.golden, ned.deily, Arfrever, python-dev, eric.snow, zach.ware
2015-01-10 18:29:52steve.dowersetmessageid: <1420914592.3.0.0643997714008.issue22980@psf.upfronthosting.co.za>
2015-01-10 18:29:52steve.dowerlinkissue22980 messages
2015-01-10 18:29:51steve.dowercreate