Message160104
| Author | brett.cannon |
|---|---|
| Recipients | Arfrever, brett.cannon, eric.araujo, eric.smith, eric.snow, lemburg, ncoghlan, pitrou, python-dev |
| Date | 2012-05-06.19:05:05 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1336331106.6.0.0390815701026.issue14657@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
I think it's beyond a hint and says we need to find a solution or else other people will run into similar issues. And while I'm thinking about it, there is precedent for exposing modules under a different name than they are actually installed as in the system (e.g. os.path is posixpath), so I don't think we need to bend over backwards to mask every detail if the bootstrap solution is not taken (e.g. if we decided to just paper over _frozen_importlib we don't need to iterate over _frozen_importlib.__dict__ and patch up __module__). But I do think that we need to choose some solution to prevent this "forking" of code in the running interpreter. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2012-05-06 19:05:06 | brett.cannon | set | recipients: + brett.cannon, lemburg, ncoghlan, pitrou, eric.smith, eric.araujo, Arfrever, python-dev, eric.snow |
| 2012-05-06 19:05:06 | brett.cannon | set | messageid: <1336331106.6.0.0390815701026.issue14657@psf.upfronthosting.co.za> |
| 2012-05-06 19:05:06 | brett.cannon | link | issue14657 messages |
| 2012-05-06 19:05:05 | brett.cannon | create | |