On Mon, Aug 31, 2009 at 9:27 AM, Brett Cannon<br...@python.org> wrote: > On Mon, Aug 31, 2009 at 08:10, Antoine Pitrou<solip...@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/) _______________________________________________ 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
