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 martin.panter
Recipients Alex.Willmer, bennykj, doko, martin.panter, xdegaye, yan12125, zach.ware
Date 2016-10-18.02:28:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1476757694.03.0.408248671545.issue28444@psf.upfronthosting.co.za>
In-reply-to
Content
Well, I am not really an expert on the setup.py stuff, but I will ask a question anyway that may help the review process: Why do you remove the code that loops over Modules/Setup? Maybe is it redundant with the other code for removing the already-built-in modules?

Looking at the repository history, the code for avoiding already-built-in modules was first added as part of revision c503fa9b265e; see the __import__() call. Later, the second chunk of code looping over Setup was added in revision 90e90c92198b, with discussion at <https://marc.info/?i=E14WL9X-0000cP-00@usw-sf-web3.sourceforge.net>.

The logic matching MODOBJS doesn’t look super robust. E.g. I suspect it will get confused if there are two Python modules that happen to use the same C filename in different subdirectories. Also, I suspect it could get confused by _math.c, which is shared by the “math” and “cmath” modules.

Perhaps I don’t know what I am talking about, but if you added Modules/Setup.config to the list of Setup files to process, would that eliminate the need to look at both MODOBJS and sys.builtin_module_names?
History
Date User Action Args
2016-10-18 02:28:14martin.pantersetrecipients: + martin.panter, doko, xdegaye, zach.ware, Alex.Willmer, yan12125, bennykj
2016-10-18 02:28:14martin.pantersetmessageid: <1476757694.03.0.408248671545.issue28444@psf.upfronthosting.co.za>
2016-10-18 02:28:13martin.panterlinkissue28444 messages
2016-10-18 02:28:12martin.pantercreate