[Python-Dev] PEP 338 issue finalisation (was Re: 2.5 PEP)

Nick Coghlan ncoghlan at gmail.com
Fri Feb 17 14:55:47 CET 2006


Guido van Rossum wrote:
> [Hey, I thought I sent that just to you. Is python-dev really
> interested in this?]

Force of habit on my part - I saw the python-dev header and automatically 
dropped "pyd" into the To: field of the reply.

Given Paul's contribution on the get_data front, it turned out to be a 
fortuitous accident :)


[init_globals argument]
>> I just realised that anything that's a legal argument to "dict.update" will
>> work. I'll fix the function description in the PEP (and the docs patch as well).
> 
> I'm not sure that's a good idea -- you'll never be able to switch to a
> different implementation then.

Good point - I'll change the wording so that (officially, at least) it has to 
be a dictionary.


[_read_compiled_file() error handling]
> Also, *perhaps* it makes more sense to return None instead of raising
> ValueError? Since you're always catching it? (Or are you?)

I've changed this in my local copy. That provides a means for dealing with 
marshal, too - catching any Exception from marshal.load and convert it to 
returning None.

This approach loses some details on what exactly was wrong with the file, but 
that doesn't seem like a big issue (and it cleans up some of the other code).


[run_module() error handling]
> OK. But a loader could return None from get_code() -- do you check for
> that? (I don't have the source handy here.)

The current version on SF doesn't check it, but I just updated my local copy 
to fix that.


[run_module() interaction with import]
> What happens when you execute "foo.py" as __main__ and then (perhaps
> indirectly) something does "import foo"? Does a second copy of foo.py
> get loaded by the regular loader?

Yes - this is the same as if foo.py was run directly from the command line via 
its filename.


[YAGNI and 6 public functions where only 1 has a demonstrated use case]
> I do wonder if runpy.py isn't getting a bit over-engineered -- it
> seems a lot of the functionality isn't actually necessary to implement
> -m foo.bar, and the usefulness in other circumstances is as yet
> unproven. What do you think of taking a dose of YAGNI here?
> (Especially since I notice that most of the public APIs are very thin
> layers over exec or execfile -- people can just use those directly.)

I had a look at pdb and profile, and the runpy functions really wouldn't help 
with either of those. Since I don't have any convincing use cases, I'll demote 
run_code and run_module_code to be private helper functions and remove the 
three run*file methods (I might throw those three up on ASPN as a cookbook 
recipe instead).

That leaves the public API containing only run_module, which is all -m really 
needs.

[thread safety and the import lock]
>> Another problem that occurred to me is that the module isn't thread safe at
>> the moment. The PEP 302 emulation isn't protected by the import lock, and the
>> changes to sys.argv in run_module_code will be visible across threads (and may
>> clobber each other or the original if multiple threads invoke the function).
> 
> Another reason to consider cutting it down to only what's needed by
> -m; -m doesn't need thread-safety (I think).

Yeah, thread-safety is only an issue if invoking runpy.run_module from 
threaded Python code. However, I think this is one of those nasty threading 
problems where it will work for 99.9% of cases and produce intractable bugs 
for the remaining 0.1%. If an extra try-finally block can categorically rule 
out those kinds of problems, then I think it's nicer to include it.

Cheers,
Nick.

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


More information about the Python-Dev mailing list