From jergosh at gmail.com Thu Sep 15 09:41:36 2011 From: jergosh at gmail.com (Greg Slodkowicz) Date: Thu, 15 Sep 2011 09:41:36 +0200 Subject: [Import-SIG] New PEP draft: "Simplified Package Layout and Partitioning" In-Reply-To: <20110824131856.7D7AF3A4114@sparrow.telecommunity.com> References: <20110713171345.4E0673A4100@sparrow.telecommunity.com> <20110718121726.123e5b44@resist.wooz.org> <20110721163700.3daff988@resist.wooz.org> <20110815234422.DAA243A4105@sparrow.telecommunity.com> <20110816213116.8FE063A409E@sparrow.telecommunity.com> <20110824131856.7D7AF3A4114@sparrow.telecommunity.com> Message-ID: > By the way, do any of your tests make sys.path changes and check whether > virtual packages' __path__ attributes are updated accordingly? Good point, I should add some tests for that. Sorry for not replying earlier but my semester has started already and I was occupied with courses. -Greg From ericsnowcurrently at gmail.com Wed Sep 21 21:06:22 2011 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Wed, 21 Sep 2011 13:06:22 -0600 Subject: [Import-SIG] improving ImportError Message-ID: Armin Ronacher has an interesting blog post about some of the challenges of using Python's imports: http://lucumr.pocoo.org/2011/9/21/python-import-blackbox/ In particular, his main point about "not found" vs. "broken" vs. "problem with inner import" got me thinking. Would it be a bad idea to split ImportError into more specific exceptions? I imagine that cataloguing the different causes of ImportError and how someone might react to those differently wouldn't be too hard... -eric From brett at python.org Wed Sep 21 21:59:36 2011 From: brett at python.org (Brett Cannon) Date: Wed, 21 Sep 2011 12:59:36 -0700 Subject: [Import-SIG] improving ImportError In-Reply-To: References: Message-ID: On Wed, Sep 21, 2011 at 12:06, Eric Snow wrote: > Armin Ronacher has an interesting blog post about some of the > challenges of using Python's imports: > > http://lucumr.pocoo.org/2011/9/21/python-import-blackbox/ > > In particular, his main point about "not found" vs. "broken" vs. > "problem with inner import" got me thinking. Would it be a bad idea > to split ImportError into more specific exceptions? I imagine that > cataloguing the different causes of ImportError and how someone might > react to those differently wouldn't be too hard... > Without reading the blog post, granularity never hurt. But first thing is first, I need to get an attribute or two on ImportError to help identify what has gone wrong: http://bugs.python.org/issue1559549 . -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.m.bray at gmail.com Wed Sep 21 22:43:32 2011 From: erik.m.bray at gmail.com (Erik Bray) Date: Wed, 21 Sep 2011 16:43:32 -0400 Subject: [Import-SIG] improving ImportError In-Reply-To: References: Message-ID: On Wed, Sep 21, 2011 at 3:06 PM, Eric Snow wrote: > Armin Ronacher has an interesting blog post about some of the > challenges of using Python's imports: > > http://lucumr.pocoo.org/2011/9/21/python-import-blackbox/ > > In particular, his main point about "not found" vs. "broken" vs. > "problem with inner import" got me thinking. ?Would it be a bad idea > to split ImportError into more specific exceptions? ?I imagine that > cataloguing the different causes of ImportError and how someone might > react to those differently wouldn't be too hard... > > -eric I agree, more granularity would be good. Would these additional exceptions be subclasses of ImportError? It would be useful to be able to start with just ImportError but then do different things for ModuleNotFound as opposed to an import error due to a deeper exception, perhaps with an easy way to access the original exception that caused the ImportError as an attribute of the ImportError. Erik From brett at python.org Wed Sep 21 23:16:05 2011 From: brett at python.org (Brett Cannon) Date: Wed, 21 Sep 2011 14:16:05 -0700 Subject: [Import-SIG] improving ImportError In-Reply-To: References: Message-ID: On Wed, Sep 21, 2011 at 13:43, Erik Bray wrote: > On Wed, Sep 21, 2011 at 3:06 PM, Eric Snow > wrote: > > Armin Ronacher has an interesting blog post about some of the > > challenges of using Python's imports: > > > > http://lucumr.pocoo.org/2011/9/21/python-import-blackbox/ > > > > In particular, his main point about "not found" vs. "broken" vs. > > "problem with inner import" got me thinking. Would it be a bad idea > > to split ImportError into more specific exceptions? I imagine that > > cataloguing the different causes of ImportError and how someone might > > react to those differently wouldn't be too hard... > > > > -eric > > I agree, more granularity would be good. Would these additional > exceptions be subclasses of ImportError? They would have to be or this is a non-starter. > It would be useful to be > able to start with just ImportError but then do different things for > ModuleNotFound as opposed to an import error due to a deeper > exception, perhaps with an easy way to access the original exception > that caused the ImportError as an attribute of the ImportError. Python 3 already can chain exceptions (both explicitly and implicitly). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericsnowcurrently at gmail.com Thu Sep 22 00:12:14 2011 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Wed, 21 Sep 2011 16:12:14 -0600 Subject: [Import-SIG] improving ImportError In-Reply-To: References: Message-ID: On Wed, Sep 21, 2011 at 1:59 PM, Brett Cannon wrote: > Without reading the blog post, granularity never hurt. But first thing is > first, I need to get an attribute or ?two on ImportError to help identify > what has gone wrong:?http://bugs.python.org/issue1559549?. Forgot about that one. Sounds good. -eric From ncoghlan at gmail.com Thu Sep 22 01:50:42 2011 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 22 Sep 2011 09:50:42 +1000 Subject: [Import-SIG] improving ImportError In-Reply-To: References: Message-ID: On Thu, Sep 22, 2011 at 7:16 AM, Brett Cannon wrote: > On Wed, Sep 21, 2011 at 13:43, Erik Bray wrote: >> >> On Wed, Sep 21, 2011 at 3:06 PM, Eric Snow >> wrote: >> > Armin Ronacher has an interesting blog post about some of the >> > challenges of using Python's imports: >> > >> > http://lucumr.pocoo.org/2011/9/21/python-import-blackbox/ >> > >> > In particular, his main point about "not found" vs. "broken" vs. >> > "problem with inner import" got me thinking. ?Would it be a bad idea >> > to split ImportError into more specific exceptions? ?I imagine that >> > cataloguing the different causes of ImportError and how someone might >> > react to those differently wouldn't be too hard... >> > >> > -eric >> >> I agree, more granularity would be good. ?Would these additional >> exceptions be subclasses of ImportError? > > They would have to be or this is a non-starter. Also see PEP 3151 (Antoine's proposed restructuring of OS and IO exceptions for 3.3) for a discussion of some of the issues and challenges associated with creating better exception hierarchies when the exceptions in question may be raised by third party code. Without careful handling, such changes can become fairly pointless since people still have to catch the top level exception to correctly handle the legacy behaviour. While the hierarchy in this case would be much simpler (base ImportError vs ImportNotFound vs ImportLoadFailed), the core problem of raising the right *kind* of error would remain. There's an even bigger problem in this case, given that we don't have 'errno' to guide the exception type selection the way that PEP 3151 does. Once ImportError.module_name is available (and set correctly by the standard machinery), then that along with the __cause__ and __context__ attributes can be used to figure out the details of what went wrong. However, to be completely compatible with third party import systems, something like Armin's traceback walking approach would still be needed to decide whether or not the module code ever started execution. If we decide to do something about the complex boilerplate needed to implement fallback modules correctly, I'd prefer that we just address that directly. "import x or y or x as name" and "from x or y or z import name" are currently syntax errors, but could fairly readily be made legal. This is far from a new proposal, but nobody has ever been interested enough to turn it into reality (i.e. write a PEP and post a patch). One huge advantage that dedicated syntax would have is that it could use a builtin helper function (ala Python 3's __build_class__) to invoke the correct find_module dance: >>> import imp ImportError: No module named none >>> def import_any(*args): ... for name in args: ... try: ... details = imp.find_module(name) ... except ImportError: ... continue ... return imp.load_module(name, *details) ... raise ImportError('modules not found: {}'.format(args)) ... >>> x = import_any('none') Traceback (most recent call last): File "", line 1, in File "", line 8, in import_any ImportError: modules not found: ('none',) >>> x = import_any('none', 'sys') >>> x Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia