[issue44950] Math
New submission from Hamish : Error shown in image -- components: Interpreter Core files: unknowasdasdasdn.png messages: 399874 nosy: hamish555 priority: normal severity: normal status: open title: Math type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file50226/unknowasdasdasdn.png ___ Python tracker <https://bugs.python.org/issue44950> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8081] a.append appends reference , causing unexpected behaviour
New submission from hamish farrant : Causes modification of an list object to change the values of the object already inside the list. Example code : import random a =[] b = [1 , 2 , 3 , 4] for i in range (15): random.shuffle(b) a.append(b) for j in a: print j Expected Behaviour : the list referenced by b , should be appended to a , creating a list of random permutations of b. -- components: Interpreter Core messages: 100548 nosy: hamish.farrant severity: normal status: open title: a.append appends reference , causing unexpected behaviour type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8081> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3
New submission from Hamish Moffatt : As of 2.5.3, calling accept() on an AF_UNIX socket fails on arm. The following exception occurs: SystemError: Negative size passed to PyString_FromStringAndSize I have attached a test program that creates a socket and connects to it. It works on x86-64 but fails on armeb (gcc 4.1.2). This failure has been noted a few times by the arm buildbot too: http://archives.free.net.ph/message/20081012.121034.89069ea2.en.html It's already fixed in 2.6.x in rev 60214. I applied the same change to 2.5.4 and the problem was resolved. -- components: Extension Modules files: accept_test.py messages: 79825 nosy: hmoffatt severity: normal status: open title: accept() on AF_UNIX sockets broken on arm as of 2.5.3 versions: Python 2.5 Added file: http://bugs.python.org/file12733/accept_test.py ___ Python tracker <http://bugs.python.org/issue4942> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3
Hamish Moffatt added the comment: Thanks for your feedback, but I'm a bit confused by the note on the web site: "This is the last bugfix release of Python 2.5. Python 2.5 is now in bugfix-only mode; no new features are being added." This implies further bug fixes are possible (and further fixes were just made to 2.4 despite the above comment about 2.4.5). Also it's a regression from 2.5.2, which must be of some concern? ___ Python tracker <http://bugs.python.org/issue4942> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4942] accept() on AF_UNIX sockets broken on arm as of 2.5.3
Hamish Moffatt added the comment: Understood. Would it be appropriate to list this issue on the known bugs page? http://www.python.org/download/releases/2.5.4/bugs/ I can't reproduce it on x86, but it's probably not ARM specific. It might even be a compiler bug. I tried the same version on x86 and x86-64 and didn't have a problem. Thanks. ___ Python tracker <http://bugs.python.org/issue4942> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13474] Mention of "-m" Flag Missing From Doc on Execution Model
Change by Hamish MacDonald : -- keywords: +patch pull_requests: +6570 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue13474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13474] Mention of "-m" Flag Missing From Doc on Execution Model
Change by Hamish MacDonald : -- pull_requests: +6571 ___ Python tracker <https://bugs.python.org/issue13474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15565] pdb displays runt Exception strings
Hamish Downer added the comment: The bug affects me on python 2.7, as described by the original reporter. I am using Ubuntu 12.04 which comes with python 2.7.3 - was this fixed for 2.7 quite recently? However the python 3.2 that is packaged for Ubuntu 12.04 does not suffer from this bug. -- nosy: +Hamish.Downer ___ Python tracker <http://bugs.python.org/issue15565> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26020] set_display evaluation order doesn't match documented behaviour
New submission from Hamish Campbell:
It looks like the behaviour of set displays do not match behaviour in some
cases. The documentation states:
"A set display yields a new mutable set object, the contents being specified by
either a sequence of expressions or a comprehension. When a comma-separated
list of expressions is supplied, its elements are evaluated from left to right
and added to the set object. When a comprehension is supplied, the set is
constructed from the elements resulting from the comprehension."
Note the following:
>>> foo = { True, 1 }
>>> print(foo)
{1}
However, if we add elements 'left to right':
>>> foo = set()
>>> foo.add(True)
>>> foo.add(1)
>>> print(foo)
{True}
Note that similar documentation for dict displays produces the expected result.
"If a comma-separated sequence of key/datum pairs is given, they are evaluated
from left to right to define the entries of the dictionary: each key object is
used as a key into the dictionary to store the corresponding datum. This means
that you can specify the same key multiple times in the key/datum list, and the
final dictionary’s value for that key will be the last one given."
>>> foo = {}
>>> foo[True] = 'bar'
>>> foo[1] = 'baz'
>>> print(foo)
{True: 'baz'}
Which matches the dict display construction:
>>> foo = { True: 'bar', 1: 'baz'}
>>> print(foo)
{True: 'baz'}
Note that I've tagged this as a documentation bug, but it seems like the
documentation might be the preferred implementation.
--
assignee: docs@python
components: Documentation
messages: 257579
nosy: Hamish Campbell, docs@python
priority: normal
severity: normal
status: open
title: set_display evaluation order doesn't match documented behaviour
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue26020>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26020] set_display evaluation order doesn't match documented behaviour
Hamish Campbell added the comment: Apologies, that first line should read "It looks like the documentation of set displays do not match behaviour in some cases". -- ___ Python tracker <http://bugs.python.org/issue26020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26020] set_display evaluation order doesn't match documented behaviour
Hamish Campbell added the comment:
Note also the differences here:
>>> print(set([True, 1]))
{True}
>>> print({True, 1})
{1}
>>> print({x for x in [True, 1]})
{True}
--
___
Python tracker
<http://bugs.python.org/issue26020>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26020] set_display evaluation order doesn't match documented behaviour
Hamish Campbell added the comment: > Do you have a use case where `x == y`/`hash(x) == hash(y)` does not mean that > `x` and `y` should be interchangeable? True and 1 are 100% interchangeable, > minus their str() output, and my example is very unlikely to ever appear in > actual code. No I don't have a use case :) > The culprit is the BUILD_SET opcode in Python/ceval.c which unnecessarily > loops backwards (it looks like it was copied from the BUILD_TUPLE opcode). Incidentally, pypy seems to behave the same as reported here. -- ___ Python tracker <http://bugs.python.org/issue26020> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
