Although the tone of the article is clearly emotional and intended to be so there are also arguments. If you find something reasonable about how relative imports work or the sys.modules cache you are free to provide a counter-argument, either here in the comment section or on your own blog.

The article about the import machinery is meant deadly serious though for reasons given there. It has been a constant pain since I can think about using Python 1.5.2 and it became even worse over the time. I actually want people to acknowledge this even if it produces bad PR temporarily ( people are forgetful and move on to things they find more important and entertaining than a rather technical and esoteric topic they can virtually contribute nothing to it ).

But as long as we’re being inflammatory and trolling, I personally think that people who want to replace imports with file paths are stuck in PHP-land. Even Perl and Java have native support for namespace packages. It’s about time Python included something better than pkgutil.extend_path.

Please consider making your writing style less combative. It is heavy on assertions and emotional adjectives (”Python is Doomed” because it uses whitespace indentation). You seem to pick one python feature a week and denounce it as an unforgivable evil. There might be two people on the planet that can be bullied into agreeing with you but for the rest of us you will have to make an agument, not propaganda.

BTW I’m not quite clear if I like the idea of versioned module imports. This has the bad taste of compiler flags to me. But that’s right now really off topic and it may be perfectly possible that it fits into the new structure quite naturally. Importing from URLs will be naturally provisioned although I don’t give a reference implementation and there also won’t be changes in the Python grammar to support URLs in import statements. If I’ve got a working prototype you might checkout implementing a fetch command yourself.

Notice also one thing. Beyond an initialization phase my implementation will completely bypass Pythons current import system which importlib does not. Maybe there will be some rest. I’m not finished with it. This can be done in pure Python only by means of language transformations - import statements have to be transformed into function calls in Python code. This also means that it will always ever have the status of a prototype.

not so sure about making the .py extension mandatory; also, it is symbolic itself (as it could be supplanted by .pyc, .pyo where suitable); but if extensions are omitted, how do you distinguish between a file x.py and a package x? or maybe this is not necessary?

also, some versioning system should be readily available, so you can e.g. state fetch( ‘foobar[>0.3]‘ ), and, importantly, to use URL-like identifiers to avoid name clashes (but please not in the way that java does it), maybe à la mojo = fetch( ‘example.com/projects/fireball//magic/mojo.py’ ).

just some arbitrary ideas. probably yours will be very different.

I’m not nearly conversant enough in the import mechanism to know if it would address your concerns (and in fact, I’ve never had a significant problem with importing, so I’m clearly not your target audience), but I’ve read much of Brett’s posting on importlib, and it seems like he spent a lot of time trying to build it properly.

Let me know your thoughts.

Thanks