[Python-ideas] sys.path is a hack - bringing it back under control

[anatoly techtonik]

On Mon, Feb 20, 2012 at 5:16 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Mon, Feb 20, 2012 at 11:18 PM, anatoly techtonik <techtonik at gmail.com>
> wrote:
> > The abstract doesn't give any valuable info. "proposes new mechanisms to
> > eliminate some longstanding traps" doesn't say anything. Which
> mechanssms?
> > What traps? I see there a mention of my problem with Django. How can it
> help
> > to debug other sys.path problems? Do I really have to read 15 page
> document
> > to understand that?
>
> Perhaps you could try reading the Table of Contents, too. (Hopefully
> you don't find it too long - it's 20+ lines)
>

I've read the ToC, but which of these parts answers the question: "How to
make debugging sys.path problems easier?"

Abstract
  Relationship with Other PEPs
What's in a __name__?
Traps for the Unwary
  Why are my imports broken?
  Importing the main module twice
  In a bit of a pickle
  Where's the source?
  Forkless Windows
Qualified Names for Modules
  Alternative Names
Eliminating the Traps
  Fixing main module imports inside packages
    Optional addition: command line relative imports
    Compatibility with PEP 382
    Incompatibility with PEP 402
    Potential incompatibilities with scripts stored in packages
  Fixing dual imports of the main module
  Fixing pickling without breaking introspection
  Fixing multiprocessing on Windows
Explicit relative imports


> Or else you may want to refrain from participating in language
> discussions if you aren't interested in understanding the topic in
> depth. No serious design discussion can possibly be held amongst
> people that are only willing to read a PEP abstract rather than the
> full PEP.


I didn't want to offend anybody by giving an impression that what you're
doing is not important. I realize that there are papers that people need to
read, especially who are willing to participate in ideas discussion, but
the point is that I'd like to have a simple answer for a simple proposal.

I read the proposal. In the following order:
PEP-0395: Abstract
PEP-3155: Rationale (skimmed)
PEP-3155: Proposal (reread several times, a lot of questions)
PEP-3155: Discussion (skim, got a feeling that there should be a link to
the actual discussion)
PEP-3155: Naming choice
PEP-3155: References (is still not clear what is `qualified name`)
http://en.wikipedia.org/wiki/QName
http://translate.google.com/#auto|ru|qualified%20name (got translation that
it is 'full name' - that makes sense)
PEP-3155: Naming choice (all right, the more intuitive 'full name' and
'path' are not really 'full name' and filesystem path, so the name is
different)
PEP-0395: Contents
PEP-0395: Qualifed Names for Modules (started - "To make it feasible to fix
these problems once and for all, it is proposed to add a new module level
attribute: __qualname__" - which problems?)
PEP-0395: Traps for the Unwary ("The overloading of the semantics of
__name__, along with some historically associated behaviour in the
initialisation of sys.path[0], has resulted in several traps for the
unwary" - damn, how is this gonna help to debug sys.path problems? gave up,
wrote a sad tl;dr smile)

Now I hope it gives an overview what difficulties a person who is
out-of-context has while trying to solve one tiny user story of debugging
sys.path. I just want everything to be as much simplified as possible,
possibly killing the fun for prose readers. Maybe I don't really want to
think about complex PEP matters, because the idea is just an episode in the
daily workflow. I'd also really prefer to keep complicated matters (e.g.
discussions) around tiny user stories, that don't require much time to load
into the brain and you can only concentrate on two or three of them that
are conflicting. Proposal to read 15 page technical paper doesn't work well
with this scenario, so if you just said - "Yes. You have to read that.",
I'd reply "Well, ok. Next time then.".

(But then, it's been suggested many times in the past that
> you may get better responses if you don't make a habit of effectively
> calling the current core developers a bunch of incompetent idiots, and
> that doesn't appear to have had the slightest effect on your style of
> communication. Why should this be any different?).
>

I am not an English writer, but I am interested to know where did this
impression of me calling core developers a bunch of incompetent idiots is
coming from. If anybody can quote concrete example and explain in private -
I may have a chance to change something. My English is a result of
learning legal and technical English texts, not love letters, and I may not
possess the communication skills required to write proper letters in
informal language (which also I prefer more than business stuff). I can
write in third person without *you* or *I* other personal pronounce, but it
takes more time to compose the proper form, so the note like this one can
take an hour or more (it already took more), and time is that I really
lack. Not me alone, though, but I may be too obsessed with saving someone
else's time by placing too much attention to it, indeed.
-- 
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120220/a9787084/attachment.html>