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 brett.cannon
Recipients Arfrever, brett.cannon, eric.smith, eric.snow, lemburg, ncoghlan, pitrou
Date 2012-04-24.15:10:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1335280219.42.0.834697229717.issue14657@psf.upfronthosting.co.za>
In-reply-to
Content
To start, I'm *not* going to make the final call on this issue's solution. I'm inches away from importlib burnout and general integration frustration with trying to clean up the implicit behaviour. So to prevent me from making a bad decision I will you guys make the final call.

Anyway, I see two options here. One is the "let _frozen_importlib be *the* implementation, period" argument put forth by Antoine (MAL's "freeze everything" also falls under this since it suffers from the same issues). This is the easiest solution for the issue of not having overlapping implementations and cause potential mix-ups, etc. The issue becomes development difficulty goes up as now you are adding a compile step where if you screw up you can get really bad error messages (e.g. "standard streams could not be created" kind of stuff). This could theoretically be overcome if the importlib tests all used a manually created module directly from the source code to verify things before rebuilding (as well as making sure sys.path_importer_cache was cleaned out). With a restructuring of importlib's tests to use a common TestCase with the proper setUp()/teardown() for keeping things clean along with class and module fixtures to prevent obscene stuff like re-importing for every test method. Another option is we hide the source as _importlib or something to allow direct importation w/o any tricks under a protected name.

Then there is Nick's proposal of using _frozen_importlib to start up and then swap out with a new version created from the source during startup. This keeps development simple since the tests run against the code *almost* all other code will use and thus eliminate the test. The problem here is that startup is a smidgen slower and it requires you blacklist what needs to get swapped out and if you mess up that will be tough to debug as well.

Both get the same outcome but with different approaches, it's just a question of which one is easiest to maintain.
History
Date User Action Args
2012-04-24 15:10:19brett.cannonsetrecipients: + brett.cannon, lemburg, ncoghlan, pitrou, eric.smith, Arfrever, eric.snow
2012-04-24 15:10:19brett.cannonsetmessageid: <1335280219.42.0.834697229717.issue14657@psf.upfronthosting.co.za>
2012-04-24 15:10:18brett.cannonlinkissue14657 messages
2012-04-24 15:10:18brett.cannoncreate