How to guard against bugs like this one?
in [Python]
|
From: Carl Banks on 2 Feb 2010 22:55 On Feb 2, 5:49 pm, Steven D'Aprano <ste...(a)REMOVE.THIS.cybersource.com.au> wrote: > On Tue, 02 Feb 2010 12:26:16 -0800, Carl Banks wrote: > > I did not propose obvious module names. I said obvious names like > > email.py are bad; more descriptive names like send_email.py are better. > > But surely send_email.py doesn't just send email, it parses email and > receives email as well? No, it doesn't. Carl Banks
From: Steven D'Aprano on 2 Feb 2010 23:52 On Tue, 02 Feb 2010 19:55:15 -0800, Carl Banks wrote: > On Feb 2, 5:49 pm, Steven D'Aprano > <ste...(a)REMOVE.THIS.cybersource.com.au> wrote: >> On Tue, 02 Feb 2010 12:26:16 -0800, Carl Banks wrote: >> > I did not propose obvious module names. I said obvious names like >> > email.py are bad; more descriptive names like send_email.py are >> > better. >> >> But surely send_email.py doesn't just send email, it parses email and >> receives email as well? > > No, it doesn't. Nevertheless, as a general principle, modules will tend to be multi- purpose and/or generic. How would you rename the math or random modules to be less "obvious" and more "descriptive"? And of course, the less obvious the name, the harder it becomes for people to find and use it. Which extreme would you rather? import zip import compress_and_decompress_files_to_zip_archives I'm sympathetic to the position you're taking. It's not bad advice at all, but I think you're over-selling it as a complete solution to the problem of name clashes. I think it can only slightly alleviate the problem of name clashes, not eliminate it. -- Steven
From: kj on 3 Feb 2010 08:52 Steve, I apologize for the snarkiness of my previous reply to you. After all, I started the thread by asking the forum for advice on how to avoid a certain kind of bugs, you were among those who gave me advice. So nothing other than thanking you for it was in order. I just let myself get carried away by my annoyance with the Python import scheme. I'm sorry about it. Even though I don't think I can put to practice all of your advice, I can still learn a good deal from it. Cheers, ~kj Steve Holden <steve(a)holdenweb.com> writes: >kj wrote: >> >>> First, I don't shadow built in modules. Its really not very hard to avoid. >> >> ...*if* you happen to be clairvoyant. I still don't see how the rest of us >> could have followed this fine principle in the case of numbers.py >> prior to Python 2.6. >> >Clearly the more you know about the standard library the less likely >this is to be a problem. Had you been migrqating from an earlier version > the breakage would have alerted you to look for some version-dependent >difference. <snip>
From: kj on 3 Feb 2010 11:17 In <hkbv23$c07$1(a)reader2.panix.com> kj <no.email(a)please.post> writes: >Steve, I apologize for the snarkiness of my previous reply to you. >After all, I started the thread by asking the forum for advice on >how to avoid a certain kind of bugs, you were among those who gave >me advice. So nothing other than thanking you for it was in order. >I just let myself get carried away by my annoyance with the Python >import scheme. I'm sorry about it. Even though I don't think I >can put to practice all of your advice, I can still learn a good >deal from it. Boy, that was dumb of me. The above apology was meant for Stephen Hansen, not Steve Holden. I guess this is now a meta-apology... (Sheesh.) ~kj
From: Nobody on 3 Feb 2010 11:55
On Tue, 02 Feb 2010 10:38:53 -0800, Carl Banks wrote: >> I don't know if that's necessary. Only supporting the "foo.h" case would >> work fine if Python behaved like gcc, i.e. if the "current directory" >> referred to the directory contain the file performing the import rather >> than in the process' CWD. >> >> As it stands, imports are dynamically scoped, when they should be >> lexically scoped. > > Mostly incorrect. The CWD is in sys.path only for interactive > sessions, and when started with -c switch. When running scripts, the > directory where the script is located is used instead, not the > process's working directory. Okay, so s/CWD/directory containing __main__ script/, but the general argument still holds. > So, no, it isn't anything like dynamic scoping. That's what it looks like to me. The way that an import name is resolved depends upon the run-time context in which the import occurs. >> The only situation where the process' CWD should be used is for an import >> statement in a non-file source (i.e. stdin or the argument to the -c >> switch). > > It already is that way, chief. > > I think you're misunderstanding what's wrong here; the CWD doesn't > have anything to do with it. Even if CWD isn't in the path you still > get the bad behavior kj noted. So now what? Search for imports first in the directory containing the file performing the import. This is essentially the situation with gcc; the directory containing the current file takes precedence over directories specified by -I switches. If you want to override this, you have to use the -I- switch, which makes it very unlikely to happen by accident. |