[issue10665] Expand unicodedata module documentation

Changes by Ezio Melotti : -- versions: +Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue10665] Expand unicodedata module documentation

Changes by Ezio Melotti : -- stage: -> patch review type: -> enhancement versions: +Python 3.3 ___ Python tracker ___ ___ Python-bug

[issue10665] Expand unicodedata module documentation

Georg Brandl added the comment: Can y'all please accept the limitation to latin-1? Like Marc-Andre says, the more "exotic" the examples, the less likely it is that users reading the HTML can display it anyway. -- ___ Python tracker

[issue10665] Expand unicodedata module documentation

Alexander Belopolsky added the comment: On Fri, Apr 15, 2011 at 1:23 PM, Marc-Andre Lemburg wrote: >.. > Why not wrap the calls with a repr() ? > Won't help: "'Ӝ'" I think you meant ascii(), but that's ugly IMO: "'\\u04dc'" Maybe '\u04dc' but that's too much of scaffolding. .. > I think

[issue10665] Expand unicodedata module documentation

Alexander Belopolsky added the comment: On Fri, Apr 15, 2011 at 1:10 PM, Marc-Andre Lemburg wrote: >.. > Why don't you use the standard literal escapes for the examples > and annotate the code points with the code point names ? A am neutral on how to enter unicode characters in source reST.

[issue10665] Expand unicodedata module documentation

Marc-Andre Lemburg added the comment: Ezio Melotti wrote: > > Ezio Melotti added the comment: > > One reason is that unicodedata.lookup actually returns a unicode char, so if > we want to show a code snippet that uses unicodedata.lookup we either have to > use a unicode literal or limit the

[issue10665] Expand unicodedata module documentation

Ezio Melotti added the comment: One reason is that unicodedata.lookup actually returns a unicode char, so if we want to show a code snippet that uses unicodedata.lookup we either have to use a unicode literal or limit the chars in the examples to latin1 to make sure it works nice with the PDF

[issue10665] Expand unicodedata module documentation

Marc-Andre Lemburg added the comment: Ezio Melotti wrote: > > Ezio Melotti added the comment: > > Alexander suggested on IRC to use the 'unicode' directive[0], but even if > that works in the HTML (only outside code blocks), it still breaks the PDF. > Another alternative that might work is t

[issue10665] Expand unicodedata module documentation

Alexander Belopolsky added the comment: > The "PDF generator" is PDFLaTeX, whose range of Unicode characters > is very limited, so no, I can't fix it. My search for pdflatex and unicode has quickly revealed this 4-year old howto: http://tclab.kaist.ac.kr/ipe/pdftex_2.html I'll experiment with

[issue10665] Expand unicodedata module documentation

Ezio Melotti added the comment: Alexander suggested on IRC to use the 'unicode' directive[0], but even if that works in the HTML (only outside code blocks), it still breaks the PDF. Another alternative that might work is the 'raw' role[1]. [0]: http://docutils.sourceforge.net/docs/ref/rst/dir

[issue10665] Expand unicodedata module documentation

Ezio Melotti added the comment: FWIW latin-1 chars are fine (e.g. ¶ or è). The right command to build the pdfs is `make latex` and then `make all-pdf` in build/latex/. Alexander, now you could also make a remote hg repo, and use it to generate up-to-date patches that can be reviewed directly

[issue10665] Expand unicodedata module documentation

Georg Brandl added the comment: The "PDF generator" is PDFLaTeX, whose range of Unicode characters is very limited, so no, I can't fix it. -- ___ Python tracker ___ ___

[issue10665] Expand unicodedata module documentation

Ezio Melotti added the comment: I think Georg said that non-ascii chars shouldn't be used directly in the rst files, and one of the reasons is that they break `make pdf` (I haven't tried though). I added him to the nosy. -- nosy: +georg.brandl ___

[issue10665] Expand unicodedata module documentation

STINNER Victor added the comment: > The patch contains non-ascii chars that should be avoided (they break `make > pdf`). What is the error? Can't you fix the PDF generator instead? -- ___ Python tracker

[issue10665] Expand unicodedata module documentation

Ezio Melotti added the comment: The patch contains non-ascii chars that should be avoided (they break `make pdf`). -- ___ Python tracker ___ ___

[issue10665] Expand unicodedata module documentation

Martin v. Löwis added the comment: > Are you going to reject say issue2636 on this basis? :-) Has *any* > patch ever been rejected as incomplete? I certainly did close patches for that reason. Before that, I keep asking people not to post W-I-P. As for issue2636, I have been really tempted to

[issue10665] Expand unicodedata module documentation

Alexander Belopolsky added the comment: On Fri, Dec 10, 2010 at 6:04 PM, Martin v. Löwis wrote: .. >> Why?  I thought "release early, release often" was a good thing. > > Create a branch for that, or post an issue on Rietveld. Martin, This is a documentation patch affecting a single HTML page

[issue10665] Expand unicodedata module documentation

Martin v. Löwis added the comment: > Why? I thought "release early, release often" was a good thing. Create a branch for that, or post an issue on Rietveld. W-I-P IMO confuses people reviewing the patches, running into the same ones over-and-over again, only to find out every time "it's not re

[issue10665] Expand unicodedata module documentation

Alexander Belopolsky added the comment: In issue10665.diff, I completed the character examples in the general categories table. -- Added file: http://bugs.python.org/file20002/issue10665.diff ___ Python tracker _

[issue10665] Expand unicodedata module documentation

Changes by Alexander Belopolsky : -- nosy: +ezio.melotti, haypo, lemburg ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue10665] Expand unicodedata module documentation

Alexander Belopolsky added the comment: On Thu, Dec 9, 2010 at 6:10 PM, Martin v. Löwis wrote: .. > Please, one issue per report and checkin, The s/5.2/6.0/ issue is hardly worth a tracker ticket. I've committed these changes in r87159. (Sorry for the unrelated changes - reverted in the nex