Should Python support \e in strings for the ESC control character, ASCII 0x1B (27)? \e is supported by Perl, PHP, Ruby, and although it is not standard C, gcc: http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Character-Escapes.html I have the Python Pocket Reference, by Mark Lutz, 1st Edition from 1998, which lists \e as a string escape code. I don't know if that was a mistake, or if \e used to be supported prior to 1.5 but was then removed. -- Steven
On 06/11/2013 09:22 AM, Steven D'Aprano wrote:
Should Python support \e in strings for the ESC control character, ASCII 0x1B (27)?
\e is supported by Perl, PHP, Ruby, and although it is not standard C, gcc:
http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Character-Escapes.html
I have the Python Pocket Reference, by Mark Lutz, 1st Edition from 1998, which lists \e as a string escape code. I don't know if that was a mistake, or if \e used to be supported prior to 1.5 but was then removed.
+1 to have it (back?) -- ~Ethan~
On 11/06/2013 17:22, Steven D'Aprano wrote:
Should Python support \e in strings for the ESC control character, ASCII 0x1B (27)?
\e is supported by Perl, PHP, Ruby, and although it is not standard C, gcc:
http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Character-Escapes.html
I have the Python Pocket Reference, by Mark Lutz, 1st Edition from 1998, which lists \e as a string escape code. I don't know if that was a mistake, or if \e used to be supported prior to 1.5 but was then removed.
I wouldn't say no, but, on the other hand, it has been a very long time since I personally have used it. In other words, is there sufficient demand for it?
On 12/06/13 03:02, MRAB wrote:
On 11/06/2013 17:22, Steven D'Aprano wrote:
Should Python support \e in strings for the ESC control character, ASCII 0x1B (27)?
\e is supported by Perl, PHP, Ruby, and although it is not standard C, gcc:
http://gcc.gnu.org/onlinedocs/gcc-3.1/gcc/Character-Escapes.html
I have the Python Pocket Reference, by Mark Lutz, 1st Edition from 1998, which lists \e as a string escape code. I don't know if that was a mistake, or if \e used to be supported prior to 1.5 but was then removed.
I wouldn't say no, but, on the other hand, it has been a very long time since I personally have used it. In other words, is there sufficient demand for it?
I use it often enough to miss having \e, but not often enough to remember what the hex or octal code for ESC is. -- Steven
11.06.13 20:10, Steven D'Aprano написав(ла):
On 12/06/13 03:02, MRAB wrote:
I wouldn't say no, but, on the other hand, it has been a very long time since I personally have used it. In other words, is there sufficient demand for it?
I use it often enough to miss having \e, but not often enough to remember what the hex or octal code for ESC is.
In such case perhaps \N{ESCAPE} is more helpful for you.
On 11.06.2013 20:12, Alexander Belopolsky wrote:
On Tue, Jun 11, 2013 at 1:10 PM, Steven D'Aprano <steve@pearwood.info>wrote:
I use it often enough to miss having \e, but not often enough to remember what the hex or octal code for ESC is.
+1
ANSI colors at the shell prompt are getting popular again these days.
How would you add a new escape character in a backwards compatible way ? Adding new escape characters is not easy, since Python defaults to passing them through as-is, e.g. '\e' == '\\e'. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 11 2013)
Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2013-07-01: EuroPython 2013, Florence, Italy ... 20 days to go 2013-07-16: Python Meeting Duesseldorf ... 35 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Wed, Jun 12, 2013 at 4:16 AM, M.-A. Lemburg <mal@egenix.com> wrote:
How would you add a new escape character in a backwards compatible way ?
Adding new escape characters is not easy, since Python defaults to passing them through as-is, e.g. '\e' == '\\e'.
My understanding of [1] is that the feature of keeping them unchanged is meant to be a debugging aid, not something you depend on. Use of unescaped backslashes in non-raw string literals is already dangerous to editing (if someone changes your Windows path name to c:\testing, your code is broken). If a new version breaks someone's non-raw literal "c:\everything", it was already broken. [1] http://docs.python.org/3/reference/lexical_analysis.html#literals ChrisA
On 11 June 2013 19:36, Chris Angelico <rosuav@gmail.com> wrote:
On Wed, Jun 12, 2013 at 4:16 AM, M.-A. Lemburg <mal@egenix.com> wrote:
How would you add a new escape character in a backwards compatible way ?
Adding new escape characters is not easy, since Python defaults to passing them through as-is, e.g. '\e' == '\\e'.
My understanding of [1] is that the feature of keeping them unchanged is meant to be a debugging aid, not something you depend on. Use of unescaped backslashes in non-raw string literals is already dangerous to editing (if someone changes your Windows path name to c:\testing, your code is broken). If a new version breaks someone's non-raw literal "c:\everything", it was already broken.
[1] http://docs.python.org/3/reference/lexical_analysis.html#literals
Reading that I see no specific mention that an auto-escaped backslash is incorrect -- just that it is useful for debugging. I have also read that they were put in place largely to make it difficult to add new escapes to prevent an unwanted proliferation of them. I see no reason for a quick "\e" where "\N{ESCAPE}" works and whenever you'll want a lot there's a weird circumstance involved better served by a quick library (as I've done above).
On 11.06.2013 20:36, Chris Angelico wrote:
On Wed, Jun 12, 2013 at 4:16 AM, M.-A. Lemburg <mal@egenix.com> wrote:
How would you add a new escape character in a backwards compatible way ?
Adding new escape characters is not easy, since Python defaults to passing them through as-is, e.g. '\e' == '\\e'.
My understanding of [1] is that the feature of keeping them unchanged is meant to be a debugging aid, not something you depend on. Use of unescaped backslashes in non-raw string literals is already dangerous to editing (if someone changes your Windows path name to c:\testing, your code is broken). If a new version breaks someone's non-raw literal "c:\everything", it was already broken.
[1] http://docs.python.org/3/reference/lexical_analysis.html#literals
I'm not saying that it's useful to rely on Python's behavior, only that any such change has the potential to break perfectly working code. The last time we changed the escape code was for the introduction of Unicode string literals. That was 13 years ago. And we carefully checked what other languages were using for Unicode at the time. Given that \e only saves you two key strokes (\033 and \x1b are the usual ways to write ESC in ASCII strings), I think the ratio between usefulness and potential breakage is not in favor of an addition. BTW: pylint detects such unsupported escape codes: http://docs.pylint.org/features.html?highlight=w1401#string-constant-checker -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 11 2013)
Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2013-07-01: EuroPython 2013, Florence, Italy ... 20 days to go 2013-07-16: Python Meeting Duesseldorf ... 35 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
11.06.13 23:21, M.-A. Lemburg написав(ла):
I'm not saying that it's useful to rely on Python's behavior, only that any such change has the potential to break perfectly working code.
The last time we changed the escape code was for the introduction of Unicode string literals. That was 13 years ago. And we carefully checked what other languages were using for Unicode at the time.
Note that in the same time \u means "Titlecase next character" and \U means "Uppercase till \E" in Perl. "Conforming with other languages" argument is not very suitable in this particular case. I'm -0.5. On one hand, I'm not worrying about backward compatibility, -- behavior of \e is not promised once for all, and there are no good reasons to use it (unlikely to backslashing non-letters). On other hands, it adds complexity (look at mess of dozens special escapes in Perl), the range of applications for this feature is enough narrow, and there are good alternatives (\x1b for shortness and \N{ESCAPE} for mnemonicity).
On 12.06.2013 08:58, Serhiy Storchaka wrote:
11.06.13 23:21, M.-A. Lemburg написав(ла):
I'm not saying that it's useful to rely on Python's behavior, only that any such change has the potential to break perfectly working code.
The last time we changed the escape code was for the introduction of Unicode string literals. That was 13 years ago. And we carefully checked what other languages were using for Unicode at the time.
Note that in the same time \u means "Titlecase next character" and \U means "Uppercase till \E" in Perl. "Conforming with other languages" argument is not very suitable in this particular case.
Perl was not available as reference, since they had started thinking about these things at the same time we did. Since Java was the first major language to implement Unicode at the time, we followed their approach. Turned out to be a good choice, since C++ added the same notation in C++11. http://en.cppreference.com/w/cpp/language/escape
I'm -0.5. On one hand, I'm not worrying about backward compatibility, -- behavior of \e is not promised once for all, and there are no good reasons to use it (unlikely to backslashing non-letters). On other hands, it adds complexity (look at mess of dozens special escapes in Perl), the range of applications for this feature is enough narrow, and there are good alternatives (\x1b for shortness and \N{ESCAPE} for mnemonicity).
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 12 2013)
Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2013-07-01: EuroPython 2013, Florence, Italy ... 19 days to go 2013-07-16: Python Meeting Duesseldorf ... 34 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On 11 June 2013 19:12, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:
ANSI colors at the shell prompt are getting popular again these days.
I just use: ### CODE ### """ Adapted from pygments.console Format colored console output. :copyright: Copyright 2006-2009 by the Pygments team, see AUTHORS. :license: BSD, see LICENSE for details. """ def load(): global codes codes = { "reset": "\N{ESCAPE}[39;49;00m", "bold": "\N{ESCAPE}[01m", "faint": "\N{ESCAPE}[02m", "standout": "\N{ESCAPE}[03m", "underline": "\N{ESCAPE}[04m", "blink": "\N{ESCAPE}[05m", "overline": "\N{ESCAPE}[06m" } dark_colors = "black", "darkred", "darkgreen", "brown", "darkblue", "purple", "teal", "lightgray" light_colors = "darkgray", "red", "green", "yellow", "blue", "fuchsia", "turquoise", "white" for i, (dark, light) in enumerate(zip(dark_colors, light_colors), 30): codes[dark] = "\N{ESCAPE}[{}m" .format(i) codes[light] = "\N{ESCAPE}[{};01m".format(i) codes["darkteal"] = codes["turquoise"] codes["darkyellow"] = codes["brown"] codes["fuscia"] = codes["fuchsia"] codes["white"] = codes["bold"] def unload(): global codes codes = {code:"" for code in codes} load() ### END CODE ### And then write stuff like: "{yellow}This is yellow!{reset} {bold}And{reset} this is not!".format(**codes)
When I sent my +1, I was under impression that \e was standardized by POSIX. (I only checked man printf.) It turns out, < http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html#tagtcjh_2>, that \e is not on the list. While I wish I could copy my bash ANSI coloring codes directly into python, I can live with the available alternatives. Consider me +0. On Tue, Jun 11, 2013 at 2:12 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
On Tue, Jun 11, 2013 at 1:10 PM, Steven D'Aprano <steve@pearwood.info>wrote:
I use it often enough to miss having \e, but not often enough to remember what the hex or octal code for ESC is.
+1
ANSI colors at the shell prompt are getting popular again these days.
From: Alexander Belopolsky <alexander.belopolsky@gmail.com> Sent: Tuesday, June 11, 2013 2:28 PM
While I wish I could copy my bash ANSI coloring codes directly into python, I can live with the available alternatives. Consider me +0.
When copying and pasting a big mess of preformatted strings, you generally have to tack a .replace('\\e', '\033') onto the end (or, if it's a list of separate strings, map that over the list). Mildly annoying, but it doesn't come up often enough to be worth changing things. And for any case _other_ than copying and pasting a big mess of pre-formatted strings into Python code, you're much better off with a library or a format dict (like the one Joshua Landau just posted). So, I'm -0.
participants (9)
-
Alexander Belopolsky -
Andrew Barnert -
Chris Angelico -
Ethan Furman -
Joshua Landau -
M.-A. Lemburg -
MRAB -
Serhiy Storchaka -
Steven D'Aprano