Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Fri, 11 Jan 2013 21:28:49 -0800 (PST)
In-Reply-To: <mailman.388.1357886143.2939.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=70.196.131.158; posting-account=h3aEwQoAAACiuqX-oR3gvCVFm8lLHoWj
References: <88bab977-ca49-487a-8fba-7d3350266d8d@googlegroups.com> <mailman.388.1357886143.2939.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: PyWart: Import resolution order
From: Rick Johnson <rantingrickjohnson@gmail.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: python-list@python.org
Precedence: list
Message-ID: <mailman.430.1357969142.2939.python-list@python.org>
Lines: 56
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:36675

On Friday, January 11, 2013 12:30:27 AM UTC-6, Chris Angelico wrote:
> Why is it better to import from the current directory first?

Opps. I was not explicit enough with my explanation :). I meant, "look in t=
he current directory FIRST when in a package". Since many times (most all t=
imes) packages will contain many sub-modules that need to be imported into =
the package's main.py module, and sometimes these modules will have the sam=
e name as a stdlib module, then looking in the package FIRST makes sense.


But the real solution is not to change the default resolution order. The re=
al solution is to wrap all builtin modules into a package and use full path=
s to access every module. But wait, i have an even better idea... read belo=
w!

> Windows
> has that policy for executable commands; Unix, on the other hand,
> requires that you put an explicit path for anything that isn't in the
> standard search path. Which of these options is the more likely to
> produce security holes and/or unexpected behaviour?

I prefer the latter of course :).=20

I think if python where *strict* about full paths for non-builtins, then we=
 would be in a better place. But there is an even better solution! Force al=
l python users to wrap THEIR modules in a toplevel package. Maybe even crea=
te the package for them. YES!. Call it "lib". Any "naked" modules (meaning =
modules that are not in a package)  would have to be accessed starting from=
 "lib". Of course professionals like you and i are already using packages t=
o properly nest out modules, but the newbie's won't realize the power of pa=
ckaging modules for some time, so create the default "lib" package for them=
.

For instance you could create a package named "chris" and then have a modul=
e named math exist inside. Alternatively if you choose to be a non-professi=
onal and create a math module without a containing package, python would th=
row the module into the default "lib" package. The only way you could acces=
s your math module now would be by using the path "lib.math".=20

So the conclusion is:

 * We encourage python programmers to use packages so they avoid any name c=
lashes with built-in modules.=20
=20
 * if they refuse fine, any "naked" modules they create will be packaged in=
 a default package (call it "lib", "userlib", or whatever) and will require=
 them to prefix the module name with "lib." -- or "lib:" if i get my way!
=20
By doing this we solve the many problems related to module name resolution =
orders and we create cleaner code bases. Damn i am full of good ideas!

> Welcome back to the list, Rick. Got any demonstrable code
> for Python 4000 yet?

I am working on it. Stay tuned. Rick is going to rock your little programmi=
ng world /very/ soon.