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 lemburg
Recipients ajaksu2, amaury.forgeotdarc, collinwinter, ezio.melotti, jafo, jimjjewett, lemburg, orivej, pitrou, vstinner
Date 2009-06-02.13:46:45
SpamBayes Score 1.9228719e-07
Marked as misclassified No
Message-id <4A252D43.2000106@egenix.com>
In-reply-to <1243723272.11.0.154600236805.issue1943@psf.upfronthosting.co.za>
Content
Jim Jewett wrote:
> Jim Jewett <jimjjewett@users.sourceforge.net> added the comment:
> 
> There were a number of patches to support sharing of data between 
> unicode objects.  (By Larry Hastings?)  They were rejected because (a)  
> they were complicated, and (b)  it was possible to provoke pathological 
> memory retention.

Right, but the patches were targeting the main Unicode type implementation.

It would certainly be possible to implement these features on a Unicode
sub-type.

Note that the Unicode type implementation on which the Python type
is based did in fact use references to other objects in order to
implement sharing.

This part was removed from the base type due to the issues with
unwillingly keeping alive large reference objects. However, the
implementation can be used as basis for writing a Unicode sub-type
which does implement data sharing.

If you're looking for application space where such data sharing
types are useful, have a look at parsing engines or routines
that split larger chunks of data in multiple smaller pieces.
Shared memory is another use case where such types would enable
sharing of Unicode data between processes... but I'm repeating
myself.
History
Date User Action Args
2009-06-02 13:46:47lemburgsetrecipients: + lemburg, collinwinter, jafo, jimjjewett, amaury.forgeotdarc, pitrou, vstinner, ajaksu2, orivej, ezio.melotti
2009-06-02 13:46:45lemburglinkissue1943 messages
2009-06-02 13:46:45lemburgcreate