[issue11395] print(s) fails on Windows with long strings

2020-04-12 Thread Adam Bartoš

Adam Bartoš  added the comment:

I've been hit by this issue recently. On my configuration, print("a" * 10215) 
fails with an infinite loop of OSErrors (WinError 8). This even cannot by 
interrupted with Ctrl-C nor the exception can be catched.

- print("a" * 10214) is fine
- print("a" * 10215) is fine when preceeded by print("b" * 2701), but not when 
preceeded by print("b" * 2700)
- the problem (or at least with these numbers) occurs only when the code is 
saved in a script, and this is run by double-clicking the file (i.e. run by 
Windows ShellExecute I guess), not by "py test.py" or interactively.

My configuration is Python 3.7.3 64 bit on Windows Vista 64 bit. I wonder if 
anyone is able to reproduce this on their configuration.

--
nosy: +Drekin

___
Python tracker 
<https://bugs.python.org/issue11395>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28373] input() prints to original stdout even if sys.stdout is wrapped

2016-10-10 Thread Adam Bartoš

Adam Bartoš added the comment:

Does GNU readline do anything fancy about printing the prompt? Because you may 
want to use GNU readline for autocompletition while still enable colored output 
via wrapped stdout. Both at the same time with one call to input(). It seems 
that currently either you go interactive and ignore sys.std*, or you lose 
readline capabilities.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28373>
___
___
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

2016-10-06 Thread Adam Bartoš

Adam Bartoš added the comment:

The main reason I have extended the support of win_unicode_console to Python 
2.7 was that the related issues won't be fixed there, so using 
win_unicode_console may fix this as well.

--

___
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



[issue28373] input() prints to original stdout even if sys.stdout is wrapped

2016-10-06 Thread Adam Bartoš

Adam Bartoš added the comment:

Other related issues are #1927 and #24829.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28373>
___
___
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

2016-10-06 Thread Adam Bartoš

Adam Bartoš added the comment:

Maybe this was fixed with the recent fix of #1602.

--

___
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



[issue28373] input() prints to original stdout even if sys.stdout is wrapped

2016-10-06 Thread Adam Bartoš

Adam Bartoš added the comment:

A related issue is that the REPL doesn't use sys.stdin for input, see #17620. 
Another related issue is #28333. I think that the situation around stdio in 
Python is complicated an inflexible (by stdio I mean all the interactions 
between REPL, input(), print(), sys.std* streams, sys.displayhook, 
sys.excepthook, C-level readline hooks). It would be nice to tidy up these 
interactions and document them at one place.

Currently, input() tries to detect whether sys.stdin and sys.stdout are 
interactive and have the right filenos, and handles the cases different way. I 
propose input() to be a thin wrapper (stripping a newline, generating EOFError) 
around proposed sys.readlinehook(). By default, sys.readlinehook would be GNU 
readline on Unix and stdio_readline (which just uses sys.stdout and sys.stdin) 
on Windows. I think that would fix all the problems like this one and 
changing/wrapping sys.std* streams would just work.

My proposal is at 
https://mail.python.org/pipermail/python-dev/2015-November/142246.html and 
there is discission at #17620. Recently, the related issue #1602 was fixed and 
there is hope there will be progress with #17620.

--
nosy: +Drekin

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28373>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue28333] input() with Unicode prompt produces mojibake on Windows

2016-10-01 Thread Adam Bartoš

New submission from Adam Bartoš:

In my setting (Python 3.6b1 on Windows), trying to prompt a non-ASCII character 
via input() results in mojibake. This is related to the recent fix of #1602 and 
so is Windows-specific.

>>> input("α")
╬▒

The result corresponds to print("α".encode("utf-8").decode("cp852")). That 
cp852 the default terminal encoding in my locale.

--
components: Unicode, Windows
messages: 277821
nosy: Drekin, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, 
zach.ware
priority: normal
severity: normal
status: open
title: input() with Unicode prompt produces mojibake on Windows
type: behavior
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28333>
___
___
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

2016-08-14 Thread Adam Bartoš

Adam Bartoš added the comment:

> Unfortunately, it looks like detecting when a readline hook has been added is 
> going to involve significant changes to the tokenizer, which I really don't 
> want to do.

