Re: class ModuleNotFoundError(ImportError)

On Tue, Mar 1, 2011 at 10:07 AM, Greg Ewing <greg.ewing@...> wrote:
> Nick Coghlan wrote:
>
>> Perhaps it it worth revisiting the old "import x or y or z as
>> whatever" syntax proposal for 3.3
>
> +1, as the suggested idiom is getting rather long-winded. Also
> it gets worse when there are more than two alternatives, since
> you end up with another nesting level for each fallback.
>
>> (although deciding what, if anything to do for "from" style
>> imports is a hassle)
>
> I don't think it would be too bad:
>
>   from x or y or z import foo, spam, eggs
>
> This would first try to find one of the listed modules, and
> having found it, import it and attempt to bind the specified
> names.

True, I guess it is really only the module naming that differs in
cases like ElementTree, which would be handled just fine by the simple
approach:

    import lxml.etree or element.ElementTree or xml.etree.ElementTree as etree
    from lxml.etree or element.ElementTree or xml.etree.ElementTree
import Element

If the internal APIs of the resolved modules differ to the point where
the latter doesn't work then the longhand form remains available.

Cheers,
Nick.

--

-- 
Nick Coghlan   |   ncoghlan@...   |   Brisbane, Australia