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 ned.deily
Recipients Decorater, Marcus.Smith, brett.cannon, dstufft, eric.snow, gregory.p.smith, ncoghlan, ned.deily, njs, paul.moore, pitrou, ronaldoussoren, steve.dower, tim.golden, zach.ware
Date 2017-12-21.20:01:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1513886496.53.0.213398074469.issue32387@psf.upfronthosting.co.za>
In-reply-to
Content
With my macOS hat on, I don't see a problem with doing this.  C extensions built via Distutils have been version-tagged on macOS since 3.5.0 (for some reason, macOS was skipped when PEP 3149 was originally implemented).

With my release manager hat on, it sounds like a good idea.  But it could introduce a compatibility problem for anyone who doesn't use Distutils to produce extension modules.  So I'd like to see this proposal get a little more visibility, at the minimum, bringing it up on the Distutils SIG mailing list.  We should also ensure that the change gets mentioned in the 3.7 What's New document.  And somewhere in the docset there should be some documentation for the .so file name requirements.  AFAICT, today it's really not mentioned anywhere in the docs other than the reference to PEP 3149 in the 3.2 What's New.  Until the packaging documents for extension modules get overhauled perhaps something could be added to the Building chapter of the Extending and Embedding document:
https://docs.python.org/3/extending/building.html#building-c-and-c-extensions
History
Date User Action Args
2017-12-21 20:01:36ned.deilysetrecipients: + ned.deily, brett.cannon, gregory.p.smith, paul.moore, ronaldoussoren, ncoghlan, pitrou, tim.golden, njs, eric.snow, zach.ware, steve.dower, dstufft, Marcus.Smith, Decorater
2017-12-21 20:01:36ned.deilysetmessageid: <1513886496.53.0.213398074469.issue32387@psf.upfronthosting.co.za>
2017-12-21 20:01:36ned.deilylinkissue32387 messages
2017-12-21 20:01:36ned.deilycreate