We don't need to detect the presence of readline hook, it may be so that there 
is always a readline hook. Whenever we have interactive stdio, and so 
PyOS_Readline is called, the new proposed API PyIO_Readline would be called 
instead. This would return Unicode str Py_Object*, so the result can be 
directly returned by input() and should be somehow encoded afterwards by the 
tokenizer (these are the only consumers of PyOS_Readline). 

We may even leave the tokenizer alone and redefine PyOS_Readline as a wrapper 
of PyIO_Readline, having full control of the encoding process there. So it 
would be enough to set up the tokenizer with UTF-8 encoding despite the fact 
that sys.std*.encoding would be UTF-16.

(I hope that if the tokenizer was desiged nowdays, it would operate on strings 
rather than bytes so there won't be any encoding problems at all.)

Also, third parties would benefit from sys.readlinehook – at least 
win_unicode_console and pyreadline would just set the attribute rather than 
messing with ctypes.

--

___
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

2016-08-14 Thread Adam Bartoš

Adam Bartoš added the comment:

There is also the following consequence of (not) having the standard filenos: 
input() either considers the streams interactive or not. To consider them 
interactive, standard filenos and isatty are needed on sys.stdin and sys.stdout.

If the streams are considered interactive, input() goes via readlinehook 
machinery, otherwise it just writes and reads an ordinary file.

The latter means we don't have to touch readline machinery now, the downside is 
that custom rlcompleters like pyreadline won't work on input().

--

___
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

2016-08-13 Thread Adam Bartoš

Adam Bartoš added the comment:

Hello Steve, that's great you are working on this!

I've ran through your patch and I have the following remarks:

• Since wide chars have two bytes, there may be problem when someone wants to 
read or write odd number of bytes. If the number is > 1, it's ok since the code 
may read or write less bytes, but when the number is exactly 1, the code should 
maybe raise some exception.

• WriteConsoleW always fails with ERROR_NOT_ENOUGH_MEMORY (8) if we try to 
write more than a certain number of bytes. For me, the number is something like 
41000. Unfortunately, it depends on actual heap usage of the console process. I 
do len = min(len, 32767) in write. The the value chosen comes from issue11395 .

• If someone types something like ^Zfoo, the standard sys.stdin returns '' -- 
it ignores everything after EOF if it is the first byte read. I reproduce the 
bahaviour in win_unicode_console to be compatible.

• There may be some issue when someone hits Ctrl-C on input. It seems that in 
that case, ReadConsoleW fails with ERROR_OPERATION_ABORTED (995) and some 
signal is asynchronously fired. It may happen that the corresponding 
KeyboardInterrupt exception occurs later that it should. In my Python/ctypes 
situation I do an ugly hack – I detect ERROR_OPERATION_ABORTED and in that case 
I sleep for 0.1 seconds to wait for the exception. I understand that the 
situation may me different in C.

--

___
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



[issue27582] Mispositioned SyntaxError caret for unknown code points

2016-07-22 Thread Adam Bartoš

Adam Bartoš added the comment:

Maybe this is related: http://bugs.python.org/issue26152.

--
nosy: +Drekin

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27582>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27469] Unicode filename gets crippled on Windows when drag and drop

2016-07-09 Thread Adam Bartoš

Adam Bartoš added the comment:

Without a handler the drop feature is disabled.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27469>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27469] Unicode filename gets crippled on Windows when drag and drop

2016-07-09 Thread Adam Bartoš

Adam Bartoš added the comment:

Also, what versions of Windows does this affect? I have 64bit Vista, so maybe 
this is fixed in say Windows 10.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27469>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27469] Unicode filename gets crippled on Windows when drag and drop

2016-07-09 Thread Adam Bartoš

Adam Bartoš added the comment:

Thank you very much for the analysis. So Python Windows installers may be 
changed to set the other drop handler. If the short paths are problem, they may 
be converted to long ones when initializing `sys.argv`.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27469>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27469] Unicode filename gets crippled on Windows when drag and drop

2016-07-08 Thread Adam Bartoš

New submission from Adam Bartoš:

When a Python script is run by drag-and-dropping another file on it in Windows 
explorer, the other file's path becomes sys.argv[1]. However, when the path 
contains a Unicode characters (e.g. α), it gets crippled – it is replaced by 
ordinary question mark.

Maybe this is not Python's fault. Calling directly GetCommandLineW already 
contains that question mark. I'm just curious whether the original path even 
can be reconstructed.

