Re: [Python-Dev] from __future__ import unicode_strings?
On Thu, 16 Feb 2006 00:36:35 + (UTC), Neil Schemenauer <[EMAIL PROTECTED]> wrote: >I'm in the process of summarizing the dicussion on the bytes object >and an idea just occured to me. Imagine that I want to write code >that deals with strings and I want to be maximally compatible with >P3k. It would be nice if I could add: > >from __future__ import unicode_strings > >and have string literals without a 'u' prefix become unicode >instances. I'm not sure how tricky the implementation would be but >it seems like a useful feature. FWIW, I've considered this before, and superficially at least, it seems attractive. > >An even crazier idea is to have that import change 'str' to be >an alias for 'unicode'. That's further than I went, though :) Until there's a replacement for str, this would make it impossible to do certain things with that __future__ import in effect. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] from __future__ import unicode_strings?
On 2/15/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > I'm in the process of summarizing the dicussion on the bytes object > and an idea just occured to me. Imagine that I want to write code > that deals with strings and I want to be maximally compatible with > P3k. It would be nice if I could add: > > from __future__ import unicode_strings > > and have string literals without a 'u' prefix become unicode > instances. I'm not sure how tricky the implementation would be but > it seems like a useful feature. Didn't we have a command-line option to do this? I believe it was removed because nobody could see the point. (Or am I hallucinating? After several days of non-stop discussing bytes that must be considered a possibility.) Of course a per-module switch is much more useful. > An even crazier idea is to have that import change 'str' to be > an alias for 'unicode'. Now *that's* crazy talk. :-) It's probably easier to do that by placing a line str = unicode at the top of the file. Of course (like a good per-module switch should!) this won't affect code in other modules that you invoke so it's not clear that it always does the right thing. But it's a start. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] from __future__ import unicode_strings?
On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote: > > from __future__ import unicode_strings > Didn't we have a command-line option to do this? I believe it was > removed because nobody could see the point. (Or am I hallucinating? > After several days of non-stop discussing bytes that must be > considered a possibility.) We do, and it's not been removed: the -U switch. Python 2.3.5 (#2, Nov 21 2005, 01:27:27) >>> "" u'' Python 2.4.2 (#2, Nov 21 2005, 02:24:28) >>> "" u'' Python 2.5a0 (trunk:42390, Feb 16 2006, 00:12:03) >>> "" u'' I've never seen it *used*, though, and IIRC there were quite a number of stdlib modules that broke when you used it, at least back when it was introduced. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] from __future__ import unicode_strings?
On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote: > On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote: > > > > from __future__ import unicode_strings > > > Didn't we have a command-line option to do this? I believe it was > > removed because nobody could see the point. (Or am I hallucinating? > > After several days of non-stop discussing bytes that must be > > considered a possibility.) > > We do, and it's not been removed: the -U switch. As Guido alluded, the global switch is useless. A per-module switch something that could actually useful. One nice advantage is that you would write code that works the same with Jython (wrt to string literals anyhow). Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] from __future__ import unicode_strings?
Thomas Wouters <[EMAIL PROTECTED]> wrote: >>> from __future__ import unicode_strings > >> Didn't we have a command-line option to do this? I believe it was >> removed because nobody could see the point. (Or am I hallucinating? >> After several days of non-stop discussing bytes that must be >> considered a possibility.) > > We do, and it's not been removed: the -U switch. It's not in the output of "python -h", though. Is it secret or what? Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] from __future__ import unicode_strings?
Neil Schemenauer wrote: > On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote: >> On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote: >> from __future__ import unicode_strings >>> Didn't we have a command-line option to do this? I believe it was >>> removed because nobody could see the point. (Or am I hallucinating? >>> After several days of non-stop discussing bytes that must be >>> considered a possibility.) >> We do, and it's not been removed: the -U switch. > > As Guido alluded, the global switch is useless. A per-module switch > something that could actually useful. One nice advantage is that > you would write code that works the same with Jython (wrt to string > literals anyhow). The global switch is not useless. It's purpose is to test the standard library (or any other piece of Python code) for Unicode compatibility. Since we're not even close to such compatibility, I'm not sure how useful a per-module switch would be. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 16 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] from __future__ import unicode_strings?
On Thu, 16 Feb 2006 11:24:35 +0100, "M.-A. Lemburg" <[EMAIL PROTECTED]> wrote: >Neil Schemenauer wrote: >> On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote: >>> On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote: >>> > from __future__ import unicode_strings Didn't we have a command-line option to do this? I believe it was removed because nobody could see the point. (Or am I hallucinating? After several days of non-stop discussing bytes that must be considered a possibility.) >>> We do, and it's not been removed: the -U switch. >> >> As Guido alluded, the global switch is useless. A per-module switch >> something that could actually useful. One nice advantage is that >> you would write code that works the same with Jython (wrt to string >> literals anyhow). > >The global switch is not useless. It's purpose is to test the >standard library (or any other piece of Python code) for Unicode >compatibility. > >Since we're not even close to such compatibility, I'm not sure >how useful a per-module switch would be. Just what Neil suggested: developers writing new code benefit from having the behavior which will ultimately be Python's default, rather than the behavior that is known to be destined for obsolescence. Being able to turn this on per-module is useful for the same reason the rest of the future system is useful on a per-module basis. It's easier to convert things incrementally than monolithicly. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] from __future__ import unicode_strings?
Giovanni Bajo wrote: > Thomas Wouters <[EMAIL PROTECTED]> wrote: > from __future__ import unicode_strings >>> Didn't we have a command-line option to do this? I believe it was >>> removed because nobody could see the point. (Or am I hallucinating? >>> After several days of non-stop discussing bytes that must be >>> considered a possibility.) >> We do, and it's not been removed: the -U switch. > > > It's not in the output of "python -h", though. Is it secret or what? Yes. We removed it from the help output to not confuse users who are not aware of the fact that this is an experimental switch. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 16 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] from __future__ import unicode_strings?
Jean-Paul Calderone wrote: > On Thu, 16 Feb 2006 11:24:35 +0100, "M.-A. Lemburg" <[EMAIL PROTECTED]> wrote: >> Neil Schemenauer wrote: >>> On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote: On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote: >> from __future__ import unicode_strings > Didn't we have a command-line option to do this? I believe it was > removed because nobody could see the point. (Or am I hallucinating? > After several days of non-stop discussing bytes that must be > considered a possibility.) We do, and it's not been removed: the -U switch. >>> As Guido alluded, the global switch is useless. A per-module switch >>> something that could actually useful. One nice advantage is that >>> you would write code that works the same with Jython (wrt to string >>> literals anyhow). >> The global switch is not useless. It's purpose is to test the >> standard library (or any other piece of Python code) for Unicode >> compatibility. >> >> Since we're not even close to such compatibility, I'm not sure >> how useful a per-module switch would be. > > Just what Neil suggested: developers writing new code benefit from having the > behavior which will ultimately be Python's default, rather than the behavior > that is known to be destined for obsolescence. > > Being able to turn this on per-module is useful for the same reason the rest > of the future system is useful on a per-module basis. It's easier to convert > things incrementally than monolithicly. Sure, but in this case the option would not only affect the module you define it in, but also all other code that now gets Unicode objects instead of strings as a result of the Unicode literals defined in these modules. It is rather likely that you'll start hitting Unicode-related compatibility bugs in the standard lib more often than you'd like. It's usually better to switch to Unicode in a controlled manner: not by switching all literals to Unicode, but only some, then test things, then switch over some more, etc. This can be done by prepending the literal with the u"" modifier. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 16 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] from __future__ import unicode_strings?
On Thu, 16 Feb 2006 16:29:40 +0100, "M.-A. Lemburg" <[EMAIL PROTECTED]> wrote: >Jean-Paul Calderone wrote: >> On Thu, 16 Feb 2006 11:24:35 +0100, "M.-A. Lemburg" <[EMAIL PROTECTED]> >> wrote: >>> Neil Schemenauer wrote: On Thu, Feb 16, 2006 at 02:43:02AM +0100, Thomas Wouters wrote: > On Wed, Feb 15, 2006 at 05:23:56PM -0800, Guido van Rossum wrote: > >>> from __future__ import unicode_strings >> Didn't we have a command-line option to do this? I believe it was >> removed because nobody could see the point. (Or am I hallucinating? >> After several days of non-stop discussing bytes that must be >> considered a possibility.) > We do, and it's not been removed: the -U switch. As Guido alluded, the global switch is useless. A per-module switch something that could actually useful. One nice advantage is that you would write code that works the same with Jython (wrt to string literals anyhow). >>> The global switch is not useless. It's purpose is to test the >>> standard library (or any other piece of Python code) for Unicode >>> compatibility. >>> >>> Since we're not even close to such compatibility, I'm not sure >>> how useful a per-module switch would be. >> >> Just what Neil suggested: developers writing new code benefit from having >> the behavior which will ultimately be Python's default, rather than the >> behavior that is known to be destined for obsolescence. >> >> Being able to turn this on per-module is useful for the same reason the rest >> of the future system is useful on a per-module basis. It's easier to >> convert things incrementally than monolithicly. > >Sure, but in this case the option would not only affect the module >you define it in, but also all other code that now gets Unicode >objects instead of strings as a result of the Unicode literals >defined in these modules. This is precisely correct. It is also exactly parallel to the only other __future__ import which changes any behavior. Personally, I _also_ like future division. Is it generally considered to have been a mistake? > >It is rather likely that you'll start hitting Unicode-related >compatibility bugs in the standard lib more often than you'd >like. You can guess this. I'll guess that it isn't the case. And who's to say how often I'd like that to happen, anyway? :) Anyone who's afraid that will happen can avoid using the import. Voila, problem solved. > >It's usually better to switch to Unicode in a controlled manner: >not by switching all literals to Unicode, but only some, then >test things, then switch over some more, etc. There's nothing uncontrolled about this proposed feature, so this statement doesn't hold any meaning. > >This can be done by prepending the literal with the u"" modifier. > Anyone who is happier converting one string literal at a time can do this. Anyone who would rather convert a module at a time can use the future import. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
