How to guard against bugs like this one?
in [Python]
|
From: Carl Banks on 2 Feb 2010 13:45 On Feb 2, 2:49 am, Jean-Michel Pichavant <jeanmic...(a)sequans.com> wrote: > Carl Banks wrote: > > Name your modules "send_email.py" or "sort_email.py" or if it's a > > library module of related functions, "email_handling.py". Modules and > > scripts do things (usually), they should be given action words as > > names. > > > (**) Questionable though it be, if the Standard Library wants to use > > an "innocuous" name, It can. > > That does not solve anything, Of course it does, it solves the problem of having poorly-named modules. It also helps reduce possibility of name clashes. > if the smtplib follows your advice, then > you'll be shadowing its send_email module. > The only way to avoid collision would be to name your module > __PDSFLSDF_send_email__13221sdfsdf__.py I know, and as we all know accidental name clashes are the end of the world and Mother Python should protect us feeble victims from any remote possibility of ever having a name clash. Carl Banks
From: Jean-Michel Pichavant on 2 Feb 2010 14:07 Carl Banks wrote: > On Feb 2, 2:49 am, Jean-Michel Pichavant <jeanmic...(a)sequans.com> > wrote: > >> Carl Banks wrote: >> >>> Name your modules "send_email.py" or "sort_email.py" or if it's a >>> library module of related functions, "email_handling.py". Modules and >>> scripts do things (usually), they should be given action words as >>> names. >>> >>> (**) Questionable though it be, if the Standard Library wants to use >>> an "innocuous" name, It can. >>> >> That does not solve anything, >> > > Of course it does, it solves the problem of having poorly-named > modules. It also helps reduce possibility of name clashes. > Actually don't you think it will increase the possibility ? There are much less possibilties of properly naming an object than badly naming it. So if everybody tend to properly name their object with their obvious version like you proposed, the set of possible names will decrease, increasing the clash ratio. I'm just nitpicking by the way, but it may be better to ask for better namespacing instead of naming (which is good thing but unrelated to the OP issue). JM
From: kj on 2 Feb 2010 14:43 In <mailman.1795.1265135424.28905.python-list(a)python.org> Terry Reedy <tjreedy(a)udel.edu> writes: >On 2/2/2010 9:13 AM, kj wrote: >>> As for fixing it, unfortunately it's not quite so simple to fix without >>> breaking backwards-compatibility. The opportunity to do so for Python 3.0 >>> was missed. >> >> This last point is to me the most befuddling of all. Does anyone >> know why this opportunity was missed for 3.0? Anyone out there >> with the inside scoop on this? Was the fixing of this problem >> discussed in some PEP or some mailing list thread? (I've tried >> Googling this but did not hit on the right keywords to bring up >> the deliberations I'm looking for.) >There was a proposal to put the whole stdlib into a gigantic package, so >that >import itertools >would become, for instance >import std.itertools. >Guido rejected that. I believe he both did not like it and was concerned >about making upgrade to 3.x even harder. The discussion was probably on >the now closed py3k list. Thanks. I'll look for this thread. ~K
From: Carl Banks on 2 Feb 2010 15:26 On Feb 2, 11:07 am, Jean-Michel Pichavant <jeanmic...(a)sequans.com> wrote: > Carl Banks wrote: > > On Feb 2, 2:49 am, Jean-Michel Pichavant <jeanmic...(a)sequans.com> > > wrote: > > >> Carl Banks wrote: > > >>> Name your modules "send_email.py" or "sort_email.py" or if it's a > >>> library module of related functions, "email_handling.py". Modules and > >>> scripts do things (usually), they should be given action words as > >>> names. > > >>> (**) Questionable though it be, if the Standard Library wants to use > >>> an "innocuous" name, It can. > > >> That does not solve anything, > > > Of course it does, it solves the problem of having poorly-named > > modules. It also helps reduce possibility of name clashes. > > Actually don't you think it will increase the possibility ? There are > much less possibilties of properly naming an object than badly naming it. You've got to be kidding me, you're saying that a bad name like email.py is less likely to clash than a more descriptive name like send_email.py? > So if everybody tend to properly name their object with their obvious > version like you proposed, the set of possible names will decrease, > increasing the clash ratio. 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. Carl Banks
From: Roel Schroeven on 2 Feb 2010 16:38
Op 2010-02-02 18:02, Nobody schreef: > On Tue, 02 Feb 2010 15:00:28 +0000, Grant Edwards wrote: > >>>> It turns out that buggy.py imports psycopg2, as you can see, and >>>> apparently psycopg2 (or something imported by psycopg2) tries to >>>> import some standard Python module called numbers; instead it ends >>>> up importing the innocent myscript/numbers.py, resulting in *absolute >>>> mayhem*. >>> >>> I feel your pain, but this is not a Python problem, per-se. >> >> I think it is. > > I agree. > >> There should be different syntax to import from >> "standard" places and from "current directory". Similar to the >> difference between "foo.h" and <foo.h> in cpp. > > 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. That is what I would have expected, it is the way I would have implemented it, and I don't understand why anyone would think differently. Yet not everyone seems to agree. Apparently, contrary to my expectations, Python looks in the directory containing the currently running script instead. That means that the behavior of "import foo" depends very much on circumstances not under control of the module in which that statement appears. Very fragile. Suggestions to use better names or just poor workarounds, IMO. Of the same nature are suggestions to limit the amount of scrips/modules in a directory... my /usr/bin contains no less than 2685 binaries, with 0 problems of name clashes; there is IMO no reason why Python should restrict itself to any less. Generally I like the design decisions used in Python, or at least I understand the reasons; in this case though, I don't see the advantages of the current approach. -- The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom. -- Isaac Asimov Roel Schroeven |