[issue24567] random.choice IndexError due to double-rounding

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Unfortunately a link to Rietveld is not available for review and inlined 
comments.

In sample() the selected set can be initialized to {n} to avoid additional 
checks in the loop for large population. In the branch for small population, 
non-empty pool can be extended ("pool.append(pool[-1])") to avoid additional 
check in the loop.

In choice() I would write the condition as "i == n > 0" to avoid indexing with 
negative index. Custom collection can has non-standard behavior with negative 
indices. This doesn't add additional cost in normal case.

--

___
Python tracker 

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

[issue24567] random.choice IndexError due to double-rounding

[Raymond Hettinger]

Changes by Raymond Hettinger :


Added file: http://bugs.python.org/file39905/handle_double_rounding2.diff

___
Python tracker 

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

[issue24567] random.choice IndexError due to double-rounding

[Raymond Hettinger]

Changes by Raymond Hettinger :


Removed file: http://bugs.python.org/file39903/handle_double_rounding.diff

___
Python tracker 

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

[issue24379] operator.subscript

[Joe Jevnik]

Joe Jevnik added the comment:

updating to address the docs and order of assertions

--
Added file: http://bugs.python.org/file39904/operator_subscript_pyonly.patch

___
Python tracker 

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

[issue24567] random.choice IndexError due to double-rounding

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
keywords: +patch
Added file: http://bugs.python.org/file39903/handle_double_rounding.diff

___
Python tracker 

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

[issue24379] operator.subscript

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The implementation itself LGTM (nice use of decorator). New feature should be 
documented. Needed changes in Doc/library/operator.rst and Doc/whatsnew/3.6.rst 
and the docstring for the subscript class. 'subscript' should be added to 
__all__.

--

___
Python tracker 

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

[issue23220] Documents input/output effects of how IDLE runs user code

[Martin Panter]

Martin Panter added the comment:

I wouldn’t say TK ignores carriage returns, though I agree it would be better 
if Idle stripped them out. Currently I get a glyph displayed for them, 
similarly to \b. They wouldn’t copy to my clipboard, so I fudged them after 
pasting here:

>>> _ = stdout.write("CRLF\r\n")  # Linux: box-drawing corner piece
CRLF┌
>>> _ = stdout.write("CRLF\r\n")  # Wine: euro sign
CRLF€

--

___
Python tracker 

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

[issue24587] Tkinter stacking versus focus behavior on Windows

[Eugene K.]

Eugene K. added the comment:

It may not be a pure Python bug, but it's definitely at least a tk bug (which 
makes it a Python bug as long as tk is the canonical UI package in Python.) 

Workarounds are nice, but a workaround fixes my specific problem here and now, 
while leaving unknown numbers of Python UI developers scratching their heads at 
the unexpected behavior of their code.

I don't object to closing this bug as long as it's forwarded to tk/tkinter 
developers first.

--

___
Python tracker 

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

[issue24567] random.choice IndexError due to double-rounding

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

For shuffle I would write "if j < i".

I think 3.x should be fixed as well as 2.7. And I like Tim's suggestion about 
import-time patching.

--

___
Python tracker 

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

[issue24379] operator.subscript

[Joe Jevnik]

Joe Jevnik added the comment:

updating with the slots change

This also adds a ton of test cases

--
Added file: http://bugs.python.org/file39902/operator_subscript_pyonly.patch

___
Python tracker 

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

[issue23220] Documents input/output effects of how IDLE runs user code

[Terry J. Reedy]

Terry J. Reedy added the comment:

I was thinking AttributeError, as mentioned in the previous sentence.  But you 
are correct that ImportError is possible too.  Maybe I should just give the 
code.

try:
import idlelib
idlelib.run
running_idle = True
except (ImportError, AttributeError):
running_idle = False

tk does not 'handle' stdout. Idle does, by inserting strings into a tk text 
widget. tk does not care where inserted chars come from. tk \b behavior is OS 
dependent. tk may always ignore \r, but this is different from (at least some) 
consoles. Attempt 2, with and added paragraph.

...
  * Except for newline ('\n'), tk handling of ascii control chars may depend on 
