[Python-Dev] Proposed beta 2 changes (Q for Anthony/Neal)

[Nick Coghlan]

Anthony Baxter wrote:
> On Tuesday 04 July 2006 22:32, Nick Coghlan wrote:
>> 1. Finishing the __module_name__ workaround to allow relative
>> imports from the main module when using -m.
> 
> I have some nervousness about this. Are there cases in the stdlib 
> where this is an issue, today? Are there any cases which can't be 
> addressed by using absolute imports? For 2.5, wouldn't it be better 
> to simply say "use absolute imports in this case"?

> My nervousness is that I don't want a late change to introduce a 
> language misfeature that we'll all regret later.

I actually come to agree with this POV - particularly after spending some time 
thinking about how I'd like to it to look in Py3k (with a simple boolean check 
replacing the __name__ == "__main__" idiom).

I'll revert the change that added __module_name__, too. I'd love to fix this 
properly for 2.5 but the timing of the discovery of the limitation is 
unfortunately lousy :(

I'll add something to PEP 338, and possibly elsewhere, noting that the -m 
switch adds the current directory to sys.path, so absolute imports will work 
fine so long as you invoke Python from the directory containing the relevant 
top level package directory, even if it isn't anywhere else on sys.path.

Some time between now and late 2007 I'll write something up about the 
interaction between __name__, sys.path[0] and implicit relative imports that 
actually makes implicit relative imports appear to work when a module inside a 
package is executed directly instead of via -m (probably when I get around to 
writing a Python 2.6 PEP on the topic).

Heh. I was going to be clever with the PEP number relating to this for 2.6, 
and I think I've discovered that trying to mix PEP 328 with 338 is going to be 
a doomed effort - add the PEP numbers together to find out why ;)

>> 2. Adding an 'ignore' filter for ImportWarning at the end of
>> warnings.py
> 
> Already covered this one in another email... Yes, this seems the best 
> approach for 2.5.

OK, I'll make the change to warnings.py, and update the warnings module 
documentation. AMK will still need to update What's New.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org