Martin v. Löwis schrieb:
>> Now, why don't we change the semantics as follows: if a file with matching
>> name
>> exists (in import.c::find_module), but opening fails, ImportError is raised
>> immediately with the concrete error message, and without trying the rest of
>> sys.path. That shouldn't c
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|> Now, why don't we change the semantics as follows: if a file with
matching name
| > exists (in import.c::find_module), but opening fails, ImportError is
raised
| > immediately with the concrete error message, and
> How about an ImportWarning instead? That way people can have either
> have import halt immediately, or continue (with or without a message).
If I put my dislike of warnings aside: yes, that would also work.
Martin
___
Python-Dev mailing list
Python-D
On 5/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Now, why don't we change the semantics as follows: if a file with
matching name
> exists (in import.c::find_module), but opening fails, ImportError is
raised
> immediately with the concrete error message, and without trying the rest
of
>
> Now, why don't we change the semantics as follows: if a file with matching
> name
> exists (in import.c::find_module), but opening fails, ImportError is raised
> immediately with the concrete error message, and without trying the rest of
> sys.path. That shouldn't cause any working and sane setu
Today, I got a request regarding importing semantics.
When a module file cannot be opened because of, say, lacking read permission,
the rest of sys.path will be tried, and if nothing else is found, you get
"no module named foo".
The reporter claimed, and I understand that, that this is a pain to