the OS and may by different from text consoles.  Both are true for backspace 
('\b') and the latter for return ('\r'), which tk ignores.

These differences noted above are not bugs. If an application is going to be 
run repeatedly after being developed with Idle, it should usually be run 
directly, without Idle.  (An exception would be non-gui Windows apps that need 
tk's better unicode support.) That means testing at least once without Idle.
---

Thanks for the comments.

--
stage: needs patch -> patch review

___
Python tracker 

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

[issue24567] random.choice IndexError due to double-rounding

[Raymond Hettinger]

Raymond Hettinger added the comment:

See the attached timings.  The performance hit isn't bad and the code's beauty 
isn't marred terribly.   Yes, we'll fix it, but no I don't have to feel good 
about it ;-)

--

___
Python tracker 

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

[issue24613] array.fromstring Use After Free

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
components: +Extension Modules
nosy: +serhiy.storchaka
stage:  -> patch review

___
Python tracker 

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

[issue24587] Tkinter stacking versus focus behavior on Windows

[Terry J. Reedy]

Terry J. Reedy added the comment:

The issue is the interaction between stacking and focus. I am pretty sure that 
this is not a Python bug and that this issue should be closed.  I suspect that 
the behavior is not even a tk bug, but simply how Windows' graphics system work.

In any case, the attached file avoids the stacking issue by temporarily 
replacing a Button with an Entry in a grid. It works on Windows 2 and 3 (the 
upload file has 'tkinter' for 3.x) and should work anywhere.  I leave it to you 
to add grid args to position and anchor the widgets better.  Also, the Entry 
widgets need to be a bit taller to match the Buttons.

--
title: Incorrect tkinter behavior of slave widgets of Button -> Tkinter 
stacking versus focus behavior on Windows
Added file: http://bugs.python.org/file39901/tem.py

___
Python tracker 

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

[issue23220] Documents input/output effects of how IDLE runs user code

[Martin Panter]

Martin Panter added the comment:

“run ``import idlelib; idlelib.run`` within a try-except statement”: It might 
be nice to say what exceptions are expected. My guess is ImportError if Idle or 
TK is not available, or AttributeError if it is but Idle is not running.

“Tk handling of ascii control chars”: I presume you mean stdout and stderr 
handling, which this bug was originally about (or also input, source code, etc 
as well?). It might be good to say that output of Unix newlines (\n) is 
guaranteed to be supported. Also might be worth explicitly pointing out that 
output of CRLFs is not supported, even if os.linesep is "\r\n". In my 
experiments between Linux and Wine, this does not appear to depend on the OS.

--

___
Python tracker 

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

[issue24379] operator.subscript

[Joe Jevnik]

Joe Jevnik added the comment:

Ah, I hadn't seen that, I will address those now, sorry about that.

--

___
Python tracker 

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

[issue24379] operator.subscript

[Martin Panter]

Martin Panter added the comment:

Joe: Have you seen the comments on the code review? See the Review link at the 
top of the bug thread, or maybe check your spam.

--
nosy: +vadmium
stage:  -> patch review

___
Python tracker 

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

[issue24567] random.choice IndexError due to double-rounding

[Tim Peters]

Tim Peters added the comment:

[Raymond]
> I can't say that I feel good about making everyone pay
> a price for a problem that almost no one ever has.

As far as I know, nobody has ever had the problem.  But if we know a bug 
exists, I think it's at best highly dubious to wait for a poor user to get 
bitten by it.  Our bugs aren't their fault, and we have no idea in advance how 
much our bugs may cost them.

Note that there's no need to change anything on boxes without double-rounding, 
and those appear to be the majority of platforms now, and "should" eventually 
become all platforms as people migrate to 64-bit platforms.  So, e.g.,

if double_rounding_happens_on_this_box:
def choice(...):
# fiddled code
else:
def choice(...):
# current code just indented a level

Then most platforms pay nothing beyond a single import-time test.  Note that 
there's already code to detect double-rounding in test_math.py, but in that 
context not to _fix_ a problem but to ignore fsum() tests that fail in its 
presence.

And just to be annoying ;-) , here's another timing variation:

