Mailman 3 July 2015 - docs

[issue23220] Documents input/output effects of how IDLE runs user code
by Terry J. Reedy 12 Jul '15

12 Jul '15

Terry J. Reedy added the comment: OK. "Both are true for backspace ('\b') and return ('\r')." ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23220> _______________________________________

1 0

[issue24614] 404 link in Documenting Python, Style Guide
by Julien Maisonneuve 12 Jul '15

12 Jul '15

New submission from Julien Maisonneuve: The link to the Apple Publications Style Guide on this page https://docs.python.org/3.0/documenting/style.html lniks to a 404 page on https://developer.apple.com/ (https://developer.apple.com/library/mac/documentation/UserExperience/Concep…) ---------- assignee: docs@python components: Documentation messages: 246640 nosy: Julien Maisonneuve, docs@python priority: normal severity: normal status: open title: 404 link in Documenting Python, Style Guide versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24614> _______________________________________

2 1

[issue23220] Documents input/output effects of how IDLE runs user code
by Martin Panter 12 Jul '15

12 Jul '15

Martin Panter added the comment: I wouldn’t say TK ignores carriage returns, though I agree it would be better if Idle stripped them out. Currently I get a glyph displayed for them, similarly to \b. They wouldn’t copy to my clipboard, so I fudged them after pasting here: >>> _ = stdout.write("CRLF\r\n") # Linux: box-drawing corner piece CRLF┌ >>> _ = stdout.write("CRLF\r\n") # Wine: euro sign CRLF€ ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23220> _______________________________________

1 0

[issue23220] Documents input/output effects of how IDLE runs user code
by Terry J. Reedy 12 Jul '15

12 Jul '15

