homepage

In Python 2.6 we have
>>> types.StringTypes
(<type 'str'>, <type 'unicode'>)
but 2to3 translates "types.StringTypes" into "str", which is obviously
wrong. The attached patch changes it into "(str, bytes)".

It's hard to guess the intention of types.StringTypes since it may mean
"text" strings or "text and byte" strings. I'm tempted to just remove
the transformation at all and issue a warning.

I agree with Benjamin. Translation into (str, bytes) is incorrect. I
don't agree that it is obvious that the translation into str is incorrect.
Recommend closing as reject.

Why I considered the existing translation incorrect was because it
translates something which was a tuple of types in Python 2.x into a
type of Python 3.x. I fail to see how this can be useful. (A check like
"x in types.StringTypes" gets translated into "x in str", which will
always fail.)
I agree that translating into "(str, bytes)" won't always be correct,
but it seems to have a much better chance of being correct than the
existing translation into "str". Otherwise it should at least be "(str,)".

> Why I considered the existing translation incorrect was because it
> translates something which was a tuple of types in Python 2.x into a
> type of Python 3.x. I fail to see how this can be useful. 
It would translate "isinstance(x, types.StringTypes)" correctly. I agree
that translating to a tuple would be correct in more cases.

I can see the merit of not including "bytes" in StringTypes, but then
the translation of StringType should be changed accordingly. How about
changing the present
StringType -> bytes
StringTypes -> str
into
StringType -> str
StringTypes -> (str,)

I think Hagen's initial analysis makes more sense: the translation is
currently guessing that the user meant the more restrict (text) alternative.
IMHO it doesn't make much sense to have this:
>>> strings = (types.StringType, types.UnicodeType)
>>> strings == types.StringTypes
True
Translated to this:
strings = (bytes, str)
strings == str

The automatic conversion can't be perfect in all cases, but I think my
second suggestion is more in line with the other transformations done by
2to3 (string literals, "str", "basestring" etc.).
I propose applying the second patch, but don't care enough to argue for
it much more if it's rejected.

I'm rejecting this patch again not because I think it's any worse than
the status quo (I think they're about equally incorrect/correct), but
because this is now released behavior and changing it may result in
backwards incompatibility. Also, people can easily remove this ambiguity
in a 2.x compatible fashion by explicitly listing the types (str,) or
(str, unicode) instead of using the types module.