[Python-Dev] how important is setting co_filename for a module being imported to what file is set to? (original) (raw)

Guido van Rossum guido at python.org
Mon Aug 31 18:33:12 CEST 2009

On Mon, Aug 31, 2009 at 9:27 AM, Brett Cannon<brett at python.org> wrote:

On Mon, Aug 31, 2009 at 08:10, Antoine Pitrou<solipsis at pitrou.net> wrote:

Benjamin Peterson <benjamin python.org> writes:

> Why can't we simply make cofilename a writable attribute instead of inventing > some complicated API? Because code objects are supposed to be a immutable hashable object? Right, but cofilename is used neither in tphash nor in tprichcompare. I didn't suggest this since I assumed cofilename was made read-only for a reason back when the design decision was made. But if the original safety concerns are not there then I am happy to simply change the attribute to writable.

Hm... I still wonder if there would be bad side effects of making co_filename writable, but I can't think of any, so maybe you can make this work... The next step would be to not write it out when marshalling a code object -- this might save a bit of space in pyc files too! (I guess for compatibility you might want to write it as an empty string.)

Of course, tracking down all the code objects in the return value of marshal.load*() might be a bit tricky -- API-wise I still think that making it an argument to marshal.load*() might be simpler. Also it would preserve the purity of code objects.

(Michael: it would be fine if other implementations of Python made co_filename writable, as long as you can't think of security issues with this.)

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list