[issue24539] StreamReaderProtocol.eof_received() should return True to keep the transport open
Drekin added the comment: I've also been hit by this issue, see https://mail.python.org/pipermail/python-list/2015-July/693496.html and the following thread. I've spent some time trying to find where the problem is, and just after I found out it's about eof_received() returning None, I could found this issue. :-) -- nosy: +Drekin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24539 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22555] Tracking issue for adjustments to binary/text boundary handling
Changes by Drekin dre...@gmail.com: -- nosy: +Drekin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22555 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: Note that under status quo PyOS_Readline is called from two places: the tokenizer during an interactive session and the builtin function input. The tokenizer passes promptstring encoded in sys.stdin.encoding while input() passes promtstring encoded in sys.stdout.encoding, so it is not possible to implement a readline hook correctly in the case the encodings are different. This might be considered a bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: Unfortunately, I have little or no experience with Python C code and I even don't have a C compiler installed so I cannot experiment. I'll just put my ideas how to solve this here. • Add sys.__readlinehook__ attribute, which can be set to a function taking a prompt string and returing a line. • Add C function PyOS_UnicodeReadline (possibly with a better name) which has the same signature as sys.__readlinehook__ (in contrast with the signature of PyOS_Readline). If sys.__readlinehook__ is set, call it; otherwise encode the prompt string using stdout encoding and delegate to PyOS_Readline and decode the string returned using stdin encoding. • Change the tokenizer and the implementation of input() so it uses PyOS_UnicodeReadline rather than PyOS_Readline. This would solve the problem that utf-16 encoded string cannot be given to the tokenizer and also would bypass the silent assumption that stdin and stdout encodings are the same. Also, readline hook could be easily set from Python code – no need for ctypes. The package pyreadline could use this. Also, the issue #1602 could be then solved just by changing sys.std* streams and providing a trivial sys.__readlinehook__ delegating to sys.stdout.write and sys.stdin.readline. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: File redirection has nothing to do with win-unicode-console and this issue. When stdout is redirected, it is not a tty so win-unicode-console doesn't replace the stream object, which is the right thing to do. You got UnicodeEncodeError because Python creates sys.stdout with encoding based on your locale. In my case it is cp1250 which cannot encode whole Unicode. You can control the encoding used by setting PYTHONIOENCODING environment variable. For example, if you have a script producer.py, which prints some Unicode characters, and consumer.py, which just does print(input()), then py producer.py | py consumer.py shows that redirection works (when PYTHONIOENCODING is set e.g. to utf-8). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: Note that win-unicode-console replaces the stdio streams rather than wraps them. So the desired state would be Unicode stream objects wrapped by PTVS. There would be no problem if win-unicode-console stream replacement occured before PTVS wraps them, which should be the case when Unicode streams for Windows are hadled by Python 3.5 itself. Is there any way to run custom Python code (like sitecustomize) before PTVS wraps the stdio streams? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: I tried the following code: import pdb pdb.set_trace() print(1 + 2) print(αβγ∫) When run in vanilla Python it indeed ends with UnicodeEncodeError as soon as it hits the line with non-ASCII characters. However, the solution via win_unicode_console package seems to work correctly. There is just an issue when you keep calling 'next' even after the main program ended. It ends with a RuntimeError after a few iterations. I didn't know that pdb can continue debugging after the main program has ended. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22667] Incorrect evaluation of variables with names containing supplementary characters
Drekin added the comment: I understand. I have found https://mail.python.org/pipermail/python-3000/2007-May/007995.html as a reason for using NFKC rather than NFC. On the other hand I think one may want these double-struct mathematical letters to be different from the ordinary ones if used as variable names. So I wonder if there are some other reasons for choosing NFKC over NFC. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22667 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22667] Incorrect evaluation of variables with names containing supplementary characters
New submission from Drekin:
eval(\N{mathematical double-struck capital a})
NameError: name 'A' is not defined
A = 2
eval(\N{mathematical double-struck capital a})
2
\N{mathematical double-struck capital a} == A
False
--
components: Interpreter Core, Unicode
messages: 229653
nosy: Drekin, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Incorrect evaluation of variables with names containing supplementary
characters
versions: Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22667
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: stijn: You are mixing two issues here. One is reading text from a file. There is no problem with it. You just call open(path, encoding=the_encoding_of_the_file). Since the encoding of the file depends on the file, you should provide the information about it. Another issue is interactively entering and displaying Unicode characters in Python REPL in Windows console. That's what is this issue about. The streams code you use is outdated, for recent version see https://pypi.python.org/pypi/win_unicode_console and https://github.com/Drekin/win-unicode-console. It's an installable package which tries to solve the issue. The readme also contains a summary of the issue. Try the package and let me know if there is any problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22408] Tkinter doesn't handle Unicode dead key combinations on Windows
Drekin added the comment: I installed wish and tried the demos shipped with Python. The behavior occurs during the demo basic editable text. So it's an issue of Tk itself. Actually the same behavior occurs even in the wish shell. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment:
Stefan Champailler:
The crash you see is maybe not a crash at all. First it has nothing to do with
printing, the problem is reading of your input line. That explains why Python
exited even before printing the traceback of the SyntaxError. If you try to
read input using `sys.stdin.buffer.raw.read(100)` and type Unicode characters,
it returns just empty bytes `b''`. So maybe Python REPL then thinks the input
just ended and so standardly exits the interpreter.
Why are you using chcp 65001? As far as I know, it doesn't give you the ability
to use Unicode in the console. It somehow helps with printing, but there are
some issues. `print(\N{euro sign})` prints the right character, but it prints
additional blank line. `sys.stdout.write(\N{euro sign})` and
`sys.stdout.buffer.write(\N{euro sign}.encode(cp65001))` does the same, but
`sys.stdout.buffer.raw.write(\N{euro sign}.encode(cp65001))` works as
expected.
If you want to enter and display Unicode in Python on Windows console, try my
package `win_unicode_console`, which tries to solve the issues. See
https://pypi.python.org/pypi/win_unicode_console.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1602
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: Nick Coghlan: Ok, done. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: Idle shell handles Unicode characters well, but one cannot enter them using deadkey combinations. See http://bugs.python.org/issue22408. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22408] Tkinter doesn't handle Unicode dead key combinations on Windows
Drekin added the comment:
By modifier I mean a key like Shift, Ctrl, Alt, AltGr; or the corresponding
modifier state. A combination modifier + base key produces either special
action or a character or a dead key. A dead key affects the next character
rather than producing a character itself. Dead keys can be even chained, i.e. a
sequence [previous dead key, modifier + base key] can produce another dead key.
(Aside: This feature has been present on Windows for long time, but is used
very rarely and applications are buggy. I spent some time designing my Unicode
keyboard layout using chained dead keys to produce various mathematical
symbols. Then I found out than some applications have problems with the feature
– including Firefox. It's basically because they try to implement the
interpretation of keyboard layout by themselves rather then using standard
Windows implementation through API.)
For example standard Czech keyboard use the AltGr key and the corresponing
state to produce characters like $, #, , @, {, }, [, ], because the top row is
used for common diacritical combinations and its Shift state for numbers. I
understand that English doesn't need many characters and so the layout usually
doesn't need AltGr or dead keys. But I think even English keyboard should be
able to type characters like English quotes, N-dash, or ellipsis: “, ”, –, ….
I have also changed the title.
--
title: Tkinter doesn't handle Unicode key events on Windows - Tkinter doesn't
handle Unicode dead key combinations on Windows
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22408
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22408] Tkinter doesn't handle Unicode key events on Windows
Drekin added the comment: It seems that it's a problem of dead key combinations rather than modifiers. Unicode characters produced directly (with or without modifiers) work correctly. Only one deadkey on my keyboard doesn't work at all. AltGr + M is a deadkey, but any following key is interpreted as if no deadkey was pressed. On the other hand, other deadkeys including those with modifiers produces the combined characters, however usually returns just ? as if someone applied char = char.encode(mbcs, errors=replace).decode(). E.g. whole Greek alphabet is transformed to question marks but beta is transformed to sharp s and mu to micro sign. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: I have found another problem. PyOS_Readline can be called from two different places – from Parser/tokenizer.c:tok_nextc (by REPL), which uses sys.stdin.encoding to encode prompt argument, and from Python/bltinmodule.c:builtin_input_impl (by input() function), which uses sys.stdout.encoding. So readline hook cannot be implemented correctly if sys.stdin and sys.stdout don't have the same encoding. Either the tokenizer should have two encodings – one for input and one for output - or better no encoding at all and should use Python string based alternative to PyOS_Readline, which could be added. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22408] Tkinter doesn't handle Unicode key events on Windows
New submission from Drekin: Key events produced on Windows handles Unicode incorrectly when Unicode character is produced by dead-key combination. On my keyboard, (AltGr + M, a) produces several key events, last of which contains char==a, however, it should contain ∀. Also dead-key sequence (\, a) should produce event.char==α, however contains ?. -- components: Tkinter, Unicode, Windows messages: 226872 nosy: Drekin, ezio.melotti, haypo priority: normal severity: normal status: open title: Tkinter doesn't handle Unicode key events on Windows versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22408 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: Antoine Pitrou: I understand. It would be nice to have that new Python string based readline hook. Its default implementation could be to call PyOS_Readline and decode the bytes using sys.stdin.encoding (as the tokenizer currently does). Tokenizer then woudn't need to decode if it called the new hook. Victor Stinner: I'm going to try the approach of reencoding my stream to UTF-8. So then my UTF-16-LE encoded stream is decoded, then encoded to UTF-8, interpreted as null-terminated *char, which is returned to the tokenizer, which again decodes it and encodes to UTF-8. I wonder if the last step could be short-circuited. What is this UTF8 flag to Python parser? I couldn't find any information. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: I realized that the behavior I want can be achieved by setting PyOS_ReadlineFunctionPointer to a function calling sys.stdin.readline(). However I found another problem: Python REPL just doesn't work, when sys.stdin.encoding is UTF-16-LE. The tokenizer (Parser/tokenizer.c:tok_nextc) reads a line using PyOS_Readline and then tries to recode it to UTF-8. The problem is that PyOS_Readline returns just plain *char and strlen() is used to determine its length when decoding, which makes no sense on UTF-16-LE encoded line, since it's full of nullbytes. Why does PyOS_Readline return *char, rather than Python string object? In the situation when PyOS_ReadlineFunctionPointer points to something producing Unicode string (e.g. my new approach to solve #1602 or pyreadline package), it must be encoded and cast to *char to return from PyOS_Readline, then it is decoded by the tokenizer and again encoded to UTF-8. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22257] PEP 432: Redesign the interpreter startup sequence
Changes by Drekin dre...@gmail.com: -- nosy: +Drekin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22257 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: I have found another example of where the current interaction between readline and Python core lead to confussion. It started with following report on my package: https://github.com/Drekin/win-unicode-console/issues/2 . Basically, IPython interactive console on Windows uses pyreadline package, which provides GNU readline functionality. To get input from user, it just calls input(prompt). Input calls readline both for writing prompt and reading the input. It interprets ANSI control sequences so colored prompt is displayed rather than garbage. And when user types, things like auto-completion work. sys.stdin is not used at all and points to standard object. One easily gets the impression that since sys.stdin is bypassed, changing it doesn't mind, but it actually does. With changed sys.stdin, input() now uses it rather than readline and ANSI control sequences result in a mess. See https://github.com/ipython/ipython/issues/17#issuecomment-53696541 . I just think that it would be better when input() allways delegated to sys.stdin and print() to sys.stdout() and this was the standard way to interact with terminal. It would then be the responsibility of sys.std* objects to do right thing – to read from file, to delegate to readline, to directly interact with console some way, to interpret or not the ANSI control sequences. Solving issues like #1602 or #18597 or adding readline support to Windows would then be just matter of providing the right sys.std* implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue516762] have a way to search backwards for re
Drekin added the comment: Hello, I wanted to use this feature and found this issue. It is marked as closed, being a duplicate of another closed issue. However the feature is actually not present. In 2008 it was planned to be added by Matthew Barnett in #3825, but the work of improving re module moved to bigger project under #2636 which resulted in regex package to be evenually included in stdlib. So unless regex is included in stdlib, one should try regex package (e.g. pip install regex). I've put here this summary just in case there is someone like me who looked for the feature and found this issue. -- nosy: +Drekin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue516762 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: I think that boxes are ok, it's just missing font. Without active workaroud there is just UnicodeEncodeError (with cp852 for me). There is problem with astral characters – I'm getting each box twice. It is possible that Windows console doesn't handle astral characters at all – it doesn't interpret surrogate pairs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: I looked to the sourcecode and found the following. First, the codepath of how interactive loop gets its input follows: Python/pythonrun.c:PyRun_InteractiveLoopFlags Python/pythonrun.c:PyRun_InteractiveOneObject Python/pythonrun.c:PyParser_ASTFromFileObject Parse/parsetok.c:PyParser_ParseFileObject Parse/parsetok.c:parsetok Parse/tokenizer.c:PyTokenizer_Get Parse/tokenizer.c:tok_get Parse/tokenizer.c:tok_nextc Parser/myreadline.c:PyOS_Readline OR Parse/tokenizer.c:decoding_fgets PyRun_InteractiveOneObject tries to get the input encoding via sys.stdin.encoding. The encoding is then passed along and finally stored in a tokenizer object. It is tok_nextc function that gets the input. If the prompt is not NULL it gets the data via PyOS_Readline and uses the encoding to recode it to UTF-8. This is unfortunate since the encoding, which originates in sys.stdin.encoding, can have nothing to do with the data returned by PyOS_Readline. Αlso note that there is hardcoded stdin argument to PyOS_Readline, but it probably holds tok-fp == stdin so it doesn't matter. If the prompt in tok_nextc is NULL then the data are gotten by decoding_fgets function, which either use fp_readl tok-decoding_readline or Objects/fileobject.c:Py_UniversalNewlineFgets depending on tokenizer state. tok-decoding_readline handler may be set to io.open(isisOOO, fileno(tok-fp), …) (I have no idea what isisOOO might be). PyOS_Readline function either calls PyOS_StdioReadline or the function pointed to by PyOS_ReadlineFunctionPointer which is by default again PyOS_StdioReadline, but usually is set to support GNU readline by the code in Modules/readline.c. PyOS_StdioReadline function uses my_fgets which calls fgets. Now what input() function does. input is implemented as Python/bltinmodule.c:builtin_input. It tests if we are on tty by comparing sys.stdin.fileno() to fileno(stdin) and testing isatty. Note that this may not be enough – if I inslall a custom sys.stdin but let it have standard fileno then the test may succeed. If we are tty then PyOS_Readline is used (and again together with sys.std*.encoding), if we aren't then Objects/fileobject.c:PyFile_WriteObject sys.stdout.write (for prompt) and :PyFile_GetLine sys.stdin.readline are used. As we can see, the API is rather FILE* based. The only places where sys.std* objects are used are in one branch of builtin_input, and when getting the encoding used in tokenizer. Could it be possible to configure the tokenizer so it uses sys.stdin.readline for input, and also rewrite builtin_input to allways use sys.std*? Then it would be sys.stdin.buffer.raw.read* methods' responsibility to decide whether to use GNU readline or whatever PyOS_Readline uses or something else (e.g. ReadConsoleW on Windows tty), and also check for Ctrl-C afterwards. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: Sorry for formating in the previous message. Repeating… I looked to the sourcecode and found the following. First, the codepath of how interactive loop gets its input follows: Python/pythonrun.c:PyRun_InteractiveLoopFlags Python/pythonrun.c:PyRun_InteractiveOneObject Python/pythonrun.c:PyParser_ASTFromFileObject Parse/parsetok.c:PyParser_ParseFileObject Parse/parsetok.c:parsetok Parse/tokenizer.c:PyTokenizer_Get Parse/tokenizer.c:tok_get Parse/tokenizer.c:tok_nextc Parser/myreadline.c:PyOS_Readline OR Parse/tokenizer.c:decoding_fgets PyRun_InteractiveOneObject tries to get the input encoding via sys.stdin.encoding. The encoding is then passed along and finally stored in a tokenizer object. It is tok_nextc function that gets the input. If the prompt is not NULL it gets the data via PyOS_Readline and uses the encoding to recode it to UTF-8. This is unfortunate since the encoding, which originates in sys.stdin.encoding, can have nothing to do with the data returned by PyOS_Readline. Αlso note that there is hardcoded stdin argument to PyOS_Readline, but it probably holds tok-fp == stdin so it doesn't matter. If the prompt in tok_nextc is NULL then the data are gotten by decoding_fgets function, which either use fp_readl tok-decoding_readline or Objects/fileobject.c:Py_UniversalNewlineFgets depending on tokenizer state. tok-decoding_readline handler may be set to io.open(isisOOO, fileno(tok-fp), …) (I have no idea what isisOOO might be). PyOS_Readline function either calls PyOS_StdioReadline or the function pointed to by PyOS_ReadlineFunctionPointer which is by default again PyOS_StdioReadline, but usually is set to support GNU readline by the code in Modules/readline.c. PyOS_StdioReadline function uses my_fgets which calls fgets. Now what input() function does. input is implemented as Python/bltinmodule.c:builtin_input. It tests if we are on tty by comparing sys.stdin.fileno() to fileno(stdin) and testing isatty. Note that this may not be enough – if I inslall a custom sys.stdin but let it have standard fileno then the test may succeed. If we are tty then PyOS_Readline is used (and again together with sys.std*.encoding), if we aren't then Objects/fileobject.c:PyFile_WriteObject sys.stdout.write (for prompt) and :PyFile_GetLine sys.stdin.readline are used. As we can see, the API is rather FILE* based. The only places where sys.std* objects are used are in one branch of builtin_input, and when getting the encoding used in tokenizer. Could it be possible to configure the tokenizer so it uses sys.stdin.readline for input, and also rewrite builtin_input to allways use sys.std*? Then it would be sys.stdin.buffer.raw.read* methods' responsibility to decide whether to use GNU readline or whatever PyOS_Readline uses or something else (e.g. ReadConsoleW on Windows tty), and also check for Ctrl-C afterwards. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C properly
Drekin added the comment: Shouldn't there be a Ctrl-C check in Modules/_io/fileio.c:fileio_read* functions? I think some of these are called by standard sys.stdin.readline(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18597 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: My naive picture of ideal situation looks like this: When the interactive loop wants input, it just calls sys.stdin.readline, which delegates to sys.stdin.buffer.raw.readinto or .read, these can use GNU readline if available to get the data. May I ask, what's wrong with my picture? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Changes by Drekin dre...@gmail.com: Removed file: http://bugs.python.org/file27261/win_unicode_console_2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Changes by Drekin dre...@gmail.com: Removed file: http://bugs.python.org/file29563/i.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Changes by Drekin dre...@gmail.com: Removed file: http://bugs.python.org/file29564/win_unicode_console_3.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Changes by Drekin dre...@gmail.com: Removed file: http://bugs.python.org/file31756/streams.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Changes by Drekin dre...@gmail.com: Removed file: http://bugs.python.org/file31770/win_unicode_console.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Changes by Drekin dre...@gmail.com: Removed file: http://bugs.python.org/file35990/win_unicode_console.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: I have deleted all my old files and added only my current implementation of the stream objects as the only relevant part to this issue. @Mark Summerfield: I have added __init__.py to the new version of win_unicode_console. If there is any problem, you can start an issue on project GitHub site or contact me. @Victor Stinner, @Nick Coghlan: What's wrong with looking on Windows wide strings as on UTF-16-LE encoded bytes and building the raw stream objects around this? -- Added file: http://bugs.python.org/file36120/streams.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Changes by Drekin dre...@gmail.com: Removed file: http://bugs.python.org/file27245/win_unicode_console.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: @Victor Stinner: You are right. So I did it. Here are the links to GitHub and PyPI: https://github.com/Drekin/win-unicode-console, https://pypi.python.org/pypi/win_unicode_console. I also tried to delete the files, but it seems that it is only possible to unlink a file from the issue, but the file itself remains. Is it possible to manage the files? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: I have made some updates in the streams code. Better error handling (getting errno by GetLastError() and raising exception when zero bytes are written on non-zero input). This prevents the infinite loop in BufferedIOWriter.flush() when there is odd number of bytes (WriteConsoleW accepts UTF-16-LE so only even number of bytes is written). It also prevents the same infinite loop when the buffer is too big to write at once (see http://bugs.python.org/issue11395 ). The limit of 32767 bytes was added to raw write. -- Added file: http://bugs.python.org/file35990/win_unicode_console.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: There is still the serious inconsistency that the `sys.stdin` is not used for input by interactive loop but its encoding is. So if I replace `sys.stdin` with a custom object with its own `encoding` attribute, the standard interactive loop tries to use this encoding which may result in an exception on any input. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19040] Problems with overriding Enum.__new__
Drekin added the comment: Yes, I've done it similarily using a class method. Thank you for help. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19040 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] functools.total_ordering fails to handle NotImplemented correctly
Drekin added the comment: Hello, I have run into this when I wanted to use OrderedEnum and the example in enum docs seemed too repetitive to me. It's nice to know that it's being worked on. -- nosy: +Drekin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10042 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19040] Problems with overriding Enum.__new__
New submission from Drekin: I tried to implement an Enum variant OptionalEnum such that OptionalEnum(value) leaves value alone and returnes it (if there is no corresponding enum member) rather than raising ValueError. My use case is following: I'm trying to parse some keyboard layout related data. There is a table which maps virtual keys to unicode codepoints, however there are some special values which don't represent a codepoint but the fact that the key is a deadkey and more information is provided in the next table entry. Or that the key produces a ligature. So I wanted to define enums for those special values. This brought me to the following naive approach: class OptionalEnum(Enum): def __new__(cls, value): try: return super(cls, cls).__new__(cls, value) except ValueError: return value This ends with a weird exception. As I ran through enum code I found out that there are actually two flavors of EnumSubclass.__new__. The first one is for precreating the enum members (during creation of EnumSubclass). This is the intended usage. The second flavor is what happens when EnumSubclass(value) is called later. This flavor is represented by Enum.__new__ which returns existing member corresponding to the value or raises ValueError. However this Enum.__new__ is rather special. It doesn't take place in the process of the first flavor, it is explicitly by-passed. On the other hand it is forced behavior of the second flavor since it is explicitly assigned to EnumSubclass.__new__. So there seems to be no way to customize the second flavor (as I tried in my use case). So could the customization of the second flavor of __new__ be added? (One maybe naive solution would be to let user explicitly define __new_member__ rather than __new__ to customize the first flavor and leave __new__ for the second flavor.) Or could at least be done something with the exceptions produced when one tries to? (The exception in my case was 'TypeError: object() takes no parameters' and was result of having custom __new__ and hence use_args==True but having member_type==object and __new__ not creating member with _value_ attribute so object(*args) was called.) In any case additional documentation on customizing __new__ could help. There are points like that one should avoid the pattern of falling back to super().__new__ since that is Enum.__new__ which is for something else. Also the custom __new__ should return an object with _value_ attribute or object() with some argument may be called which leads to uninformative exception. -- assignee: docs@python components: Documentation, Library (Lib) messages: 197979 nosy: Drekin, docs@python priority: normal severity: normal status: open title: Problems with overriding Enum.__new__ type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19040 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: Glenn Linderman: Yes I have built on what the others learned. For your question, I made it and tested it in Python 3.3, it should also work in 3.4 and what I've tried, it actually works. As Terry J. Reedy says you can just load the module and enable the streams. I do this automatically on startup using sitecustomize. However as I said currently this meeses up the interactive session because of http://bugs.python.org/issue17620 . I have made some workaround – custom REPL built on stdlib module code. And also a helper script which runs the main script and then runs the custom REPL (I couldn't find any stadard hook which would run the custom REPL). I'm uploding full code. I will delete it if this isn't appropriate place. Things like this could be fixed more easily if more core interpreter logic took place in stdlib. E. g. the code for interactive REPL. Few days ago I started some discussion on python ideas: https://mail.python.org/pipermail/python-ideas/2013-August/023000.html . -- Added file: http://bugs.python.org/file31770/win_unicode_console.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: Hello again. I have rewritten the custom stdio objects and implemented them as raw io reading and writing bytes in UTF-16-LE encoding. They are then wrapped in standard BufferedReader/Writer and TextIOWrapper objects. This approach also solves a bug of wrong string length given to WriteConsoleW when the string contained supplementary character. Since we are waiting for Ctrl-C signal to arrive, this implmentation doesn't suffer from http://bugs.python.org/issue18597 . It seems to work when main script is executed however it doesn't work in Python interactive REPL since the REPL doesn't use sys.stdin for input. However it uses its encoding which results in mess when sys.stdin is changed to object with different encoding like UTF-16-LE. See http://bugs.python.org/issue17620 . -- Added file: http://bugs.python.org/file31756/streams.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13758] compile() should not encode 'filename' (at least on Windows)
Drekin added the comment: Since this issue was fixed, shouldn't it be marked fixed here? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13758 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18838] The order of interactive prompt and traceback on Windows
New submission from Drekin: On Windows, Python 3.3.2, when I run Python as a subprocess via Popen(py -i somescript.py, stdin=PIPE, stdout=PIPE, stderr=PIPE).communicate() and somescript.py ends with exception, there is first interactive promt in stderr output and then the traceback which is reversed to standard order when somescript.py is run interactively directly. Corresponding StackOverflow question: http://stackoverflow.com/questions/18419724/position-of-prompt-in-stderr-after-systemexit . -- components: Windows messages: 196192 nosy: Drekin priority: normal severity: normal status: open title: The order of interactive prompt and traceback on Windows type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12869] PyOS_StdioReadline is printing the prompt on stderr
Drekin added the comment: Related stackoverflow question: http://stackoverflow.com/questions/18419787/where-does-pythons-interactive-prompt-output-to . -- nosy: +Drekin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12869 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C properly
Drekin added the comment: Why are there actually more codepaths which may raise this issue? My naive idea would be that input() is just thin wrapper around sys.stdout.write() (for prompt) and sys.stdin.readline() which leads to sys.stdin.buffer.raw.read* where is the place where some low level OS-dependent function to actually get input from user is called (unistd.read or GNU readline or whatever). And also there is the place where the waiting for KeyboardInterrupt on Windows should occur. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17588] runpy cannot run Unicode path on Windows
Drekin added the comment: There is over year old closely related issue: http://bugs.python.org/issue13758 . -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17588 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13758] compile() should not encode 'filename' (at least on Windows)
Drekin added the comment: Hello. Will this be fixed? It's really annoying that you cannot pass valid unicode filename to compile(). I'm using a workaround: I just pass placeholder and then “update” the resulting code object recursively to set the correct co_filename. Afterwards the code object can be executed and produces correct tracebacks. (I'm using Windows.) Fixing this will probably fix also http://bugs.python.org/issue17588 . It doesn't bother just me. See e.g. http://stackoverflow.com/questions/8798591/unicodeencodeerror-when-using-the-compile-function . Thank you. Drekin -- nosy: +Drekin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13758 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17702] os.environ converts key type from string to bytes in KeyError exception
Drekin added the comment: This patch introduces a bit ugly traceback. Shouldn't there be “raise from None” or “raise from previous_exc” instead of simple raise? -- nosy: +Drekin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17702] os.environ converts key type from string to bytes in KeyError exception
Drekin added the comment: It's also in __delitem__. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17702 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C properly
New submission from Drekin: When I run sys.stdin.readline() interactivelly (on Windows and Python 3.3.2) and hit Ctrl-C, sometimes it returns an empty string just before KeyboardInterrupt is raised. Sometimes it isn't even raised and instead after hitting Return some weird SyntaxtError: unknown decode error (on line 0) occurs. Seems like propagation of KeyboardInterrupt is somehow out of sync. sys.stdin.read(n) has the same issue. May be related to recently fixed http://bugs.python.org/issue17619 where was similar situation with input(). -- components: Windows messages: 193918 nosy: Drekin priority: normal severity: normal status: open title: On Windows sys.stdin.readline() doesn't handle Ctrl-C properly versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18597] On Windows sys.stdin.readline() doesn't handle Ctrl-C properly
Drekin added the comment: I haven't experience with Python C code but I tried to find some clues in the code. First for input(): it call PyOS_Readline which may call PyOS_StdioReadline my_fgets fgets in Parser/myreadline.c. There is Windows related comment on line 56: “Ctrl-C anywhere on the line or Ctrl-Z if the only character on a line will set ERROR_OPERATION_ABORTED. Under normal circumstances Ctrl-C will also have caused the SIGINT handler to fire which will have set the event object returned by _PyOS_SigintEvent. This signal fires in another thread and is not guaranteed to have occurred before this point in the code. Therefore: check whether the event is set with a small timeout. If it is, assume this is a Ctrl-C and reset the event. If it isn't set assume that this is a Ctrl-Z on its own and drop through to check for EOF.” For sys.stdin.readline and .read: it goes down the IO machinery from text IO, buffered IO and raw IO (in this case FileIO) to Modules/_io/fileio.c where it ends calling function read(fd, buf, len), probably from unistd. I don't know how read is implemented on Windows. I also tried calling ReadConsoleW from winapi via ctypes to read Unicode charactes from console (see http://bugs.python.org/issue1602). And there was similar issue with Ctrl-C occurring. What seems to work here is to put time.sleep(0.01) after ReadConsoleW. So the general pattern is following: when calling some low-level Windows function to read input from user and when he hits Ctrl-C, the function returns and SIGINT is generated. However it takes time for this signal to arrive. Because it may arrive anywhere in the following code, the strange behaviour may occur. In the input() case, when PyOS_Readline returns, it was probably enough time, so added PyErr_CheckSignals() catched that SIGINT/KeyboardInterrupt. We can find out about Ctrl-C having been pressed by calling winapi function GetLastError() and testing against ERROR_OPERATION_ABORTED. Then we should wait for the signal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: Is there any chance the API will be added and used by python.exe? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11619] On Windows, don't encode filenames in the import machinery
Drekin added the comment: Is there a chance this will be fixed at least in Python 4? -- nosy: +Drekin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18331] runpy.run_path gives functions with corrupted .__globals__
New submission from Drekin: Let's have a simple script test.py: def f(): return x x = 2 print(f()) Now if we try to run it via runpy.run_path, we get the following: import runpy g = runpy.run_path(test.py) 2 g[f]() is None True g[x] is 2 True g[f].__globals__[x] is None True Is the behaviour of f.__globals__ after return from run_path intended and why? -- components: Library (Lib) messages: 192072 nosy: Drekin priority: normal severity: normal status: open title: runpy.run_path gives functions with corrupted .__globals__ type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18331 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17730] code.interact() doesn't support no banner
New submission from Drekin: Currently, there is no way to run code.interact without a banner – empty string still means to print an empty line. If I want that behaviour, I must subclass code.InteractiveConsole and reimplement whole .interact method including the repl logic just not to print a banner. Maybe there should be .print_banner method for this. -- components: Library (Lib) messages: 186914 nosy: Drekin priority: normal severity: normal status: open title: code.interact() doesn't support no banner type: enhancement versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17730 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: I encountered it when I changed sys.stdin at runtime (I thought it was a supported feature) to affect the interactive console, see http://bugs.python.org/issue1602 . -- versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Drekin added the comment: Sorry for typos. • interactive console doesn't use sys.stdin for input, why? • it uses sys.stdin.encoding, shouldn't it rather use sys.__stdin__.encoding if anything? • input() and hence code.interact() uses sys.stdin -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17619] MS WINDOWS: input() swallows KeyboardInterrupt in Python 3.3
Drekin added the comment: I have Windows Vista Business SP2, 64-bit, (6.0.6002). If I start Python any way (from console, from shortcut, via py.exe or not) the same behavior occurs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17619] MS WINDOWS: input() swallows KeyboardInterrupt in Python 3.3
Drekin added the comment: However it raises the exception correctly in IDLE. The same behavior occured on Windows 7 Home Premium SP1, 64-bit, (6.1.7601). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17588] runpy cannot run Unicode path on Windows
Drekin added the comment: I have no specific use case. I just thought that runpy.run_path should work similarily as if the file was run directly (which works). File ∫.py can be created, displayed and run by Python with no problem in Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17588 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17619] MS WINDOWS: input() swallows KeyboardInterrupt in Python 3.3
Drekin added the comment: There is related weird behavior: try: ... input() ... except KeyboardInterrupt: ... print(exception occured) ... # Ctrl-C hit Traceback (most recent call last): File stdin, line 2, in module KeyboardInterrupt During handling of the above exception, another exception occurred: Traceback (most recent call last): File stdin, line 2, in module KeyboardInterrupt Seems like handling of Ctrl-C is kind of “out of sync”. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17619] input() swallows KeyboardInterrupt in Python 3.3
New submission from Drekin: At least on Windows, input() doesn't raise KeyboardInterrupt when Ctrl-C is hit in Python 3.3 (it does in Python 3.2). 3.3: x = input() # Ctrl-C hit - no exception raised x NameError 3.2: x = input() # Ctrl-C hit KeyboardInterrupt -- messages: 185845 nosy: Drekin priority: normal severity: normal status: open title: input() swallows KeyboardInterrupt in Python 3.3 type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
New submission from Drekin: The Python interactive console actually doesn't use sys.stdin but standard C stdin for input. Is there any reason for this? Why it then uses its encoding attribute? (Assigning sys.stdin something, that doesn't have encoding attribute freezes the interpreter.) If anything, wouldn't it make more sense if it used sys.__stdin__.encoding instead of sys.stdin? sys.stdin is intended to be set by user (it affects input() and code.inpterrupt() which tries to minic standard interactive console). -- messages: 185848 nosy: Drekin priority: normal severity: normal status: open title: Python interactive console doesn't use sys.stdin for input type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17588] runpy cannot run Unicode path on Windows
New submission from Drekin: runpy.run_path(\u222b.py) raises UnicodeEncodeError when trying to use mbcs codec on Windows. However opening the file using open() is ok. So why is runpy trying to encode the name using mbcs encoding when it's not necessary or even correct? See http://bpaste.net/show/aOqQLMyYAAFTJ8pQnkli/ . -- components: Library (Lib), Unicode, Windows messages: 185634 nosy: Drekin, ezio.melotti priority: normal severity: normal status: open title: runpy cannot run Unicode path on Windows type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17588 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: Hello. I have made a small upgrade of the workaround. • win_unicode_console.enable_streams() sets sys.stdin, stdout and stderr to custom filelike objects which use Windows functions ReadConcoleW and WriteConsoleW to handle unicode data properly. This can be done in sitecustomize.py to take effect automatically. • Since Python interactive console doesn't use sys.stdin for getting input (still don't know reason for this), there is an alternative repl based on code.interact(). win_unicode_console.IntertactiveConsole.enable() sets it up. To set it up automatically, put the enabling code into a startup file and set PYTHONSTARTUP environment variable. This works for interactive session (just running python with no script). • Since there is no hook to run InteractiveConsole.enable() when a script is run interactively (-i flag), that is after the script and before the interactive session, I have written a helper script i.py. It just runs given script and then enters an interactive mode using InteractiveConsole. Just put i.py into site-packages and run py -m i script.py arguments instead of py -i script.py arguments. It's a shame that in the year 2013 one cannot simply run Python console on Windows and enter Unicode characters. I'm not saying it's just Python fault, but there is a workaround on Python side. -- versions: +Python 3.4 Added file: http://bugs.python.org/file29563/i.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Changes by Drekin dre...@gmail.com: Added file: http://bugs.python.org/file29564/win_unicode_console_3.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: I have finished a solution working for me. It bypasses standard Python interactive interpreter and uses its own repl based on code.interact(). This repl is activated by an ugly hack since PYTHONSTARTUP doesn't apply when some file is run (python -i somefile.py). Why it works like that? Startup script could find out if a file is run or not. If anybody knows how to get rid of time.sleep() used for wait for KeyboardInterrupt or how to get rid of PromptHack, please let me know. The patch can be activated by win_unicode_console_2.enable(change_console=True, use_hack=True) in site or sitecustomize or usercustomize. -- Added file: http://bugs.python.org/file27261/win_unicode_console_2.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Drekin added the comment: Hello, I'm trying to handle Unicode input and output in Windows console and found this issue. Will this be solved in 3.3 final? I tried to write a solution (file attached) based on solution here – rewriting sys.stdin and sys.stdout so it uses ReadConsoleW and WriteConsoleW. Output works well, but there are few problems with input. First, the Python interactive interpreter actually doesn't use sys.stdin but standard C stdin. It's implemented over file pointer (PyRun_InteractiveLoopFlags, PyRun_InteractiveOneFlags in pythonrun). But still the interpreter uses sys.stdin.encoding (assigning sys.stdin something, that doesn't have encoding==None freezes the interpreter). Wouldn't it make more sense if it used sys.__stdin__.encoding? However, input() (which uses stdin.readline) works as expected. There's a small problem with KeyboardInterrupt. Since signals are processed asynchronously, it's raised at random place and it behaves wierdly. time.sleep(0.01) after the C call works well, but it's an ugly solution. When code.interact() is used instead of standard interpreter, it works as expected. Is there a way of changing the intepreter loop? Some hook which calls code.interact() at the right place? The patch can be applied in site or sitecustomized, but calling code.iteract() there obviously doesn't work. Some other remarks: - When sys.stdin or sys.stdout doesn't define encoding and errors, input() raises TypeError: bad argument type for built-in operation. - input() raises KeyboardInterrupt on Ctrl-C in Python 3.2 but not in Python 3.3rc2. -- nosy: +Drekin Added file: http://bugs.python.org/file27245/win_unicode_console.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
