On Sat, Mar 5, 2011 at 3:19 AM, "Martin v. Löwis" <mar...@v.loewis.de> wrote: >> Experimenting with this idea became significantly more feasible since >> Brett wrote importlib, but would still require a strong understanding >> of Python's import system. I suspect even a proof of concept that was >> tested against just filesystem imports and zipimport would prove quite >> tricky. > > That, of course, makes it a difficult GSoC project. Ideally, the student > should have a clear vision of what needs to be done. Failing that, the > mentor should have a clear vision, and would then need frequent > communication with the student.
I have a reasonably clear vision of what I would like to see. I'm just not sure if some of the assumptions underlying PEP 302 will make it unworkable in practice given the current conventions (e.g. there is a *lot* of code that accesses sys.modules directly. Accommodating such code without modification would require some reasonably fancy footwork with either thread local storage or stack frame inspection). If the issues can't be worked around via TLS or frame inspection, I suspect several of the PEP 302 interfaces would need to be modified to make the system work with arbitrary importers and loaders, but actually implementing something based on importlib (or a fork, if it turns out interfaces need to change) would be the best way to find out. I'm a little confused by the http://wiki.python.org/moin/SummerOfCode/2011 page though. If I'm a *member* of an approved project (CPython in this case), can I just add an entry to the table? Or do I need to do something first to be approved as a prospective mentor? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
