Éric Araujo mer...@netwok.org added the comment:
There were comments by Ezio and me on Rietveld.
Also, the commit adds a period after the help text for --encoding, but all
other help text aren’t capitalized and don’t use periods, as is usual in help
messages.
--
Hello Éric,
I might have ignored some minor stylistic comments. The '.' in the help text
and , after the last TestName, I am not sure if it is of concern.
I think, to update the stylistic comments, if the submitters (if they
care) could have updated the patch, or a separate commit on style
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 9fc7ef60ea06 by Senthil Kumaran in branch '3.2':
Fix closes Issue10087 - fixing the output of calendar display in the html
format. Patch by Chris Lambacher. Test Contributed by catherine.
Antoine Pitrou pit...@free.fr added the comment:
Le Mon, 08 Aug 2011 10:46:20 +,
Senthil Kumaran rep...@bugs.python.org a écrit :
Antoine - I was specifically interested to know if
sys.stdout.buffer.write as in the patch was good(/proper) way to go
forward writing the bytes?
Yes, it
Senthil Kumaran sent...@uthcode.com added the comment:
I agree with Chris's point that people using html format in console are
probably redirecting to a file and encoding parameter should be helpful.
What do we settle upon? Leave the encoding argument as such?
Antoine - I was specifically
Changes by STINNER Victor victor.stin...@haypocalc.com:
--
nosy: -haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10087
___
___
Senthil Kumaran sent...@uthcode.com added the comment:
Chris, as you already suggested in msg124410, I would prefer the removal of
encoding specification from command line. Providing the encoding argument via
API with deprecating warning is a good idea.
The output should be string and it
Chris Lambacher ch...@kateandchris.net added the comment:
Senthil: I wasn't advocating the removal of the ability to specify encoding,
only stating that avoiding the use of sys.stdout.buffer.write could only
sensibly be done if we also removed the ability to specify an encoding (I can
see how
Antoine Pitrou pit...@free.fr added the comment:
I don't think WARNING: this may corrupt your terminal is warranted. Also, I
think we can safely remove the --encoding option. Calling a module from the
command-line is intended as a demonstration of the module's functionality, it's
not an
Senthil Kumaran sent...@uthcode.com added the comment:
FWIW, I think removing the encoding facility (more so because it can interfere
with the terminal encoding) and just dealing with strings to output the html
version of calendar seems a neater way than definiing write =
Ezio Melotti ezio.melo...@gmail.com added the comment:
BTW, accessing sys.stdout.buffer is not really safe, because if sys.stdout has
been replaced with some other object, the buffer attribute might not be
available (IIRC StringIO doesn't have it).
--
Chris Lambacher ch...@kateandchris.net added the comment:
Senthil: I think that would fundamentally make things worse. The HTML calendar
apparently always provides a bytes type, but lets assume it provided you with
unicode and we used sys.stdout.write on the output. Fundamentally you would get
Éric Araujo mer...@netwok.org added the comment:
Patch looks good. I made a few very minor style comments on Rietveld (follow
the “review” link).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10087
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10087
___
___
Catherine Devlin fredv8vi...@liquidid.net added the comment:
Very simplistic patch to test_calendar.py that adds a test for this fix. This
fails on the unpatched trunk b/c the unpatched output begins with bb'?xm
instead of b?xml . Test needs a quick review... I'm not familiar with the
Changes by Ron Adam ron_a...@users.sourceforge.net:
--
nosy: +ron_adam
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10087
___
___
Ron Adam ron_a...@users.sourceforge.net added the comment:
The problem is in the following line...
return ''.join(v).encode(encoding, xmlcharrefreplace)
The .encode(encoding, xmlcharrefreplace) is returning a bytes object.
Here is the simplest change to resolve the problem.
return
Chris Lambacher ch...@kateandchris.net added the comment:
Sorry in advance for the long winded response.
Ron, have you looked at my patch?
The underlying issue is that the semantics for print() between Python 1 and 3.
print() does not accept a bytes type in Python 3. In Python 2 str was a
Ron Adam ron_a...@users.sourceforge.net added the comment:
Oops. You're right.
I miss understood how the encode method works in this particular case. ;-/
I agree with your comments as well.
--
___
Python tracker rep...@bugs.python.org
Chris Lambacher ch...@kateandchris.net added the comment:
I don't think we *need* to have the encoding in the HTML calendar, but I doubt
we could remove it at this point, deprecate maybe, but since I don't use the
module I don't have a sense for how often the need for encoding comes up.
The
Chris Lambacher ch...@kateandchris.net added the comment:
I don't understand what you mean by elides the line breaks in output. They
are still there, you just don't see them as \n because print() is no longer
implicitly converting the bytes to a string (which appears to actually result
in a
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10087
___
___
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
Chris Lambacher ch...@kateandchris.net added the comment:
I am attaching a new patch which fixes the majority of the comments raised.
1. Any suggestions about how to test the output of the console program (the
case that this bug affects) would be appreciated.
2. Agreed, included in the output
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Mon, Nov 22, 2010 at 11:55 AM, Chris Lambacher
rep...@bugs.python.org wrote:
..
1. Any suggestions about how to test the output of the console program (the
case that this bug affects)
would be appreciated.
For month
Chris Lambacher ch...@kateandchris.net added the comment:
The test_pydoc method looks workable, but I'll need to come back to it later
because I don't have any more time to work on it today.
--
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I wonder: do we really need encoding option to the calendar output? It is
really not the job of the calendar module to deal with encodings. The calendar
module should produce text calendars as unicode strings and HTML
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10087
___
___
Chris Lambacher ch...@kateandchris.net added the comment:
I have attached a patch that conditionally uses sys.stdout.buffer.write to
output binary (encoded) data to stdout.
--
nosy: +lambacck
Added file: http://bugs.python.org/file19768/calendar_bytes_output.patch
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
It may be acceptable, but your patch elides the line breaks in output. Can you
add unit tests?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10087
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10087
___
___
Python-bugs-list
New submission from Alexander Belopolsky belopol...@users.sourceforge.net:
$ python3 -m calendar --type=html 2010
Produces HTML which renders into the attached PDF file. It looks like bytes
vs. strings issue.
--
assignee: belopolsky
components: Library (Lib)
files: Calendar for
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
The issue is clearly with using print() for bytes' output:
if len(args) == 1:
print(cal.formatyearpage(datetime.date.today().year, **optdict))
I am not sure, however how this can be fixed because
Walter Dörwald wal...@livinglogic.de added the comment:
Does the following patch fix your problems?
--
keywords: +patch
nosy: +doerwalter
Added file: http://bugs.python.org/file19217/calendar.diff
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Wed, Oct 13, 2010 at 12:20 PM, Walter Dörwald rep...@bugs.python.org wrote:
..
Does the following patch fix your problems?
Probably not because with your patch print() will encode HTML stream
with the system default
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
There is a similar issue with printing text calendar with specified encoding:
$ python3 -m calendar --encoding=utf8
b' 2010\n\n ..
--
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Note that .decode(encoding) calls have been deliberately removed in py3k: see
issue 3059.
--
nosy: +georg.brandl, gpolo
___
Python tracker rep...@bugs.python.org
37 matches
Mail list logo
