<br><div class="gmail_quote">On Sun, Aug 30, 2009 at 5:24 PM, Guido van Rossum <span dir="ltr">&lt;<a href="mailto:guido@python.org">guido@python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Sun, Aug 30, 2009 at 4:28 PM, Brett Cannon&lt;<a href="mailto:brett@python.org">brett@python.org</a>&gt; wrote:<br>
&gt; I am going through and running the entire test suite using importlib<br>
&gt; to ferret out incompatibilities. I have found a bunch, although all<br>
&gt; rather minor (raising a different exception typically; not even sure<br>
&gt; they are worth backporting as anyone reliant on the old exceptions<br>
&gt; might get a nasty surprise in the next micro release), and now I am<br>
&gt; down to my last failing test suite: test_import.<br>
&gt;<br>
&gt; Ignoring the execution bit problem (<a href="http://bugs.python.org/issue6526" target="_blank">http://bugs.python.org/issue6526</a><br>
&gt; but I have no clue why this is happening), I am bumping up against<br>
&gt; TestPycRewriting.test_incorrect_code_name. Turns out that import<br>
&gt; resets co_filename on a code object to __file__ before exec&#39;ing it to<br>
&gt; create a module&#39;s namespace in order to ignore the file name passed<br>
&gt; into compile() for the filename argument. Now I can&#39;t change<br>
&gt; co_filename from Python as it&#39;s a read-only attribute and thus can&#39;t<br>
&gt; match this functionality in importlib w/o creating some custom code to<br>
&gt; allow me to specify the co_filename somewhere (marshal.loads() or some<br>
&gt; new function).<br>
&gt;<br>
&gt; My question is how important is this functionality? Do I really need<br>
&gt; to go through and add an argument to marshal.loads or some new<br>
&gt; function just to set co_filename to something that someone explicitly<br>
&gt; set in a .pyc file? Or I can let this go and have this be the one<br>
&gt; place where builtins.__import__ and importlib.__import__ differ and<br>
&gt; just not worry about it?<br>
<br>
</div>ISTR that Bill Janssen once mentioned a file replication mechanism<br>
whereby there were two names for each file: the &quot;canonical&quot; name on a<br>
replicated read-only filesystem, and the longer &quot;writable&quot; name on a<br>
unique master copy. He ended up with the filenames in the .pyc files<br>
being pretty bogus (since not everyone had access to the writable<br>
filesystem). So setting co_filename to match __file__ (i.e. the name<br>
under which the module is being imported) would be a nice service in<br>
this case.<br>
<br>
In general this would happen whenever you pre-compile a bunch of .py<br>
files to .pyc/.pyo and then copy the lot to a different location. Not<br>
a completely unlikely scenario.</blockquote><div><br></div><div>8-9 years ago while using py2exe on windows to create stand along binaries out of Python programs for distribution we ran into this issue... The compiled .pyc&#39;s that py2exe bundles up contained the pathname to the source code on the development build system.  When you get a stacktrace python would look for the source code based on those.... Really horrible if your build system used a windows drive letter other than C such as D: as it could cause windows to pop up a dialog asking the user to insert a CD or spin up a spun down optical disc or ask for a floppy, etc. ;)</div>

<div><br></div></div>