This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients _doublep, loewis
Date 2008-09-07.19:28:34
SpamBayes Score 1.8593105e-10
Marked as misclassified No
Message-id <1220815715.73.0.472406288146.issue3760@psf.upfronthosting.co.za>
In-reply-to
Content
The intention is that different interpreters have distinct, separate
instances of the type objects. This is desirable in case of class
variables, and standard for Python-defined types. Clearly, 3.0 won't
provide that separation for many of the builtin types (and never may);
for out-of-core types, it is really the choice of the module designer.

I forgot to implement PyType_Copy; it is meant to create a new type
object which is a field-by-field copy. It's now too late to add it to
3.0; extension authors requiring it now should include it's source code
(which is currently not even written - contributions are welcome).

Reconsidering it: what should it do to the base types? 
 a) just incref tp_base and clone tp_bases, 
 b) offer an optional parameter to specify an alternative base object, 
 c) offer an optional parameter to specify an alternative bases tuple.
History
Date User Action Args
2008-09-07 19:28:35loewissetrecipients: + loewis, _doublep
2008-09-07 19:28:35loewissetmessageid: <1220815715.73.0.472406288146.issue3760@psf.upfronthosting.co.za>
2008-09-07 19:28:35loewislinkissue3760 messages
2008-09-07 19:28:34loewiscreate