anatoly techtonik wrote:

On Mon, Feb 20, 2012 at 1:06 PM, Simon Sapin wrote:

...

I often find this in my scripts/projects, that I run directly from

...

checkout:

DEVPATH =os.path.dirname(os.path.**abspath(__file__)) sys.path.insert(0,DEVPATH)

You shouldn’t have to do that if you’re running 'python something.py'

But I did for some reason, and right now I can't even say if it was Windows, Linux, FreeBSD, PyPy, IPython, gdb or debugging from IDE.

If you can't say why you did it, how can we judge whether you did it for a good reason or a bad reason? Having a user-accessible search path is not a hack, or if it is, it is a hack in the positive sense: a feature, not a design bug. The same concept is used by Unix tools, via the PATH environment variable. It is "the simplest thing that could possibly work" for solving the problem of configurable search paths. Personally, I don't believe sys.pack needs to be brought back under control, because I don't believe it is out of control. Most code doesn't need to mess with the path; of that which does, most does not lead to problems. The only time I have seen path problems is when I have accidentally shadowed standard library modules, and they are simple to solve. Perhaps others have experienced harder problems, and if so, they have my sympathy, but I don't believe this is a problem so great that it needs to break backward compatibility. I would say, though, that nearly every time I have changed sys.path, I would have been satisfied with some way of importing directly from a known location. import spam from 'this/is/a/relative/path' from spam import ham from '/and/this/is/an/absolute/path' sort of thing, although I can see that import...from and from...import are too similar for comfort. -- Steven

On Mon, Feb 20, 2012 at 1:38 PM, Nick Coghlan wrote:

On Mon, Feb 20, 2012 at 7:47 PM, anatoly techtonik wrote:

...

Hi,

I often find this in my scripts/projects, that I run directly from checkout:

DEVPATH = os.path.dirname(os.path.abspath(__file__)) sys.path.insert(0, DEVPATH)

PEP 395 describes my current plan to fix sys.path initialisation (however, I can't yet promise that it will make it into 3.3, since it doesn't even have a reference implementation yet, and I have several other things I want to get done first).

tl;dr :( 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? -- anatoly t.

On Mon, Feb 20, 2012 at 5:16 PM, Nick Coghlan wrote:

On Mon, Feb 20, 2012 at 11:18 PM, anatoly techtonik 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.

On Tue, Feb 21, 2012 at 3:39 AM, anatoly techtonik wrote:

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

Ah, my apologies. I must confess to having misread your original email (I paid too much attention to the first half, not enough to the latter). PEP 395 aims to avoid people feeling the need to mess with sys.path in the first place, thus reducing the likelihood of problems occurring in the first place. For *debugging* sys.path, as you say, the problem is figuring out who is messing it up after problems have already occurred and you've found strange entries in there. There's definitely a case to be made that sys.path should be a smarter kind of object by default, one that accepts callbacks to be triggered when modifications occur. (such behaviour would be useful for updating namespace package __path__ attributes, for instance). However, for purely debugging purposes, it should be sufficient to monkeypatch sys.path with an object that write any changes through to the original path, while overriding the various mutations methods to report the source of the modification (via stack introspection). IIt's the same kind of technique you can use to investigate faults in *any* kind of container. (Versions based on UserDict and UserList might be interesting Python Cookbook recipes).

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.".

The fault was mine - I didn't understand your suggestion correctly, so I didn't realise that PEP 395 doesn't actually address it.

...

(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, thanks for taking the time to explain that. The impression comes from the fact that many of the things you object to within Python are largely a result of limited availability of development resources, so even things that are at least arguably good ideas simply don't get investigated. The universe of good ideas is vast, the universe of bad ideas is even larger, but the space we have the capacity to explore is actually relatively tiny. Since there's such an enormous number of things that *could* be done, the answer to "why aren't they done?" is almost always going to "because people don't think they're important enough to do them instead of all the other things they're doing". Deciding how to spend our time on Python-related efforts is a matter of perceived priorities and potential payoffs and those are always going to vary substantially across individuals. Being more willing to accept that as a rationale for not doing things would go a long way towards reducing the negative reactions - I know mine arise not so much for your initial suggestions (which are often, although not always, quite reasonable ideas in a world where we had unlimited development resources), but from subsequently continuing to push them in the face "because we're simply not interested in doing that" and "the status quo may not be perfect, but it's good enough that it isn't worth the hassle of changing" responses. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On Feb 20, 11:18 pm, anatoly techtonik wrote:

tl;dr :(

You're _constantly_ bemoaning the "obvious" lack of clear communication paths in the Python community, and yet when you're pointed to an _explicit piece of documentation that answers your concerns_ you can't even be bothered to read it. It's pretty damn "obvious" that your only real issue with communication is when it isn't being spoon fed to you.