[issue28850] Regression in Python 3: Subclassing PrettyPrinter.format doesn't work anymore

2016-12-01 Thread Michael Enßlin 

New submission from Michael Enßlin:

This issue was previously addressed and fixed here:

http://bugs.python.org/issue1351692

When subclassing PrettyPrinter, overriding the format() method should allow 
users to define custom pretty-printers.

However, for objects whose repr is short, format() is not called for the 
individual members.

Example code that reproduces the issue is as follows:


import pprint
import sys

pprint.pprint(sys.version_info)

class MyPrettyPrinter(pprint.PrettyPrinter):
def format(self, object, context, maxlevels, level):
if isinstance(object, int):
return hex(object), True, False
else:
return pprint.PrettyPrinter.format(self, object, context, 
maxlevels, level)

MyPrettyPrinter().pprint(10)
MyPrettyPrinter().pprint([10])


When run with different versions of Python:


sys.version_info(major=2, minor=7, micro=11, releaselevel='final', serial=0)
0xa
[0xa]

(3, 0, 1, 'final', 0)
0xa
[10]

sys.version_info(major=3, minor=2, micro=5, releaselevel='final', serial=0)
0xa
[10]

sys.version_info(major=3, minor=4, micro=4, releaselevel='final', serial=0)
0xa
[10]

sys.version_info(major=3, minor=6, micro=0, releaselevel='beta', serial=4)
0xa
[10]

You'll notice that the regression exists in all versions >= 3.0,
even though the commit that fixed the issue is still in the log (2008-01-20):
https://hg.python.org/cpython/log/3.0/Lib/pprint.py

I have not had the time to look at the source of the issue or provide a fix; I 
might do so tonight.

--
components: Library (Lib)
messages: 282159
nosy: anthonybaxter, doerwalter, georg.brandl, gvanrossum, markhirota, mic_e, 
rhettinger
priority: normal
severity: normal
status: open
title: Regression in Python 3: Subclassing PrettyPrinter.format doesn't work 
anymore
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

[issue17337] input() and raw_input() do not work correctly with colored prompts

2013-03-15 Thread Michael Enßlin 

Michael Enßlin added the comment:

Terry, i guess you are right; it is indeed not the job of python to know how 
its terminal will print characters; there is a whole lot of issues to consider, 
such as terminal unicode support, control characters, ansi escape sequences, 
terminal-specific escape sequences such as terminal title, etc.
I guess that on UNIX, a lot of that information could be taken from terminfo, 
to provide a method that guesses the length of a text on the terminal that is 
referenced in the $TERM environment variable.

In fact, I think this is a design problem of readline; readline should print 
the prompt, and then try to determine its length via the dedicated escape 
sequence (if it really needs to know the prompt length). In that case, there 
would be no way to fix this in python - apart from re-implementing. In 
conclusion, no, I don't believe the python readline code should be modified, 
maybe an additional, os- and $TERM-dependent method for adding prompt escapes 
should be added.

However, the issue should definitely be documented in the readline 
documentation:
importing readline _will_ break input() if the prompt contains non-printable 
characters that are not escaped by '\x01' and '\x02' characters.

Hence I have changed the bug components to 'Documentation'.

--
assignee:  -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python

___
Python tracker 
<http://bugs.python.org/issue17337>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17337] input() and raw_input() do not work correctly with colored prompts

2013-03-02 Thread Michael Enßlin 

Michael Enßlin added the comment:

The issue might very well be strictly related to GNU readline.

I have both successfully reproduced it in a C program:

#include 
#include 
int main() {
readline("\x1b[31;1mthis is a bold red prompt\x1b[m> ");
}

gcc -lreadline test.c

and found a fix, hinted at by this stackoverflow post:
http://stackoverflow.com/questions/9468435/look-how-to-fix-column-calculation-in-python-readline-if-use-color-prompt

Readline uses the characters \x01 and \x02 to mark invisible portions of the 
prompt, so I am now pre-processing the prompt with this function:

def surround_ansi_escapes(prompt, start = "\x01", end = "\x02"):
escaped = False
result = ""

for c in prompt:
if c == "\x1b" and not escaped:
result += start + c
escaped = True
elif c.isalpha() and escaped:
result += c + end
escaped = False
else:
result += c

return result

However, in my opionion this fact deserves at least to be mentioned in the 
readline documentation.

--

___
Python tracker 
<http://bugs.python.org/issue17337>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com