i = int(random() * n)
return seq[i - (i == n)]

--

___
Python tracker 

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

[issue24613] array.fromstring Use After Free

[John Leitch]

John Leitch added the comment:

Attaching patch.

--
keywords: +patch
Added file: http://bugs.python.org/file39900/arraymodule.c.patch

___
Python tracker 

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

[issue24613] array.fromstring Use After Free

[John Leitch]

New submission from John Leitch:

The Python array.fromstring() method suffers from a use after free caused by 
unsafe realloc use. The issue is triggered when an array is concatenated to 
itself via fromstring() call:

static PyObject *
array_fromstring(arrayobject *self, PyObject *args)
{
char *str;
Py_ssize_t n;
int itemsize = self->ob_descr->itemsize;
if (!PyArg_ParseTuple(args, "s#:fromstring", &str, &n))  The str buffer 
is parsed from args. In cases where an array is passed to itself, self->ob_item 
== str.
return NULL;
if (n % itemsize != 0) {
PyErr_SetString(PyExc_ValueError,
   "string length not a multiple of item size");
return NULL;
}
n = n / itemsize;
if (n > 0) {
char *item = self->ob_item;  If str == self->ob_item, item == str.
if ((n > PY_SSIZE_T_MAX - Py_SIZE(self)) ||
((Py_SIZE(self) + n) > PY_SSIZE_T_MAX / itemsize)) {
return PyErr_NoMemory();
}
PyMem_RESIZE(item, char, (Py_SIZE(self) + n) * itemsize);  A 
realloc call occurs here with item passed as the ptr argument. Because realloc 
sometimes calls free(), this means that item may be freed. If item was equal to 
str, str is now pointing to freed memory.
if (item == NULL) {
PyErr_NoMemory();
return NULL;
}
self->ob_item = item;
Py_SIZE(self) += n;
self->allocated = Py_SIZE(self);
memcpy(item + (Py_SIZE(self) - n) * itemsize,
   str, itemsize*n);  If str is dangling at this point, a use 
after free occurs here.
}
Py_INCREF(Py_None);
return Py_None;
}

In most cases when this occurs, the function behaves as expected; while the 
dangling str pointer is technically pointing to deallocated memory, given the 
timing it is highly likely the memory contains the expected data. However, 
ocassionally, an errant allocation will occur between the realloc and memcpy, 
leading to unexpected contents in the str buffer.

In applications that expose otherwise innocuous indirect object control of 
arrays as attack surface, it may be possible for an attacker to trigger the 
corruption of arrays. This could potentially be exploited to exfiltrate data or 
achieve privilege escalation, depending on subsequent operations performed 
using corrupted arrays.

A proof-of-concept follows:

import array
import sys
import random

testNumber = 0

def dump(value):
global testNumber
i = 0
for x in value:
y = ord(x)
if (y != 0x41): 
end = ''.join(value[i:]).index('A' * 0x10)
sys.stdout.write("%08x a[%08x]: " % (testNumber, i))
for z in value[i:i+end]: 
sys.stdout.write(hex(ord(z))[2:])
sys.stdout.write('\r\n')
break   
i += 1

def copyArray():
global testNumber
while True:
a=array.array("c",'A'*random.randint(0x0, 0x1))
a.fromstring(a)
dump(a)
testNumber += 1

print "Starting..." 
copyArray()

The script repeatedly creates randomly sized arrays filled with 0x41, then 
calls fromstring() and checks the array for corruption. If any is found, the 
relevant bytes are written to the console as hex. The output should look 
something like this:

Starting...
0007 a[0cdc]: c8684d0b0f54c0
001d a[f84d]: b03f4f0b8be620
0027 a[119f]: 50724d0b0f54c0
004c a[0e53]: b86b4d0b0f54c0
005a a[01e1]: d8ab4609040620
0090 a[015b]: 9040620104e5f0
014d a[02d6]: 10ec620d8ab460
0153 a[00f7]: 9040620104e5f0
023c a[0186]: 50d34c0f8b65a0
0279 a[01c3]: d8ab4609040620
02ee a[0133]: 9040620104e5f0
02ff a[0154]: 9040620104e5f0
030f a[0278]: 10ec620d8ab460
0368 a[0181]: 50d34c0f8b65a0
03b2 a[005a]: d0de5f0d05e5f0
03b5 a[021c]: b854d00d3620
0431 a[01d8]: d8ab4609040620
044b a[02db]: 10ec620d8ab460
0461 a[00de]: 9040620104e5f0
04fb a[232f]: 10f74d0c0ce620
0510 a[014a]: 9040620104e5f0

