Neal Norwitz schrieb:
> On 5/6/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
>> I lost the key I originally gave for commiting my summaries. Who do I
>> talk to about fixing that?
>
> Send your new key to pydotorg. -- n
In doing so, please indicate whether you just lost it, or somebody else
may
On 5/6/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> I lost the key I originally gave for commiting my summaries. Who do I
> talk to about fixing that?
Send your new key to pydotorg. -- n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
I lost the key I originally gave for commiting my summaries. Who do I
talk to about fixing that?
--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/
___
Python-Dev mailing list
Python-Dev@py
Steve Holden wrote:
> Tim Delaney wrote:
>> BTW, one of my test cases involves multiple super calls in the same
>> method - there is a *very* large performance improvement by
>> instantiating it once.
>>
> And how does speed deteriorate for methods with no uses of super at
> all (which will, I s
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
10 matches
Mail list logo
