[Python-Dev] how important is setting co_filename for a module being imported to what __file__ is set to?

[Guido van Rossum]

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 <at> python.org> writes:
>>>
>>> > Why can't we simply make co_filename a writable attribute instead of
>> inventing
>>> > some complicated API?
>>>
>>> Because code objects are supposed to be a immutable hashable object?
>>
>> Right, but co_filename is used neither in tp_hash nor in tp_richcompare.
>
> I didn't suggest this since I assumed co_filename 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/)