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 ncoghlan
Recipients barry, belopolsky, benjamin.peterson, cben, eric.araujo, ezio.melotti, flox, georg.brandl, gvanrossum, jcea, lemburg, loewis, ncoghlan, pconnell, petri.lehtinen, r.david.murray, ssbarnea, vstinner
Date 2013-04-23.14:55:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1366728955.72.0.784422005178.issue7475@psf.upfronthosting.co.za>
In-reply-to
Content
If transform is a method, how do you plan to accept arbitrary buffer supporting types as input?

This is why I mentioned memoryview: it doesn't provide decode(), but there's no good reason you should have to copy the data from the view before decoding it. Similarly, you shouldn't have to make an unaltered copy before creating a compressed (or decompressed) copy.

With codecs.encode and codecs.decode as functions, supporting memoryview as an input for bytes->str decoding, binary->bytes encoding (e.g. gzip compression) and binary->bytes decoding (e.g. gzip decompression) is trivial. Ditto for array.array and anything else that supports the buffer protocol.

With transform/untransform as methods? No such luck.

And once you're using functions rather than methods, it's best to define the API as object -> object, and leave any type constraints up to the individual codecs (with the error handling improved to provide more context and a more meaningful exception type, as I described earlier in the thread)
History
Date User Action Args
2013-04-23 14:55:55ncoghlansetrecipients: + ncoghlan, lemburg, gvanrossum, loewis, barry, georg.brandl, jcea, cben, belopolsky, vstinner, benjamin.peterson, ezio.melotti, eric.araujo, r.david.murray, ssbarnea, flox, petri.lehtinen, pconnell
2013-04-23 14:55:55ncoghlansetmessageid: <1366728955.72.0.784422005178.issue7475@psf.upfronthosting.co.za>
2013-04-23 14:55:55ncoghlanlinkissue7475 messages
2013-04-23 14:55:55ncoghlancreate