Terry J. Reedy added the comment: I was thinking AttributeError, as mentioned in the previous sentence. But you are correct that ImportError is possible too. Maybe I should just give the code. try: import idlelib idlelib.run running_idle = True except (ImportError, AttributeError): running_idle = False tk does not 'handle' stdout. Idle does, by inserting strings into a tk text widget. tk does not care where inserted chars come from. tk \b behavior is OS dependent. tk may always ignore \r, but this is different from (at least some) consoles. Attempt 2, with and added paragraph. ... * Except for newline ('\n'), tk handling of ascii control chars may depend on the OS and may by different from text consoles. Both are true for backspace ('\b') and the latter for return ('\r'), which tk ignores. These differences noted above are not bugs. If an application is going to be run repeatedly after being developed with Idle, it should usually be run directly, without Idle. (An exception would be non-gui Windows apps that need tk's better unicode support.) That means testing at least once without Idle. --- Thanks for the comments. ---------- stage: needs patch -> patch review _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23220> _______________________________________

1 0

[issue23220] Documents input/output effects of how IDLE runs user code
by Martin Panter 12 Jul '15

12 Jul '15

Martin Panter added the comment: “run ``import idlelib; idlelib.run`` within a try-except statement”: It might be nice to say what exceptions are expected. My guess is ImportError if Idle or TK is not available, or AttributeError if it is but Idle is not running. “Tk handling of ascii control chars”: I presume you mean stdout and stderr handling, which this bug was originally about (or also input, source code, etc as well?). It might be good to say that output of Unix newlines (\n) is guaranteed to be supported. Also might be worth explicitly pointing out that output of CRLFs is not supported, even if os.linesep is "\r\n". In my experiments between Linux and Wine, this does not appear to depend on the OS. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23220> _______________________________________

1 0

[issue24610] Incorrect example Unicode string in docs footnote
by Chris Angelico 11 Jul '15

11 Jul '15

New submission from Chris Angelico: https://docs.python.org/3/reference/expressions.html#id18 The string "\u0327\u0043" does not normalize to the same string as "\u00C7", as combining characters are supposed to _follow_ the base character. (Some consoles may happen to display them the same way, but prepend another letter to the string and it's clear that the combining cedilla is attached to that and not to the C.) Switching the two escape sequences makes the example work. Patch attached. ---------- assignee: docs@python components: Documentation files: cedilla_docs.patch keywords: patch messages: 246599 nosy: Rosuav, docs@python priority: normal severity: normal status: open title: Incorrect example Unicode string in docs footnote versions: Python 3.6 Added file: http://bugs.python.org/file39894/cedilla_docs.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24610> _______________________________________

3 3

[issue23220] Documents input/output effects of how IDLE runs user code
by Terry J. Reedy 11 Jul '15

11 Jul '15

Terry J. Reedy added the comment: Serhiy, thanks for the paraphrase of what I tried to say. This issue has already been changed to a doc issue to explain the input/output effects of Idle's way of running user code. I should have retitled before. Control codes are just one of the effects that have come up on the tracker, python-list, or stackoverflow. Misunderstanding had lead to user puzzlement and even undeserved insults directed as Python. I propose to something like the following to the introductory section of the Idle doc, https://docs.python.org/3/library/idle.html#index-0, after the feature list. --- When Idle runs user code from either the shell or an editor window, the result is nearly always be the same as running the same code directly with python in either interactive or batch mode. However, environmental differences can have visible effects. For instance, Idle import statements add numerous entries to sys.modules and a few module attributes to modules such as tkinter. The line `1import tkinter; tkinter.colorchooser`` normally raises AttributeError but works when run with Idle because Idle has already imported tkinter.colorchooser. To detect whether code is running under Idle, run ``import idlelib; idlelib.run`` within a try-except statement. More important are the input/output differences. Python normally runs in a text console process with direct access to keyboard and screen. For code run with Idle, the keyboard and screen are controlled by the tk graphics subsystem and sys.stdin, sys.stdout, and sys.stderr are bound to objects that connect to the gui. (Note that ``print`` calls ``sys.stdout.write``.) Here are some of the effects of keyboard and screen access being indirect. * Operating system (OS) specific functions that directly access the keyboard may not work. * The Idle shell works with complete statements rather than individual lines of code. One can edit and retrieve complete multiline statements instead of single lines. * User code gets colorized. Normal output and error output to the shell get their own colors. * Tk supports the Basic Multilingual Plane (BMP) subset of Unicode characters. This is worse than consoles that support supplementary planes (with appropriate fonts in use), but better than the Windows console, which only supports restricted subsets of the BMP, depending on the code page in use. * Tk handling of ascii control chars depends on the OS and is usually different from the text console. --- ---------- title: IDLE does not display \b backspace correctly. -> Documents input/output effects of how IDLE runs user code _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23220> _______________________________________

1 0

[issue23220] IDLE does not display \b backspace correctly.
by Serhiy Storchaka 11 Jul '15

11 Jul '15

Serhiy Storchaka added the comment: Control characters are named control characters because they are control the output device. Different devices have different capabilities and reacts different on the same codes. Windows console, different sorts of Linux terminals and Tk text widget are different devices. Some prints funny characters, others not, some beeps, others not, some interprets particular flavor of ESC sequences, others not, some allows color and positioning, others not. Python can't unify the behavior of these devices without lost most of functionality as it can't unify the behavior of black-white matrix printer, graphical plotter and 24-bit color LCD monitor. I would close this issue as not related to Python. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23220> _______________________________________

1 0

[issue23220] IDLE does not display \b backspace correctly.
by Terry J. Reedy 11 Jul '15

11 Jul '15

Terry J. Reedy added the comment: I closed #24572 as a duplicate of this. It is the same issue except for printing \r instead of \b. These issues are not about responses to keyboard actions when entering text into an Idle editor window. During entry, just about any cntl/alt/function/shift/key combination can be intercepted to and translated to arbitrary action. They are also not about REPL echo. For 3.4+ Win7, both console Python and Shell echo '\b\t\x08\x09' as '\x08\t\x08\t'. Carol's report suggest that the same is true on Mac also. Both issues *are* about print(s, file=outfile), where s is the result of processing all args except 'file' and outfile defaults to sys.stdout. The print call is the same as outfile.write(s), so outfile (and sys.stdout) could be any object with a write method. >>> print('hello\b\b\b\b\bHELLO') helloHELLO >>> import sys; sys.stdout.write('hello\b\b\b\b\bHELLO'+'\n') helloHELLO (I actually see the same circles as Al, but copy-paste does not seem to work as well for me.) So both issues are about the effect of writing 'control chars', in particular \b and \r, to a file. Well, that depends on the file. Some possibilities are copy as is (StringIO), encode and copy (disk file, socket), ignore, display as one glyph, display as multiple chars, non-destructively backspace (like backspace on typewriters and printing terminals and left-arrow elsewhere), or destructively backspace (like backspace on as most (all?) screen keyboards). After non-destructive movement of the 'cursor' position, the possibilities for following graphical chars are overwrite (like typewriters), replace, and insert (the modes sometimes selected by the Insert key). Non-destructive backspace followed by overwrite (meaning 'HELLO' printed on top of 'hello') is the original meaning of 'backspace'. Having said all this, I am sympathetic to the idea that there should be an option to have 'print(ascii_string)' in user code give the same result in the console and Idle. I think this would best be accomplished by a least-common-denominator SimpleTerm subclass of tkinter.Text put somewhere in the tkinter package. (This would be a new issue that should start on python-ideas list.) However, I would consider something Idle specific. Does the following work the same on *nix and Mac as Windows? >>> print('hello\rHELLO') HELLO # helloHELLO with Win7 Idle Are there any control-chars (other than \n) that work might work in the consoles on all three systems and that should be included? Carol, another difference between the Windows console and Idle is that tk and hence Idle support the entire BMP subset of unicode. This should also be mentioned in the doc. ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23220> _______________________________________

1 0

[issue22232] str.splitlines splitting on non-\r\n characters
by Gregory P. Smith 10 Jul '15

10 Jul '15

Gregory P. Smith added the comment: If this isn't already mentioned in 2 to 3 porting notes it is worth highlighting there. code which uses a str in python 2 and still uses a str in python 3 is now splitting on many more characters. That seems to be the source of bugs like issue22233. splitlines() used to work for the strict \r\n splitting task. now that code needs to made explicit about its splitting desires. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22232> _______________________________________

1 0