On Thu, Jul 15, 2010 at 6:29 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Wed, 14 Jul 2010 19:24:28 -0400 > Alexander Belopolsky <alexander.belopol...@gmail.com> wrote: .. >> This means that >> Antoine's concern that "tomorrow [object_new()] may entail additional >> operations" is not valid - there is no tomorrow for 2.x. :-) > > But there *is* a tomorrow in 3.x and that's what we are talking about. > Your code is meant to emulate object_new() in 3.x. >
Yes, I realized that after I hit the sent button. However, it is 2.x classic instances that are being unpickled and it won't be reasonable for 3.x objects that are expected to emulate them to do anything non-trivial. The need to be able to faithfully emulate classic instances unpickled from 2.x may be a valid constraint to future object_new() evolution. >> This >> also means that the type cannot inherit from anything other than >> object and thus cannot have funny tp_flags or tp_alloc that does not >> create a usable object. > > Why can't it inherit from something else than object? Because this would not be a reasonable way to forward port 2.x classic classes and expect them to interoperate with 2.x pickles. There are many ways to break unpickling of old pickles by modifying the class in the new version of code. The serious question for me is whether a valid tp_alloc can create a partially initialized object that will crash the interpreter when its method is called. I don't think this is the case because certainly you need to be able to delete the object if tp_new fails and that can call arbitrary code. _______________________________________________ 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
