Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
On Mon, Nov 22, 2010 at 9:48 AM, Chris Lambacher <rep...@bugs.python.org> wrote:
..
> I don't understand what you mean by "elides the line breaks in output".
It is actually not that bad:
$ ./python.exe -m calendar -t html| wc -l
121
$ python2.7 -m calendar -t html| wc -l
122
At first, I thought that html was printed one line at a time, but now
I realize that it is prepared in-memory and printed in one shot. The
extra '\n' in python2.7 is probably a bug in 2.7.
I think this is a reasonable approach. Just a few comments on the patch:
1. Unit tests needed.
2. It may be appropriate to add a warning to the documentation stating
that using -e option may mess up the terminal.
3. In the following snippet, p is an unconditional shortcut to
sys.stdout.buffer.write. I would just call it "write"
optdict = dict(encoding=encoding, css=options.css)
+ p = sys.stdout.buffer.write
4. While white space consistency with 2.7 is not very important, the
following should be fixed, IMO:
$ ./python.exe -m calendar -e ascii| wc -l
35
$ ./python.exe -m calendar| wc -l
36
5. I wonder how ./python.exe -m calendar -e ascii will look on
Windows. I don't think cmd window is smart about displaying unix line
endings.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
