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 ncoghlan
Recipients brett.cannon, eric.snow, mikekap, ncoghlan
Date 2016-10-25.02:24:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1477362294.63.0.0858394776446.issue26388@psf.upfronthosting.co.za>
In-reply-to
Content
Ah, very nice. (And no worries on taking an as-you-have-time approach to this - you'll see from the dates on some of the referenced issues below that even I'm in that situation where runpy is concerned)

I think you're right that offering a 2-phase load/run API will make a lot of sense to folks already familiar with the find/exec model for imports, and it also aligns with this old design concept for making runpy friendlier to modules that need access to the created globals even if the execution step fails: http://bugs.python.org/issue9325#msg133833

I'd just completely missed that that idea was potentially relevant here as well :)

I'll provide a few more detailed comments inline.

The scale of the refactoring does make me wonder if there might be a way to account for the "target module" idea in http://bugs.python.org/issue19982 though.
History
Date User Action Args
2016-10-25 02:24:54ncoghlansetrecipients: + ncoghlan, brett.cannon, eric.snow, mikekap
2016-10-25 02:24:54ncoghlansetmessageid: <1477362294.63.0.0858394776446.issue26388@psf.upfronthosting.co.za>
2016-10-25 02:24:54ncoghlanlinkissue26388 messages
2016-10-25 02:24:52ncoghlancreate