Brett Cannon wrote: > OK, since no one has really said anything, I am going to assume no one > has issues with importlib in terms of me checking it in or choosing a > name for it (I like importlib more than imp so I will probably stick > with that). > > So I will do some file renaming and reorganization, get the code set > up to be run by regrtest, and then check the code in! I am going to > set PyCon as a hard deadline such that no matter how much more file > churn I have left I will still check it into py3k by then (along with > importlib.import_module() into 2.7). > +1 :-) Michael > On Thu, Jan 8, 2009 at 11:06, Brett Cannon <brett at python.org> wrote: > >> My work rewriting import in pure Python code has reached beta. >> Basically the code is semantically complete and as >> backwards-compatible as I can make it short of widespread testing or >> running on a Windows box. There are still some tweaks here and there I >> want to make and an API to expose, but __import__ works as expected >> when run as the import implementation for all unit tests. >> >> Knowing how waiting for perfection leads to never finishing, I would >> like to start figuring out what it will take to get the code added to >> the standard library of 3.1 with hopes of getting the bootstrapping >> stuff done so that the C implementation of import can go away in 3.1 >> as well. I see basically three things that need to be decided upfront. >> >> One, does anyone have issues if I check in importlib? We have >> typically said code has to have been selected as best-of-breed by the >> community first, so I realize I am asking for a waiver on this one. >> >> Two, what should the final name be? I originally went with importlib >> since this code was developed outside of the trunk, but I can see some >> people suggesting using the imp name. That's fine although that does >> lead to the question of what to do with the current imp. It could be >> renamed _imp, but then that means what is currently named _importlib >> would have to be renamed to something else as well. Maybe >> imp._bootstrap? Plus I always viewed imp as the place where really >> low-level, C-based stuff lived. Otherwise importlib can slowly subsume >> the stuff in imp that is still useful. >> >> Three, there are still some structural changes to the code that I want >> to make. I can hold off on checking in the code until these changes >> are made, but as I said earlier, I know better than to wait forever >> for perfection. >> >> And because I know people will ask: no, I do not plan to backport all >> the code to 2.7. I want this to be a carrot to people to switch to >> 3.x. But I will backport the import_module function I wrote to 2.7 so >> people do have that oft-requested feature since it is a really simple >> bit of Python code. >> >> -Brett >> >> > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4