In some applications, such as those that are web-based, similar circumstances 
may manifest that would allow for remote exploitation.

To fix the issue, array_fromstring should check if self->ob_item is pointing to 
the same memory as str, and handle the copy accordingly. A proposed patch is 
attached.

--
files: array.fromstring-Use-After-Free.py
messages: 246621
nosy: JohnLeitch
priority: normal
severity: normal
status: open
title: array.fromstring Use After Free
type: security
versions: Python 2.7
Added file: http://bugs.python.org/file39899/array.fromstring-Use-After-Free.py

___
Python tracker 

___
__

[issue24612] not operator expression raising a syntax error

[Martin Panter]

Martin Panter added the comment:

BTW “yield” is not a fair comparison because its syntax is even stranger (due 
to originally being a “yield” statement):

def g():
x = yield + 1  # Yield the value +1
y = (yield) + 1  # Add 1 after yielding
return (yield)  # Mandatory brackets

--

___
Python tracker 

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

[issue24612] not operator expression raising a syntax error

[Martin Panter]

Martin Panter added the comment:

Funny, I ran into this one or two days ago, when refactoring some code that 
used the bitwise exclusive-or operator, since there is no boolean exclusive or:

-if (x == a) ^ (y != b): ...
+aa = x == a
+bb = y == b
+if aa ^ not bb: ...

It is fairly clear what I wanted to do above, but with “is not” you would have 
to avoid ambiguity:

>>> "spam" is not "ham"  # Using “is not” operator
True
>>> "spam" is (not "ham")  # Two distinct operators
False

I think it would be too complicated to make unary “not” bind more tightly than 
“and” in some cases but not in others. How would you handle these cases?

a + not b and c
a ** not b ** c
a is not not b

The way I see it, there is no equivalent problem with the other unary 
operators: arithmetic (+, -), bitwise (~), and “await”. Await has higher 
priority than all other binary operators, so no problem there. The other three 
are equal with the highest priority binary operator, exponentiation (**):

>>> 2 ** -1 ** 2  # Evaluated right to left
0.5
>>> 2 ** (-1) ** 2  # Negation first
2
>>> (2 ** -1) ** 2  # Left-hand exponentiation first
0.25

BTW, in the operator precedence table 
, I 
think exponentiation should be in the same priority group as the arithmetic and 
bitwise unary operations. At the moment it says exponentiation has higher 
priority, but has a footnote saying this is reversed on the right-hand side of 
an exponentiation. This is unclear when applied to my example above.

--

___
Python tracker 

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

[issue24567] random.choice IndexError due to double-rounding

[Raymond Hettinger]

Changes by Raymond Hettinger :


Added file: http://bugs.python.org/file39898/shuffle_timings.txt

___
Python tracker 

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

[issue24379] operator.subscript

[Joe Jevnik]

Joe Jevnik added the comment:

ping: is there anything blocking this?

--

___
Python tracker 

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

[issue24567] random.choice IndexError due to double-rounding

[Raymond Hettinger]

Changes by Raymond Hettinger :


Added file: http://bugs.python.org/file39897/choice_timings.txt

___
Python tracker 

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

