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>
	<CADiSq7c6uzJrbapPMnvn6R7CP6+_fus2DQ_C+rj0YB_zTioKOQ@mail.gmail.com>
	<20110721163700.3daff988@resist.wooz.org>
	<CAGY-8BJND2+8zn1=tsdM5KELFjoT0zZ1-23takFxygC0=rkhGw@mail.gmail.com>
	<20110815234422.DAA243A4105@sparrow.telecommunity.com>
	<CAGY-8BJbR8gEMdoYZ1_yzLpQJDDDkhmOG0ERRNz8pUv6K6xggg@mail.gmail.com>
	<20110816213116.8FE063A409E@sparrow.telecommunity.com>
	<CAGY-8BK=AqT5YxcrUzFCcZzrJ9qCrZbfspB7vzfA4PRON1_YJg@mail.gmail.com>
	<CAP1=2W676RnDz-gxAVNygnwTWkfUmTxtD+Q4rFgr1T9Y=a-Xzg@mail.gmail.com>
	<CAGY-8B+FOkztQ42PWroOTR55enb31Dk=O6WhbRW=45M+LbXekw@mail.gmail.com>
	<CAP1=2W4_7jPQkESVLs95-pd-RN3tc=78Mu-tGUjd0p3LR0isXA@mail.gmail.com>
	<CAGY-8BKNMPZAvNnY2MSqGVHqL3+w5k=SxExwBC2-E1EnFn35bA@mail.gmail.com>
	<20110824131856.7D7AF3A4114@sparrow.telecommunity.com>
Message-ID: <CAGY-8B+-SaPQ68b2+SUzzUCWEbrqCMqq7tr9K_qs2rm85YkQBA@mail.gmail.com>

> 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: <CALFfu7DrmQYzwSaScuKCRRx_RJjndYWEM9HhpkidkKE_sC+C2g@mail.gmail.com>

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: <CALFfu7DrmQYzwSaScuKCRRx_RJjndYWEM9HhpkidkKE_sC+C2g@mail.gmail.com>
References: <CALFfu7DrmQYzwSaScuKCRRx_RJjndYWEM9HhpkidkKE_sC+C2g@mail.gmail.com>
Message-ID: <CAP1=2W6OTMkMsyH2FZdZLoTy+0W0f4We9OmmejRxFo65v=YQVA@mail.gmail.com>

On Wed, Sep 21, 2011 at 12:06, Eric Snow <ericsnowcurrently at gmail.com>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: <http://mail.python.org/pipermail/import-sig/attachments/20110921/e385de4d/attachment.html>

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: <CALFfu7DrmQYzwSaScuKCRRx_RJjndYWEM9HhpkidkKE_sC+C2g@mail.gmail.com>
References: <CALFfu7DrmQYzwSaScuKCRRx_RJjndYWEM9HhpkidkKE_sC+C2g@mail.gmail.com>
Message-ID: <CAOTD34Y0fp=Bsg9zwDffyxmBzdoJbn0wfqwRThPBWnBGSK_7=g@mail.gmail.com>

On Wed, Sep 21, 2011 at 3:06 PM, Eric Snow <ericsnowcurrently at gmail.com> 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: <CAOTD34Y0fp=Bsg9zwDffyxmBzdoJbn0wfqwRThPBWnBGSK_7=g@mail.gmail.com>
References: <CALFfu7DrmQYzwSaScuKCRRx_RJjndYWEM9HhpkidkKE_sC+C2g@mail.gmail.com>
	<CAOTD34Y0fp=Bsg9zwDffyxmBzdoJbn0wfqwRThPBWnBGSK_7=g@mail.gmail.com>
Message-ID: <CAP1=2W56tOCv9Y_F_Yej8bxPdEacE9s=5ipJRuCU2z13VmBuRQ@mail.gmail.com>

On Wed, Sep 21, 2011 at 13:43, Erik Bray <erik.m.bray at gmail.com> wrote:

> On Wed, Sep 21, 2011 at 3:06 PM, Eric Snow <ericsnowcurrently at gmail.com>
> 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: <http://mail.python.org/pipermail/import-sig/attachments/20110921/e88447e2/attachment.html>

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: <CAP1=2W6OTMkMsyH2FZdZLoTy+0W0f4We9OmmejRxFo65v=YQVA@mail.gmail.com>
References: <CALFfu7DrmQYzwSaScuKCRRx_RJjndYWEM9HhpkidkKE_sC+C2g@mail.gmail.com>
	<CAP1=2W6OTMkMsyH2FZdZLoTy+0W0f4We9OmmejRxFo65v=YQVA@mail.gmail.com>
Message-ID: <CALFfu7BGqP6DgBfbGEJWXR73DDWdCdzF-93XqkxcUfJA=TOhdw@mail.gmail.com>

On Wed, Sep 21, 2011 at 1:59 PM, Brett Cannon <brett at python.org> 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: <CAP1=2W56tOCv9Y_F_Yej8bxPdEacE9s=5ipJRuCU2z13VmBuRQ@mail.gmail.com>
References: <CALFfu7DrmQYzwSaScuKCRRx_RJjndYWEM9HhpkidkKE_sC+C2g@mail.gmail.com>
	<CAOTD34Y0fp=Bsg9zwDffyxmBzdoJbn0wfqwRThPBWnBGSK_7=g@mail.gmail.com>
	<CAP1=2W56tOCv9Y_F_Yej8bxPdEacE9s=5ipJRuCU2z13VmBuRQ@mail.gmail.com>
Message-ID: <CADiSq7cV0ktW0TVXZ72b01YLcEkTiHqxOafcONxg=wv+csmnMA@mail.gmail.com>

On Thu, Sep 22, 2011 at 7:16 AM, Brett Cannon <brett at python.org> wrote:
> On Wed, Sep 21, 2011 at 13:43, Erik Bray <erik.m.bray at gmail.com> wrote:
>>
>> On Wed, Sep 21, 2011 at 3:06 PM, Eric Snow <ericsnowcurrently at gmail.com>
>> 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 "<stdin>", line 1, in <module>
  File "<stdin>", line 8, in import_any
ImportError: modules not found: ('none',)
>>> x = import_any('none', 'sys')
>>> x
<module 'sys' (built-in)>

Cheers,
Nick.

-- 
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia