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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
