Author ncoghlan
Recipients Arfrever, inada.naoki, ishimoto, loewis, mrabarnett, ncoghlan, pitrou, serhiy.storchaka, vstinner
Date 2012-08-07.05:34:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1344317642.32.0.214345258398.issue15216@psf.upfronthosting.co.za>
In-reply-to
Content
The reason I marked this as a release blocker for 3.4 is because it's a key piece of functionality for writing command line apps which accept an encoding argument. I'll use "high" instead.

An interesting proposal was posted to the python-dev thread [1]: using self.detach() and self.__init__() to reinitialise the wrapper *in-place*.

With that approach, the pure Python version of set_encoding() would look something like this:

    _sentinel = object()
    def set_encoding(self, encoding=_sentinel, errors=_sentinel):
        if encoding is _sentinel:
            encoding = self.encoding
        if errors is _sentinel:
            errors = self.errors
        self.__init__(self.detach(),
                      encoding, errors,
                      self._line_buffering,
                      self._readnl,
                      self._write_through)

(The pure Python version currently has no self._write_through attribute - see #15571)

Note that this approach addresses my main concern with the use of detach() for this: because the wrapper is reinitialised in place, old references (such as the sys.__std*__ attributes) will also see the change.

Yes, such a function would need a nice clear warning to say "Calling this may cause data loss or corruption if used without due care and attention", but it should *work*. (Without automatic garbage collection, the C implementation would need an explicit internal "reinitialise" function rather than being able to just use the existing init function directly, but that shouldn't be a major problem).

[1] http://mail.python.org/pipermail/python-ideas/2012-August/015898.html
History
Date User Action Args
2012-08-07 05:34:02ncoghlansetrecipients: + ncoghlan, loewis, ishimoto, pitrou, vstinner, mrabarnett, Arfrever, inada.naoki, serhiy.storchaka
2012-08-07 05:34:02ncoghlansetmessageid: <1344317642.32.0.214345258398.issue15216@psf.upfronthosting.co.za>
2012-08-07 05:34:01ncoghlanlinkissue15216 messages
2012-08-07 05:34:00ncoghlancreate