--
components: Unicode, Windows
messages: 269991
nosy: Drekin, ezio.melotti, haypo, paul.moore, steve.dower, tim.golden, 
zach.ware
priority: normal
severity: normal
status: open
title: Unicode filename gets crippled on Windows when drag and drop
type: behavior
versions: Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27469>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26090] More correct string truncating in PyUnicode_FromFormat()

2016-06-21 Thread Adam Bartoš

Changes by Adam Bartoš <dre...@gmail.com>:


--
nosy: +Drekin

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26090>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue13592] repr(regex) doesn't include actual regex

2016-06-20 Thread Adam Bartoš

Adam Bartoš added the comment:

Isn't the trucation of long patterns too rough? Currently, repr(re.compile("a" 
* 1000)) returns something like "re.compile('a)", i.e. no ending 
quote and no indication that something was truncated (besides the missing 
quote). It looked like a bug to me at first sight.

--
nosy: +Drekin

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13592>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1927] Change input() to always prompt to stderr

2016-06-14 Thread Adam Bartoš

Adam Bartoš added the comment:

Regarding the comment by Martin Panter from 2015-11-22: It would be nice if 
PyOS_StdioReadline worked that way. Unfortunately, it's still based on C file 
objects and char* for the prompt string rather than using actual Python 
objects. The relevant issue is issue17620 .

--
nosy: +Drekin

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1927>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19570] distutils' Command.ensure_dirname fails on Unicode

2016-06-13 Thread Adam Bartoš

Adam Bartoš added the comment:

Recently, I was also hit by this when trying to autoset `sys.argv` to a list of 
Unicode string (see 
https://github.com/Drekin/win-unicode-console/issues/20#issuecomment-225638271 
).

It would be nice to have this fixed. It seems to me (I may be wrong) that every 
occurence of `isinstance(…, str)` is a potential bug in Python 2.7. Either it 
should be spelled out as `isinstance(…, bytes)` or there should be 
`isinstance(…, types.StringTypes)` or even `isinstance(…, unicode)`.

--
nosy: +Drekin

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19570>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue27268] Incorrect error message on float('')

2016-06-08 Thread Adam Bartoš

New submission from Adam Bartoš:

>>> float('foo')
ValueError: could not convert string to float: 'foo'
>>> float('')
ValueError: could not convert string to float: 

should be
ValueError: could not convert string to float: ''

The message comes from Objects/floatobject.c:183 but I don't understand how the 
empty string gets discarded.

--
components: Interpreter Core
messages: 267858
nosy: Drekin
priority: normal
severity: normal
status: open
title: Incorrect error message on float('')
type: behavior
versions: Python 3.5

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27268>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26152] A non-breaking space in a source

2016-01-20 Thread Adam Bartoš

Adam Bartoš added the comment:

We have one particular invalid token, so why it should point to the next token 
rather than to the invalid one?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26152>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26152] A non-breaking space in a source

2016-01-20 Thread Adam Bartoš

Adam Bartoš added the comment:

It could still point to the first or the last byte of the invalid token rather 
than to the start of the next token. Also, by the Python implementation of the 
tokenizer in tokenize module we get an ERRORTOKEN containing a non-breaking 
space followed by a number token containing 2.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26152>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26152] A non-breaking space in a source

2016-01-20 Thread Adam Bartoš

Adam Bartoš added the comment:

That explains the message. But why is the caret at a wrong place?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26152>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue26152] A non-breaking space in a source

2016-01-19 Thread Adam Bartoš

New submission from Adam Bartoš:

Consider the following code:
>>> 1, 2
  File "", line 1
1, 2
   ^
SyntaxError: invalid character in identifier

The error is due to the fact, that the space before "2" is actually a 
non-breaking space. The error message and the position of the caret is 
misleading.

The tokenize module gives an ERRORTOKEN at the position of the space, so 
shouldn't the massage be more like "invalid syntax" with the correct position 
or even something more appropriate?

--
components: Interpreter Core, Unicode
messages: 258584
nosy: Drekin, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: A non-breaking space in a source
type: behavior
versions: Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26152>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue25834] getpass falls back when sys.stdin is changed

2015-12-10 Thread Adam Bartoš

New submission from Adam Bartoš:

