[Python-ideas] My objections to implicit package directories

[Guido van Rossum]

On Tue, Mar 13, 2012 at 8:35 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 13 March 2012 06:07, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> However, so long as the backwards compatibility from PEP 402 is
>> incorporated, and the new PEP proposed a specific addition to the
>> tutorial to document the "never CD into a package, never double-click
>> a file in a package to execute it, always use -m to execute modules
>> from inside packages" guideline (and makes it clear that you may get
>> strange and unpredictable behaviour if you ever break it), then I can
>> learn to live with it.
>
> Whoa! I'm not sure I can. I just recently got bitten badly by this for
> real. The following was what I was doing:
>
> 1. I'm writing a package.
> 2. I'm trying to do the tests-as-I-develop approach (yes, I know I
> should have been doing this for years - so sue me :-))
> 3. I have my tests as a subpackage of the main package.
> 3. I use the command line
> 4. I cd to the tests directory as that's the easiest way to edit
> tests: gvim test_dow<TAB> to edit test_download_binaries.py.
>
> And yes, I had endless trouble trying to work out why I can't then run
> the tests from the command line. I consider the trouble I have as a
> bug - it *should* work, in my view. I understand why what I'm doing is
> an edge case, but intuitively, I don't like it not working.
>
> I can change my practices, or use an IDE, or something. But my
> workflow will be less comfortable for me, and I don't feel that I
> understand why I should have to.
>
> I *think* that what Nick is proposing is a fix for this (and if it
> isn't, can you fix this scenario too, please Nick? :-)) and the idea
> that it's going to get documented as "don't do that" strikes me as
> unfriendly, if not outright wrong. I also don't think it should be
> documented in the tutorial - it's not something a new developer hits,
> it's later on, when people are writing bigger, more complex code, that
> they hit it.
>
> In summary, I guess I support Nick's objections 3 and 4. We need a
> better response than just "don't do that", IMHO.

Oh, but there are several other solutions. For example, if you set
PYTHONPATH to the directory *containing* your toplevel package, new
code could be added that will discover the true toplevel no matter
where you are. This code doesn't exist today, but Nick is proposing
something similar looking for __init__.py files; the code that tries
to find the script directory as a subdirectory of some path on
sys.path could be added there. Also, the code Nick currently proposes
for PEP 395 is still useful if you add __init__.py files to your
package -- if you did that you wouldn't have to set PYTHONPATH
(assuming we do add this code to Python 3.3, of course).


-- 
--Guido van Rossum (python.org/~guido)