On Mon, Aug 31, 2009 at 14:52, P.J. Eby<p...@telecommunity.com> wrote: > At 01:39 PM 8/31/2009 -0700, Brett Cannon wrote: >> >> On Mon, Aug 31, 2009 at 12:59, Brett Cannon<br...@python.org> wrote: >> > On Mon, Aug 31, 2009 at 12:27, Antoine Pitrou<solip...@pitrou.net> >> > wrote: >> >> Brett Cannon <brett <at> python.org> writes: >> >>> >> >>> I will plan to take this approach then; >> >>> http://bugs.python.org/issue6811 will track all of this. Since this is >> >>> a 3.2 thing I am not going to rush to implement this. >> >> >> >> I still don't understand what the point is of this complicated approach >> >> (adding >> >> an argument to marshal.load()) compared to the simple and obvious >> >> approach >> >> (making co_filename mutable). >> > >> > If we add the argument to marshal.load* we can eventually drop the >> > file location string from marshal data entirely by requiring people to >> > specify the filename to use when the code object is created. Making >> > co_filename mutable simply doesn't allow for this case unless we >> > decide a default value should be used instead. >> > >> >> I should also mention that I am +0 on the marshal.load* change. I >> could be convinced to try to pursue a mutable co_filenme direction, >> but considering the BDFL likes the marshal.load* approach and it opens >> up the possibility of compacting the marshal format I am leaning >> towards sticking with this initial direction. > > Why not just try the code I posted earlier, that doesn't need a mutable > attribute OR an API change?
Ignoring that 'new' is not in Python 3.x (luckily 'types' is), I want a proper solution that doesn't require reconstructing every code object that I happen to import. -Brett _______________________________________________ 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