There is a check in Lib/getpass.py:win_getpass that causes a fallback version 
to be used when `sys.stdin` is changed. I change `sys.stdin` in my 
`win_unicode_console` package, and in this situation there is no reason to use 
the fallback version (see 
https://github.com/Drekin/win-unicode-console/issues/24).

It seems the check was added because of some issue with IDLE 
(https://hg.python.org/cpython/rev/6d5ac3c43416). Could this check be changed 
so it satisfies all the needs?

--
components: Library (Lib), Windows
messages: 256180
nosy: Drekin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: getpass falls back when sys.stdin is changed
type: behavior
versions: Python 3.5, Python 3.6

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25834>
___
___
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

2015-11-28 Thread Adam Bartoš

Adam Bartoš added the comment:

I've formulated a proposal regarding this issue: 
https://mail.python.org/pipermail/python-dev/2015-November/142246.html . Does 
it make sense?

--

___
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



[issue12869] PyOS_StdioReadline is printing the prompt on stderr

2015-11-22 Thread Adam Bartoš

Adam Bartoš added the comment:

> * The interactive interpreter always reads from the original standard input, 
> whether Readline is used or not.

This is not true – the interactive interpreter reads via PyOS_Readline, which 
may call whatever readline hook is installed.

I think the situation would be much more clear if something like my proposal 
was implemented 
(https://mail.python.org/pipermail/python-dev/2015-November/142246.html).

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12869>
___
___
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

2015-11-09 Thread Adam Bartoš

Adam Bartoš added the comment:

dead1ne: Hello, I'm maintaining a package that tries to solve this issue: 
https://github.com/Drekin/win-unicode-console . There are actually many related 
problems.

--

___
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



[issue24829] Use interactive input even if stdout is redirected

2015-09-01 Thread Adam Bartoš

Adam Bartoš added the comment:

How about reconsidering in the case that the machinery around PyOS_Readline is 
rewritten as I suggest in #17620 ?

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24829>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23572] functools.singledispatch fails when not BaseClass is True

2015-08-16 Thread Adam Bartoš

Adam Bartoš added the comment:

I was also bitten by this via Enum. Is there any chance this will be fixed in 
Python 3.5?

--
nosy: +Drekin

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23572
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9232] Allow trailing comma in any function argument list.

2015-08-11 Thread Adam Bartoš

Adam Bartoš added the comment:

Some remarks:

• A trailing comma after a non-empty argument list is allowed in every call 
form, including class statement and optional call in decorator syntax. In the 
grammar, this correponds to `arglist`.

• In function definition, trailing comma is allowed only if there is no star 
before:
def f(a, b, c,): # allowed
def f(a=1, b=2, c=3,): # allowed
def f(*args,): # disallowed
def f(**kwargs,): # disallowed
def f(*, a, b, c,): # disallowed
The last example is what bothers me. The presence of the star should not affect 
whether trailing comma is allowed or not. If `f(a, b, c,)` is allowed as a 
call, it should be allowed in a definition, and if def `f(a, b, c,)` is 
allowed, `f(*, a, b, c,)` should be allowed as well.

In the grammar this corresponds to `typedargslist` for functions and 
`varargslist` for lambdas.

• A traling comma is allowed in tuples, lists, dicts, sets, the corresponding 
comprehensions, augmented assignments, and subscripts. It is also allowed in 
`from module import names` in the names part, but only if there are surrounding 
parentheses. Also a trailing semicolon is allowed for multiple statements in 
one line.

• A traling comma is *not* allowed in with statement, `import modules`, assert 
statement (there is just optional second argument), global and nonlocal 
statements. In all these cases surrounding parentheses are not allowed.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9232
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9232] Allow trailing comma in any function argument list.

2015-08-11 Thread Adam Bartoš

Adam Bartoš added the comment:

Do we want to allow a trailing comma after *args or **kwargs in a function 
definition? Unlike in a call, **kwargs is always the last thing in the list and 
nothing can be added after that. Just asking.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9232
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12854] PyOS_Readline usage in tokenizer ignores sys.stdin/sys.stdout

2015-08-08 Thread Adam Bartoš

Adam Bartoš added the comment:

http://bugs.python.org/issue17620 is a duplicate, but with more discussion.

--
nosy: +Drekin

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12854
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24829] Use interactive input even if stdout is redirected

2015-08-08 Thread Adam Bartoš

New submission from Adam Bartoš:

Currently, if one redirects stdout, readline hook is not used (see 
https://hg.python.org/cpython/file/default/Parser/myreadline.c#l208). I would 
assume that if I run Python as py -i  output.txt, I can use GNU readline or 
other readline hook for input just like normal; only the output is redirected 
to the file.

--
messages: 248271
nosy: Drekin
priority: normal
severity: normal
status: open
title: Use interactive input even if stdout is redirected
type: behavior

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24829
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue19518] Add new PyRun_xxx() functions to not encode the filename

