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 Nick Barnes
Recipients Nick Barnes, lemburg, pitrou, vstinner
Date 2008-12-01.14:02:08
SpamBayes Score 3.92175e-06
Marked as misclassified No
Message-id <1228140130.88.0.252207691297.issue4426@psf.upfronthosting.co.za>
In-reply-to
Content
My original defect report here was incorrect, or possibly only relates
to a particular older Python installation.  It is still the case that
UTF-7 decoding is fussier than it need be (decoding should be
permissive), and is broken specifically for the '/' character (ASCII
47).  I'm probably going to rewrite the whole codec for greater clarity
and decoding permissiveness.

Any UTF-7 encoder has two boolean parameters: whether to base-64 encode
whitespace (sp, ht, nl, cr), and whether to base-64 encode "set O"
characters.  The existing Python UTF-7 encoder says "no" to both of
these.  It would be useful to have them as options.  How should encoding
parameters such as these be passed?  As setstate() methods on the
IncrementalEncoder and StreamWriter objects?  Or should I provide four
separate codecs (retaining the existing behaviour in the 'utf7' codec,
of course).
History
Date User Action Args
2008-12-01 14:02:10Nick Barnessetrecipients: + Nick Barnes, lemburg, pitrou, vstinner
2008-12-01 14:02:10Nick Barnessetmessageid: <1228140130.88.0.252207691297.issue4426@psf.upfronthosting.co.za>
2008-12-01 14:02:09Nick Barneslinkissue4426 messages
2008-12-01 14:02:08Nick Barnescreate