[issue24610] Incorrect example Unicode string in docs footnote

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1cae77f873af by Benjamin Peterson in branch '3.4':
fix normalization example (closes #24610)
https://hg.python.org/cpython/rev/1cae77f873af

New changeset 0127b0cad5ec by Benjamin Peterson in branch '3.5':
merge 3.4 (#24610)
https://hg.python.org/cpython/rev/0127b0cad5ec

New changeset 02b81a82a57d by Benjamin Peterson in branch 'default':
merge 3.5 (#24610)
https://hg.python.org/cpython/rev/02b81a82a57d

--
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

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

[issue24567] random.choice IndexError due to double-rounding

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger

___
Python tracker 

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

[issue24567] random.choice IndexError due to double-rounding

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, here are some variants (with differing degrees of brevity, clarity, and 
performance):

   def choice(self, seq):
"""Choose a random element from a non-empty sequence."""
n = len(seq)
i = int(self.random() * n)
if i == n:
i = n - 1
return seq[i]

def choice(self, seq):
"""Choose a random element from a non-empty sequence."""
try:
return seq[int(self.random() * len(seq))]   
  
except IndexError:
return seq[-1]

def choice(self, seq):
"""Choose a random element from a non-empty sequence."""
n = len(seq)
return seq[min(int(self.random() * n), n-1)]

--

___
Python tracker 

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

[issue24567] random.choice IndexError due to double-rounding

[Raymond Hettinger]

Raymond Hettinger added the comment:

[Antoine]
> If that would give a different sequence of random numbers, 
> I'm not sure that's acceptable in a bugfix release. Raymond
> can shed a light.

You're right.  It is not acceptable to give a different sequence of random 
numbers within a bugfix release.  

[Victor]
> Ok, it looks like most people are in favor of min(). 
> Can anyone propose a patch?

I will work up a patch, but I can't say that I feel good about making everyone 
pay a price for a problem that almost no one ever has.

--

___
Python tracker 

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

[issue23220] Documents input/output effects of how IDLE runs user code

[Terry J. Reedy]

Terry J. Reedy added the comment:

Serhiy, thanks for the paraphrase of what I tried to say.  This issue has 
already been changed to a doc issue to explain the input/output effects of 
Idle's way of running user code.  I should have retitled before.  Control codes 
are just one of the effects that have come up on the tracker, python-list, or 
stackoverflow. Misunderstanding had lead to user puzzlement and even undeserved 
insults directed as Python.

I propose to something like the following to the introductory section of the 
Idle doc, https://docs.python.org/3/library/idle.html#index-0, after the 
feature list.

---
When Idle runs user code from either the shell or an editor window, the result 
is nearly always be the same as running the same code directly with python in 
either interactive or batch mode.  However, environmental differences can have 
visible effects. For instance, Idle import statements add numerous entries to 
sys.modules and a few module attributes to modules such as tkinter.  The line 
`1import tkinter; tkinter.colorchooser`` normally raises AttributeError but 
works when run with Idle because Idle has already imported 
tkinter.colorchooser. To detect whether code is running under Idle, run 
``import idlelib; idlelib.run`` within a try-except statement.

More important are the input/output differences.  Python normally runs in a 
text console process with direct access to keyboard and screen. For code run 
with Idle, the keyboard and screen are controlled by the tk graphics subsystem 
and sys.stdin, sys.stdout, and sys.stderr are bound to objects that connect to 
the gui. (Note that ``print`` calls ``sys.stdout.write``.)  Here are some of 
the effects of keyboard and screen access being indirect.
  * Operating system (OS) specific functions that directly access the keyboard 
may not work.
  * The Idle shell works with complete statements rather than individual lines 
of code.  One can edit and retrieve complete multiline statements instead of 
single lines.
  * User code gets colorized. Normal output and error output to the shell get 
their own colors.
  * Tk supports the Basic Multilingual Plane (BMP) subset of Unicode 
characters.  This is worse than consoles that support supplementary planes 
(with appropriate fonts in use), but better than the Windows console, which 
only supports restricted subsets of the BMP, depending on the code page in use.
  * Tk handling of ascii control chars depends on the OS and is usually 
different from the text console.
---

--
title: IDLE does not display \b backspace correctly. -> Documents input/output 
effects of how IDLE runs user code

___
Python tracker 

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

[issue24612] not operator expression raising a syntax error

[Martin Panter]

Changes by Martin Panter :


--
nosy: +vadmium

___
Python tracker 

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

[issue24612] not operator expression raising a syntax error

[Stefan Behnel]

Stefan Behnel added the comment:

Hmm, right. I see your point and also the analogy with "yield". I could live 
with (maybe) giving it a better error message suggesting to use parentheses for 
clarity and otherwise keeping it a SyntaxError.

--

___
Python tracker 

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

[issue24612] not operator expression raising a syntax error

[Matthew Barnett]

Matthew Barnett added the comment:

"not" has a lower priority than unary "-"; this:

not a < b

is parsed as:

not (a < b)

How would you parse:

0 + not 0 + 0

?

Would it be parsed as:

0 + not (0 + 0)

?

Similar remarks could apply to "yield":

0 + yield 0

which is also a syntax error.

--
nosy: +mrabarnett

___
Python tracker 

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

[issue19713] Deprecate various things in importlib thanks to PEP 451

[Petr Viktorin]

Changes by Petr Viktorin :


--
nosy: +encukou

___
Python tracker 

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

[issue24612] not operator expression raising a syntax error

[Stefan Behnel]

Stefan Behnel added the comment:

It looks like perfectly valid syntax to me and I cannot see why it should be 
semantically rejected. I disagree that it shouldn't be changed. I think it's a 
(minor) bug that should eventually get fixed.

--
nosy: +scoder

___
Python tracker 

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

[issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think this simple patch should fix the issue.

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file39896/issue24611.patch

___
Python tracker 

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

[issue24587] Incorrect tkinter behavior of slave widgets of Button

[Eugene K.]

Eugene K. added the comment:

File attached

--
Added file: http://bugs.python.org/file39895/bug.py

___
Python tracker 

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

[issue24612] not operator expression raising a syntax error

[Steven D'Aprano]

Steven D'Aprano added the comment:

On Sat, Jul 11, 2015 at 03:23:53PM +, candide wrote:
> 
> New submission from candide:
> 
> Expressions such as
> 
> a + not b
> a * not b
> + not b
> - not b
> 
> raise a SyntaxError, for instance :
> 
> 
> >>> 0 + not 0
>   File "", line 1
> 0 + not 0
>   ^
> SyntaxError: invalid syntax

That has been invalid syntax since Python 1.5, if not older. I don't 
think that it needs to be changed.

[steve@ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012, 09:09:18)  [GCC 4.1.2 20080704 (Red Hat 
4.1.2-52)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> 0 + not 0
  File "", line 1
0 + not 0
  ^
SyntaxError: invalid syntax

--
nosy: +steven.daprano

___
Python tracker 

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

[issue24612] not operator expression raising a syntax error

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

"not not 0" is compiled successful, while "+ not 0", "- not 0", and "~ not 0" 
are rejected.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue24612] not operator expression raising a syntax error

[candide]

New submission from candide:

Expressions such as

a + not b
a * not b
+ not b
- not b

raise a SyntaxError, for instance :


>>> 0 + not 0
  File "", line 1
0 + not 0
  ^
SyntaxError: invalid syntax
>>> - not 0
  File "", line 1
- not 0
^
SyntaxError: invalid syntax
>>>

if the not expression is wrapped in parenthesis, expected evaluation occurs:


>>> - not 0
  File "", line 1
- not 0
^
SyntaxError: invalid syntax
>>> 0 + (not 0)
1
>>> - (not 0)
-1
>>>



The problem has been first submitted in comp.lang.python :

https://groups.google.com/forum/?hl=fr#!topic/comp.lang.python/iZiBs3tcuak


suggesting  a bug report.

--
components: Interpreter Core
messages: 246606
nosy: candide, serhiy.storchaka
priority: normal
severity: normal
status: open
title: not operator expression raising a syntax error
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4

[R. David Murray]

R. David Murray added the comment:

unixware is not a platform we support (we don't have a buildbot for it).  If 
you can figure out how to fix this and it isn't disruptive to the codebase, you 
can submit a patch.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> needs patch

___
Python tracker 

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

[issue24611] Compiling Python 2.7.10 Error on Unixware 7.1.4

[Ron Barak]

New submission from Ron Barak:

I wanted to add Python 2.7 to Unix.
I downloaded the sources to the VirtualBox on which the Unix is installed and 
run

./configure --prefix=/usr   \
--enable-shared \
--with-system-expat \

without problems.

However, when I try to run make, it fails on:

cc –Kpthread –Wl,-Bexport –o python Modules/python.o libpython2.7.a -lsocket 
–lnsl –lpthread –ldl –lm 

Undefined   first referenced
symbol  in file
_PyInt_FromDev  libpython2.7.a(posixmodule.o) 
UX:ld: ERROR: Symbol referencing errors. No output written to python
*** Error code 1 (bu21)
UX:make: ERROR: fatal error.


Environment:

OS  Unixware 7.1.4
Python   2.7.10
CC  Optimizing C Compilation System (CCS) 4.2 05/11/04 (ux714.bl3af)

--
components: Build
messages: 246604
nosy: ronbarak
priority: normal
severity: normal
status: open
title: Compiling Python 2.7.10 Error on Unixware 7.1.4
type: compile error
versions: Python 2.7

___
Python tracker 

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

[issue23601] use small object allocator for dict key storage

[Julian Taylor]

Julian Taylor added the comment:

ok I ran it again, but note the machine was under use the full time so the 
results are likely have no meaning.

python perf.py -r -b default /tmp/normal/bin/python3 /tmp/opt/bin/python3

Min: 0.399279 -> 0.376527: 1.06x faster
Avg: 0.410819 -> 0.383315: 1.07x faster
Significant (t=49.29)
Stddev: 0.00450 -> 0.00330: 1.3631x smaller

### etree_iterparse ###
Min: 0.639638 -> 0.630989: 1.01x faster
Avg: 0.658744 -> 0.641842: 1.03x faster
Significant (t=14.82)
Stddev: 0.00959 -> 0.00617: 1.5557x smaller

### etree_parse ###
Min: 0.433050 -> 0.377830: 1.15x faster
Avg: 0.444014 -> 0.389695: 1.14x faster
Significant (t=43.28)
Stddev: 0.01010 -> 0.00745: 1.3570x smaller

### tornado_http ###
Min: 0.335834 -> 0.326492: 1.03x faster
Avg: 0.346100 -> 0.334186: 1.04x faster
Significant (t=13.66)
Stddev: 0.01024 -> 0.00689: 1.4864x smaller

The following not significant results are hidden, use -v to show them:
2to3, django_v2, etree_process, fastpickle, fastunpickle, json_dump_v2, 
json_load, nbody, regex_v8.

/tmp$ /tmp/normal/bin/python3 -c 'import timeit; print(timeit.repeat("dict(a=5, 
b=2)"))'
[0.5112445619997743, 0.514110946735, 0.5185121280010208]
/tmp$ /tmp/opt/bin/python3 -c 'import timeit; print(timeit.repeat("dict(a=5, 
b=2)"))'
[0.4426167189994885, 0.4465744609988178, 0.4467797579982289]

--

___
Python tracker 

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

[issue23220] IDLE does not display \b backspace correctly.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Control characters are named control characters because they are control the 
output device. Different devices have different capabilities and reacts 
different on the same codes. Windows console, different sorts of Linux 
terminals and Tk text widget are different devices. Some prints funny 
characters, others not, some beeps, others not, some interprets particular 
flavor of ESC sequences, others not, some allows color and positioning, others 
not. Python can't unify the behavior of these devices without lost most of 
functionality as it can't unify the behavior of black-white matrix printer, 
graphical plotter and 24-bit color LCD monitor.

I would close this issue as not related to Python.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue24610] Incorrect example Unicode string in docs footnote

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM.

The 2.x docs were fixed in c9bf6e70308e, but this change was lost during 
merging to 3.x in 3d866579117d.

--
components: +Unicode
nosy: +ezio.melotti, haypo, serhiy.storchaka
stage:  -> commit review
versions: +Python 3.4, Python 3.5

___
Python tracker 

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

[issue24610] Incorrect example Unicode string in docs footnote

[Chris Angelico]

Chris Angelico added the comment:

Interestingly, the 2.7 docs have this correct already.

https://docs.python.org/2.7/reference/expressions.html#id23

--

___
Python tracker 

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

[issue24610] Incorrect example Unicode string in docs footnote

[Chris Angelico]

New submission from Chris Angelico:

https://docs.python.org/3/reference/expressions.html#id18

The string "\u0327\u0043" does not normalize to the same string as "\u00C7", as 
combining characters are supposed to _follow_ the base character. (Some 
consoles may happen to display them the same way, but prepend another letter to 
the string and it's clear that the combining cedilla is attached to that and 
not to the C.)

Switching the two escape sequences makes the example work. Patch attached.

--
assignee: docs@python
components: Documentation
files: cedilla_docs.patch
keywords: patch
messages: 246599
nosy: Rosuav, docs@python
priority: normal
severity: normal
status: open
title: Incorrect example Unicode string in docs footnote
versions: Python 3.6
Added file: http://bugs.python.org/file39894/cedilla_docs.patch

___
Python tracker 

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

[issue24595] InteractiveInterpreter always prints to stdout

[Terry J. Reedy]

Terry J. Reedy added the comment:

To me, this cries out for a public context manager ( believe there is a public 
one in test.support, or something), so one can write

with stdout(ob):
  print(stuff)

I am not sure, though, where the C.M.s should live.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue24587] Incorrect tkinter behavior of slave widgets of Button

[Terry J. Reedy]

Terry J. Reedy added the comment:

Please attach the file to this issue, using the [Browse] button.

--
nosy: +serhiy.storchaka, terry.reedy

___
Python tracker 

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

[issue23220] IDLE does not display \b backspace correctly.

[Terry J. Reedy]

Terry J. Reedy added the comment:

I closed #24572 as a duplicate of this. It is the same issue except for 
printing \r instead of \b.  These issues are not about responses to keyboard 
actions when entering text into an Idle editor window.  During entry, just 
about any cntl/alt/function/shift/key combination can be intercepted to and 
translated to arbitrary action. They are also not about REPL echo.  For 3.4+ 
Win7, both console Python and Shell echo '\b\t\x08\x09' as '\x08\t\x08\t'. 
Carol's report suggest that the same is true on Mac also.

Both issues *are* about print(s, file=outfile), where s is the result of 
processing all args except 'file' and outfile defaults to sys.stdout. The print 
call is the same as outfile.write(s), so outfile (and sys.stdout) could be any 
object with a write method.

>>> print('hello\b\b\b\b\bHELLO')
helloHELLO
>>> import sys; sys.stdout.write('hello\b\b\b\b\bHELLO'+'\n')
helloHELLO
(I actually see the same circles as Al, but copy-paste does not seem to work as 
well for me.)

So both issues are about the effect of writing 'control chars', in particular 
\b and \r, to a file. Well, that depends on the file.  Some possibilities are 
copy as is (StringIO), encode and copy (disk file, socket), ignore, display as 
one glyph, display as multiple chars, non-destructively backspace (like 
backspace on typewriters and printing terminals and left-arrow elsewhere), or 
destructively backspace (like backspace on as most (all?) screen keyboards).  
After non-destructive movement of the 'cursor' position, the possibilities for 
following graphical chars are overwrite (like typewriters), replace, and insert 
(the modes sometimes selected by the Insert key). Non-destructive backspace 
followed by overwrite (meaning 'HELLO' printed on top of 'hello') is the 
original meaning of 'backspace'.

Having said all this, I am sympathetic to the idea that there should be an 
option to have 'print(ascii_string)' in user code give the same result in the 
console and Idle.  I think this would best be accomplished by a 
least-common-denominator SimpleTerm subclass of tkinter.Text put somewhere in 
the tkinter package. (This would be a new issue that should start on 
python-ideas list.)  However, I would consider something Idle specific.

Does the following work the same on *nix and Mac as Windows?

>>> print('hello\rHELLO')
HELLO  # helloHELLO with Win7 Idle

Are there any control-chars (other than \n) that work might work in the 
consoles on all three systems and that should be included?

Carol, another difference between the Windows console and Idle is that tk and 
hence Idle support the entire BMP subset of unicode.  This should also be 
mentioned in the doc.

--
stage:  -> needs patch
type:  -> enhancement

___
Python tracker 

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