2015-08-04 Thread Adam Bartoš

Adam Bartoš added the comment:

I'm not sure this is the right issue. The support for Unicode filenames is not 
(at least on Windows) ideal.

Let α.py be a Python script with invalid syntax.

 py α.py
  File encoding error, line 2
as as compile error
 ^
SyntaxError: invalid syntax

On the other hand, if run.py is does something like

path = sys.argv[1]
with tokenize.open(path) as f:
source = f.read()
code = compile(source, path, exec)
exec(code, __main__.__dict__)

we get 
 py run.py α.py
  File Python Unicode\\u03b1.py, line 2
as as compile error
 ^
SyntaxError: invalid syntax

(or 'File Python Unicode\α.py, line 2' depending on whether sys.stdout can 
encode the string).

So the encoding error in the first example is unfortunate as it is easy to 
get better result even by a simple pure Python approach.

--
nosy: +Drekin

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19518
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24771] Cannot import _tkinter in Python 3.5 on Windows

2015-08-01 Thread Adam Bartoš

Adam Bartoš added the comment:

It seems that both tcl86t.dll and tk86t.dll can be found, but their dependency 
VCRUNTIME140.dll cannot. For some reason, Dependency Walker cannot locate also 
python35.dll and ieshims.dll (but it tries to find all three libraries in 
Python 3.5\DLLs and at least python35.dll is located directly in Python 3.5 
directory).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24771
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24771] Cannot import _tkinter in Python 3.5 on Windows

2015-08-01 Thread Adam Bartoš

New submission from Adam Bartoš:

I found out that I cannot import tkinter in Python 3.5.0b4 on 64-bit Windows 
Vista. Trying to import _tkinter results in ImportError: DLL load failed. On 
the other hand I have no problem importing _ctypes whose .pyd file is at the 
same location as _tkinter.pyd.

--
components: Tkinter, Windows
messages: 247802
nosy: Drekin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cannot import _tkinter in Python 3.5 on Windows
type: behavior
versions: Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24771
___
___
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

2015-07-27 Thread Adam Bartoš

Adam Bartoš added the comment:

Yes, it is a behavior change between Python 2 and Python 3. I just tried with 
2.7 and 3.0.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18838
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24695] Don't print traceback header if traceback is None in TracebackException

2015-07-26 Thread Adam Bartoš

Adam Bartoš added the comment:

I meant this one: 
https://docs.python.org/3.5/whatsnew/changelog.html#python-3-5-beta-4 .

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24695
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24695] Don't print traceback header if traceback is None in TracebackException

2015-07-26 Thread Adam Bartoš

Adam Bartoš added the comment:

Ok, thanks.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24695
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24695] Don't print traceback header if traceback is None in TracebackException

2015-07-26 Thread Adam Bartoš

Adam Bartoš added the comment:

Just out of my curiosity – why is not this issue listed in Python 3.5b4 
changelog even though the issue is fixed there?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24695
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24695] Don't print traceback header if traceback is None in TracebackException

2015-07-24 Thread Adam Bartoš

Adam Bartoš added the comment:

Thank you all for a quick reaction.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24695
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24695] Don't print traceback header if traceback is None

2015-07-23 Thread Adam Bartoš

New submission from Adam Bartoš:

The documentation of traceback.print_exception says if traceback is not None, 
it prints a header Traceback (most recent call last):. That also meant that 
the header wasn't printed if traceback was None. However, the new Python 3.5 
TracebackException object always prints the header.

--
components: Library (Lib)
messages: 247208
nosy: Drekin
priority: normal
severity: normal
status: open
title: Don't print traceback header if traceback is None
type: behavior
versions: Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24695
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24696] Don't use None as sentinel for traceback

2015-07-23 Thread Adam Bartoš

New submission from Adam Bartoš:

There is a subtle bug in Python 3.4 implementation of traceback library:

 import traceback

 try:
... 1 / 0
... except Exception as e:
... exc = e
...
 traceback.print_exception(exc.__class__, exc, exc.__traceback__)
Traceback (most recent call last):
  File stdin, line 2, in module
ZeroDivisionError: division by zero
 
 traceback.print_exception(exc.__class__, exc, None)
