[issue21957] ASCII Formfeed (FF) & ASCII Vertical Tab (VT) Have Hexadecimal Representation

[Stephen Paul Chappell]

New submission from Stephen Paul Chappell:

In the string module, the definition of whitespace is ' \t\n\r\v\f'. However, 
the representation of string.whitespace is ' \t\n\r\x0b\x0c'. Would it be 
terribly inconvenient to change the representation of '\x0b\x0c' to '\v\f'? The 
documentation at 
https://docs.python.org/3.4/reference/lexical_analysis.html#string-and-bytes-literals
 lists recognized escape sequences, but string represetations seem to diverge 
slightly from what is recognized. The same "problem" exists with the 
representation of bytes.

--
messages: 222749
nosy: Zero
priority: normal
severity: normal
status: open
title: ASCII Formfeed (FF) & ASCII Vertical Tab (VT) Have Hexadecimal 
Representation
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21957] ASCII Formfeed (FF) & ASCII Vertical Tab (VT) Have Hexadecimal Representation

[Ned Deily]

Ned Deily added the comment:

I am not sure why the string reprs for FF and VT are not special-cased to \f 
and \v but they are not alone: \a (BEL) and \b (BS) are also not special-cased. 
 My guess is that it was for performance reasons but perhaps someone with a 
longer memory can comment.  As now implemented, supporting these special cases 
would add checks for each for every character being encoded, a critical path 
for many applications, and in most cases, CR, LF, and HT are much more likely 
to be encountered.  I also don't see where this behavior is documented anywhere 
but it goes back a long way, probably to the earliest days of Python and, in 
general, Python does not make any promises about which of any valid 
representations for particular characters will be used.  While, on the one 
hand, it would make some string reprs look cleaner, on the other hand there are 
downsides: the risks of breaking existing code that might depend on the 
long-standing behavior, the potential performance impact that would need to be 
 measured and mitigated, and the cost to develop and test.  In balance, I think 
the risks outweigh any benefit so I think we should not pursue this change.  If 
others feel differently, feel free to reopen.  In any case, thanks for the 
suggestion.

--
nosy: +ned.deily
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21957] ASCII Formfeed (FF) & ASCII Vertical Tab (VT) Have Hexadecimal Representation

[Stephen Paul Chappell]

Change by Stephen Paul Chappell :


--
nosy:  -Zero

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com