Smoothing transition: 'unicode' and 'basestring' as aliases for 'str'?
I found this in an old post:
Maybe too late now but there should have been 'unicode', 'basestring' as aliases for 'str'.
I guess it is too late to think about it again ... Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/
The thread is here in the archive (https://mail.python.org/ pipermail/python-ideas/2016-June/040761.html) if anyone's wondering context, as I was. In short, someone wanted an alias from string to basestring. This is addressed in the "What's new in Python 3.0" ( https://docs.python.org/3/whatsnew/3.0.html) page:
- The built-in basestring abstract type was removed. Use str <https://docs.python.org/3/library/stdtypes.html#str> instead. The str <https://docs.python.org/3/library/stdtypes.html#str>and bytes <https://docs.python.org/3/library/functions.html#bytes> types don’t have functionality enough in common to warrant a shared base class. The 2to3 tool (see below) replaces every occurrence of basestring with str <https://docs.python.org/3/library/stdtypes.html#str>.
Personally, I have no issue with leaving an alias like this in 2to3, since
adding it to the language feels more like forced backwards compatibility to me. That said, there are more related subtleties on the "What's new in Python 3.0" page, some of which seem less intuitive, so I understand where a desire like this would come from. Would more specific and succinct documentation on this change alone help? -Ryan Birmingham On 3 March 2017 at 06:44, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
I found this in an old post:
Maybe too late now but there should have been 'unicode', 'basestring' as aliases for 'str'.
I guess it is too late to think about it again ...
Regards, Thomas Güttler
-- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
I see no reason to introduce clutter like this at this point in time - code needing to run in both Py 2 nd 3, if not using something like "six" could do: compat.py try: unicode except NameError: unicode = basestring = str elsewhere: from compat import unicode, basestring Or rather: try: unicode else: str = basestring = unicode and from compat import str # therefore having Python3 valid and clear code from here. On 3 March 2017 at 11:37, Ryan Birmingham <rainventions@gmail.com> wrote:
The thread is here in the archive (https://mail.python.org/pipermail/python-ideas/2016-June/040761.html) if anyone's wondering context, as I was.
In short, someone wanted an alias from string to basestring. This is addressed in the "What's new in Python 3.0" (https://docs.python.org/3/whatsnew/3.0.html) page:
The built-in basestring abstract type was removed. Use str instead. The strand bytes types don’t have functionality enough in common to warrant a shared base class. The 2to3 tool (see below) replaces every occurrence of basestring with str.
Personally, I have no issue with leaving an alias like this in 2to3, since adding it to the language feels more like forced backwards compatibility to me.
That said, there are more related subtleties on the "What's new in Python 3.0" page, some of which seem less intuitive, so I understand where a desire like this would come from. Would more specific and succinct documentation on this change alone help?
-Ryan Birmingham
On 3 March 2017 at 06:44, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
I found this in an old post:
Maybe too late now but there should have been 'unicode', 'basestring' as aliases for 'str'.
I guess it is too late to think about it again ...
Regards, Thomas Güttler
-- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
yes, you are right. It's better to leave Python3 clean (without "basestring"). I see two ways now. six ---- six.string_types # replacement for basestring Source https://docs.djangoproject.com/en/1.10/topics/python3/#string-handling-with-... future ------ from past.builtins import basestring # pip install future Source http://python-future.org/compatible_idioms.html#basestring I have no clue which one I should use. Regards, Thomas Am 03.03.2017 um 16:43 schrieb Joao S. O. Bueno:
I see no reason to introduce clutter like this at this point in time - code needing to run in both Py 2 nd 3, if not using something like "six" could do:
compat.py try: unicode except NameError: unicode = basestring = str
elsewhere: from compat import unicode, basestring
Or rather:
try: unicode else: str = basestring = unicode
and from compat import str # therefore having Python3 valid and clear code from here.
On 3 March 2017 at 11:37, Ryan Birmingham <rainventions@gmail.com> wrote:
The thread is here in the archive (https://mail.python.org/pipermail/python-ideas/2016-June/040761.html) if anyone's wondering context, as I was.
In short, someone wanted an alias from string to basestring. This is addressed in the "What's new in Python 3.0" (https://docs.python.org/3/whatsnew/3.0.html) page:
The built-in basestring abstract type was removed. Use str instead. The strand bytes types don’t have functionality enough in common to warrant a shared base class. The 2to3 tool (see below) replaces every occurrence of basestring with str.
Personally, I have no issue with leaving an alias like this in 2to3, since adding it to the language feels more like forced backwards compatibility to me.
That said, there are more related subtleties on the "What's new in Python 3.0" page, some of which seem less intuitive, so I understand where a desire like this would come from. Would more specific and succinct documentation on this change alone help?
-Ryan Birmingham
On 3 March 2017 at 06:44, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
I found this in an old post:
Maybe too late now but there should have been 'unicode', 'basestring' as aliases for 'str'.
I guess it is too late to think about it again ...
Regards, Thomas Güttler
-- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Thomas Guettler http://www.thomas-guettler.de/
Am 06.03.17 um 11:12 schrieb Thomas Güttler:
yes, you are right. It's better to leave Python3 clean (without "basestring").
I see two ways now.
six ----
six.string_types # replacement for basestring
Source https://docs.djangoproject.com/en/1.10/topics/python3/#string-handling-with-...
future ------
from past.builtins import basestring # pip install future
Source http://python-future.org/compatible_idioms.html#basestring
I have no clue which one I should use.
I would recommend future. It gives you a Python-3-like experience in Python 2. Once you fully transition to Python 3, you only need to remove the future imports and you don't have any dependency on it any more. For example: from builtins import bytes, str gives you Python 3 bytes and strings in Python 2. Now, you can replace basestring with str and it works the same in Python 2 and 3. Maybe this works for you. I am pretty happy with future. Best, Mike
Thank you for guiding me, Mike. We see us on CLT this weekend :-) Regards, Thomas Güttler Am 06.03.2017 um 12:01 schrieb Mike Müller:
Am 06.03.17 um 11:12 schrieb Thomas Güttler:
yes, you are right. It's better to leave Python3 clean (without "basestring").
I see two ways now.
six ----
six.string_types # replacement for basestring
Source https://docs.djangoproject.com/en/1.10/topics/python3/#string-handling-with-...
future ------
from past.builtins import basestring # pip install future
Source http://python-future.org/compatible_idioms.html#basestring
I have no clue which one I should use.
I would recommend future. It gives you a Python-3-like experience in Python 2. Once you fully transition to Python 3, you only need to remove the future imports and you don't have any dependency on it any more.
For example:
from builtins import bytes, str
gives you Python 3 bytes and strings in Python 2. Now, you can replace basestring with str and it works the same in Python 2 and 3. Maybe this works for you.
I am pretty happy with future.
Best, Mike
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Thomas Guettler http://www.thomas-guettler.de/
participants (4)
-
Joao S. O. Bueno -
Mike Müller -
Ryan Birmingham -
Thomas Güttler