Joel Bender writes:
> > Fiddling with the name of the antonym doesn't help.
> > The direction of "untransform" or whatever it's
> > called is only as clear as the direction of
> > "transform".
>
> How about making the transformation parameter more descriptive?
>
> gzipped = plaintext.transform(plaintext_to_gzip)
> plaintext = gzipped.transform(gzip_to_plaintext)
+1
But why be verbose *and* ignore the vernacular?
gzipped = plaintext.transform('gzip')
plaintext = gzipped.transform('gunzip')
I think the style should be EIBTI for "private" protocols, and TOOWDTI
for transforms that wrap well-known libraries.
> I would rather have one function that can do lots of different
> transformations, the same name can be used for bytes and strings,
This is a non-starter, because you don't know what the representation
of strings is. We could be right-thinking and mandate that in the
.transform() context the string representation is considered
big-endian (and for little-endian platforms the bytes are swabbed
before applying the transformation). But that would annoy all the
Wintel users because string.transform('zip') would produce gobbledgook
when unzipped from the command line. And of course assuming a little-
endian representation is un-right-thinkable.<wink>
In this sense string-to-string and byte-to-byte *must* be kept
separate from "true" codecs. I think it would be a very bad idea to
allow names to be shared for, say, byte-to-byte and string-to-byte
"gzip" for the reason given above.
Whether string-to-string and byte-to-byte need to share a namespace is
another question, but since we already need three (string->byte,
byte->string, byte->byte) that should be forced not to collide, I
don't think that there's that big a loss in requiring that
.transform('pig_latin') (string to string) be spelled differently from
.transform('pig_latin1') (byte to byte assuming ISO 8859/1 data).
Do you have use cases where byte-to-byte and string-to-string
transformations should share the same name?
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