Traceback (most recent call last):
  File stdin, line 2, in module
ZeroDivisionError: division by zero
 
 traceback.print_exception(exc.__class__, exc, None, chain=False)
ZeroDivisionError: division by zero

As can be seen, giving None traceback is ignored if chain == True. This is 
because None is incorrectly used as a sentinel value in traceback._iter_chain 
(see line 135).

Note that this bug is fixed in Python 3.5 since there is a new implementation 
of traceback module using TracebackException objects. Will this be backported 
to Python 3.4? Otherwise, the bug itself should be fixed anyway.

--
components: Library (Lib)
messages: 247210
nosy: Drekin
priority: normal
severity: normal
status: open
title: Don't use None as sentinel for traceback
type: behavior
versions: Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24696
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24677] def f(*args, ): pass does not compile

2015-07-21 Thread Adam Bartoš

New submission from Adam Bartoš:

I think that a trailing comma in function definition should be allowed also 
after *. 

Current situation with definitions:
def f(*args, ): pass # SyntaxError
def f(*, ): pass # SyntaxError
def f(*, a, ): pass # SyntaxError
def f(*, a=2, ): pass # SyntaxError

def f(a, ): pass # Ok
def f(, ): pass # SyntaxError – this should probably stay error

Corresponding calls:
f(*args, ) # Ok
f(*args, a, ) # Ok
f(*args, a=2, ) # Ok 

f(a, ) # Ok
f(, ) # SyntaxError – this is why the corresponding def behavior should stay

My use case:
def f(*, 
long = 1, 
list = 2, 
of = 3, 
kwonly = 4, 
parameters = 5, 
):
...

--
messages: 247023
nosy: Drekin
priority: normal
severity: normal
status: open
title: def f(*args, ): pass does not compile

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24677
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue9232] Allow trailing comma in any function argument list.

2015-07-21 Thread Adam Bartoš

Adam Bartoš added the comment:

Reposting from from my newest duplicate of this issue (Issue 24677), which is 
now closed:

I think that a trailing comma in function definition should be allowed also 
after *. 

Current situation with definitions:
def f(*args, ): pass # SyntaxError
def f(*, ): pass # SyntaxError
def f(*, a, ): pass # SyntaxError
def f(*, a=2, ): pass # SyntaxError

def f(a, ): pass # Ok
def f(, ): pass # SyntaxError – this should probably stay error

Corresponding calls:
f(*args, ) # Ok
f(*args, a, ) # Ok
f(*args, a=2, ) # Ok 

f(a, ) # Ok
f(, ) # SyntaxError – this is why the corresponding def behavior should stay

My use case:
def f(*, 
long = 1, 
list = 2, 
of = 3, 
kwonly = 4, 
parameters = 5, 
):
...

--
nosy: +Drekin

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9232
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23057] [Windows] asyncio: support signal handlers on Windows (feature request)

2015-07-07 Thread Adam Bartoš

Adam Bartoš added the comment:

David Robertson: The behaviour you pointed out is a consequence of the general 
issue: signals on Windows aren't fully supported. Basically, they cannot 
interrupt the event loop when every coroutine is waiting for something. 
Instead, they are fired when something happens – some data are recieved or some 
timer reaches zero. In your case it was the connection of the client or the 
message it sent.

This is the right issue related to your problem. Hopefully, it will be fixed 
eventually. A current workaround is to schedule a task which periodically 
sleeps for an amount of time. For example, if it allways sleeps for one second, 
then you will wait for KeyboardInterrupt at most one second.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23057
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue23057] [Windows] asyncio: support signal handlers on Windows (feature request)

2015-07-05 Thread Adam Bartoš

Adam Bartoš added the comment:

I've also run into this issue (see 
https://mail.python.org/pipermail/python-list/2015-July/693496.html and the 
following thread). I'm adding some small examples showing the behavior.

import asyncio

async def wait():
await asyncio.sleep(5)

loop = asyncio.get_event_loop()
loop.run_until_complete(wait())

---

The following even smaller example by Terry Reedy and the OP from 
http://stackoverflow.com/questions/27480967/why-does-the-asyncios-event-loop-suppress-the-keyboardinterrupt-on-windows
 cannot be interrupted other way then shuting down whole process:

asyncio.get_event_loop().run_forever()

---

It would be nice the patch mentioned was eventually applied.

--
nosy: +Drekin

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23057
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com