From ericsnowcurrently at gmail.com Wed May 28 06:54:50 2014 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Tue, 27 May 2014 22:54:50 -0600 Subject: [Import-SIG] importlib2 Message-ID: Hi all, Motivated at PyCon by the "pymigrate" discussions, I started backporting importlib to 2.7. I've finally freed up some time in the last week or so and have come close to having the project ready to release on the cheeseshop (as importlib2). I'm hosting the repo and bug tracker on bitbucket: https://bitbucket.org/ericsnowcurrently/importlib2 Feel free to take it for a spin. Keep in mind that any functionality that depends on the no-longer-implicit import state (finders/path hooks) will not work without first calling importlib2.hook.inject(). That includes importlib2.import_module(). If you notice any other rough corners just let me know. There are a few minor things I want to wrap up before officially releasing the project, but that shouldn't take much work. In parallel I'm going to start working on the pymigrate* project, which will leverage importlib2 and importers to facilitate per-module enforcement of the 2.7/3.x intersection language. Lastly, I can never offer enough thanks to Brett Cannon for importlib and its thorough test suite. It's made the backporting job possible (and almost easy). Thanks Brett! -eric * Go go gadget bikeshed! From ncoghlan at gmail.com Wed May 28 11:06:24 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 28 May 2014 19:06:24 +1000 Subject: [Import-SIG] importlib2 In-Reply-To: References: Message-ID: On 28 May 2014 14:55, "Eric Snow" wrote: > > Hi all, > > Motivated at PyCon by the "pymigrate" discussions, I started > backporting importlib to 2.7. I've finally freed up some time in the > last week or so and have come close to having the project ready to > release on the cheeseshop (as importlib2). I'm hosting the repo and > bug tracker on bitbucket: > > https://bitbucket.org/ericsnowcurrently/importlib2 Awesome! > Feel free to take it for a spin. Keep in mind that any functionality > that depends on the no-longer-implicit import state (finders/path > hooks) will not work without first calling importlib2.hook.inject(). > That includes importlib2.import_module(). If you notice any other > rough corners just let me know. > > There are a few minor things I want to wrap up before officially > releasing the project, but that shouldn't take much work. In parallel > I'm going to start working on the pymigrate* project, which will > leverage importlib2 and importers to facilitate per-module enforcement > of the 2.7/3.x intersection language. Yeah, that's going to be a pretty significant project (in both senses of the word). Thanks for taking the initiative to get it moving! Cheers, Nick. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcannon at gmail.com Wed May 28 15:44:06 2014 From: bcannon at gmail.com (Brett Cannon) Date: Wed, 28 May 2014 13:44:06 +0000 Subject: [Import-SIG] importlib2 References: Message-ID: On Wed May 28 2014 at 12:55:00 AM, Eric Snow wrote: > Hi all, > > Motivated at PyCon by the "pymigrate" discussions, I started > backporting importlib to 2.7. I've finally freed up some time in the > last week or so and have come close to having the project ready to > release on the cheeseshop (as importlib2). I'm hosting the repo and > bug tracker on bitbucket: > > https://bitbucket.org/ericsnowcurrently/importlib2 > > Feel free to take it for a spin. Keep in mind that any functionality > that depends on the no-longer-implicit import state (finders/path > hooks) will not work without first calling importlib2.hook.inject(). > That includes importlib2.import_module(). If you notice any other > rough corners just let me know. > > There are a few minor things I want to wrap up before officially > releasing the project, but that shouldn't take much work. In parallel > I'm going to start working on the pymigrate* project, which will > leverage importlib2 and importers to facilitate per-module enforcement > of the 2.7/3.x intersection language. > You'll have to refresh my memory because there were a lot of ideas tossed out at PyCon: why an importer and not some custom rules for pylint? E.g. I can see requiring that either ``from __future__ import unicode_literals`` or every string literal being marked with u or b being a rule, but I don't see the exact benefit of that over an importer (I realize that a per-file thing is desired, but tooling for that should be possible as well). Anyway, this discussion should probably happen on the python-porting list since that's the audience more interested in this topic. =) > > Lastly, I can never offer enough thanks to Brett Cannon for importlib > and its thorough test suite. It's made the backporting job possible > (and almost easy). Thanks Brett! > Glad it helped someone else out! If I ever needed a personal example of why testing is important, importlib is it (there has been hardly any bugs about importlib which still continues to astound me). -Brett > -eric > > * Go go gadget bikeshed! > _______________________________________________ > Import-SIG mailing list > Import-SIG at python.org > https://mail.python.org/mailman/listinfo/import-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericsnowcurrently at gmail.com Wed May 28 16:19:59 2014 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Wed, 28 May 2014 08:19:59 -0600 Subject: [Import-SIG] importlib2 In-Reply-To: References: Message-ID: On Wed, May 28, 2014 at 7:44 AM, Brett Cannon wrote: > You'll have to refresh my memory because there were a lot of ideas tossed > out at PyCon: why an importer and not some custom rules for pylint? E.g. I > can see requiring that either ``from __future__ import unicode_literals`` or > every string literal being marked with u or b being a rule, but I don't see > the exact benefit of that over an importer (I realize that a per-file thing > is desired, but tooling for that should be possible as well). To be honest, I don't remember exactly. Maybe a linter would be sufficient, though I could swear there was some reason it wasn't. I'll consider that. > > Anyway, this discussion should probably happen on the python-porting list > since that's the audience more interested in this topic. =) I was actually going to take it over to python-ideas (or python-dev) considering the possible impact of the tool. I hadn't even thought about python-porting. That will be a good place to start. :) -eric From ncoghlan at gmail.com Wed May 28 16:41:54 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 29 May 2014 00:41:54 +1000 Subject: [Import-SIG] importlib2 In-Reply-To: References: Message-ID: On 29 May 2014 00:19, Eric Snow wrote: > On Wed, May 28, 2014 at 7:44 AM, Brett Cannon wrote: >> You'll have to refresh my memory because there were a lot of ideas tossed >> out at PyCon: why an importer and not some custom rules for pylint? E.g. I >> can see requiring that either ``from __future__ import unicode_literals`` or >> every string literal being marked with u or b being a rule, but I don't see >> the exact benefit of that over an importer (I realize that a per-file thing >> is desired, but tooling for that should be possible as well). > > To be honest, I don't remember exactly. Maybe a linter would be > sufficient, though I could swear there was some reason it wasn't. > I'll consider that. IIRC, it came out of one of our conversation with Steve Dower, and it was more a matter of "do both" rather than one or the other. The other advantage of the runtime model was being able to turn on -3 warnings. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia