Re: [Python-Dev] PyPy progress: list of CPython 3.5 crashers and bugs
Hi Raymond,
On 6 December 2016 at 05:59, Raymond Hettinger
wrote:
> Also, we use {...} instead of OrderedDict(...).
No, at least CPython 3.5.2 uses ``...`` for OrderedDict, and not
``{...}``. Following that example, deques should also use ``...``
instead of ``[...]``. But I bow to your choice and remove my point
from cpython-crashers.rst anyway.
A bientôt,
Armin.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy progress: list of CPython 3.5 crashers and bugs
Hi Nick, On 5 December 2016 at 13:22, Nick Coghlan wrote: > I think 3 omnibus issues would be a reasonable way to go, with the > discussion on those issues then splitting things out to either new > issue reports, or entries in > https://hg.python.org/cpython/file/default/Lib/test/crashers/ (if any > of the crashers can't be readily resolved). Ok, added: http://bugs.python.org/issue28883 http://bugs.python.org/issue28884 http://bugs.python.org/issue28885 A bientôt, Armin. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] List mutation in list_repr?
Hey all, I just stumbled on the following comment in the C source of the repr implementation for the list object: /* Do repr() on each element. Note that this may mutate the list, so must refetch the list size on each iteration. */ (as seen in list_repr implementation [1]) I’m honestly very surprised about this remark since I can neither understand why this would be the case (repr shouldn’t mutate the list), and I also don’t see any clue in the source as to when this would actually happen. Since inside the loop, the list object `v` is never accessed other than passing `v->ob_item[i]` to the recursive repr call, there shouldn’t be any mutation on the list object itself. I understand that a custom repr implementation could theoretically mutate an object, but this could only affect the object itself (or its children), but not the container list. So the list object `v` here should be safe from mutations. I tried looking at the original change when this was introduced. Unfortunately, this was in 2001 [2], so I don’t really expect Tim to still know *why* the comment was added back then. Do you have any insights on why the comment is there, and whether I am missing something that could actually mutate the list, making the size refetch necessary and the comment justified? Thanks a lot! Patrick [1] https://github.com/python/cpython/blob/b8519e4d08a82da9aa438d531058100c0e3d04b4/Objects/listobject.c#L361 [2] https://github.com/python/cpython/commit/bce15a39b30b0f5866e7b48ba3c29c3aa430a766 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] List mutation in list_repr?
On Tue, Dec 6, 2016, at 05:27, Patrick Westerhoff wrote: > Hey all, > > I just stumbled on the following comment in the C source of the repr > implementation for the list object: > > /* Do repr() on each element. Note that this may mutate the list, >so must refetch the list size on each iteration. */ > > (as seen in list_repr implementation [1]) > > I’m honestly very surprised about this remark since I can neither > understand why this would be the case (repr shouldn’t mutate the > list) It *shouldn't*, but it can't be enforced. It's one of those things where if Python assumes all user code is sane (in this case, overridden __repr__ not messing with the list) it can bite in a way that could cause the interpreter to crash. >>> class EvilClass: ... def __repr__(x): ... l.pop() ... return 'x' ... >>> l = [EvilClass()]*10 >>> l [x, x, x, x, x] >, and I also don’t see any clue in the source as to when this > would actually happen. Since inside the loop, the list object `v` is > never accessed other than passing `v->ob_item[i]` to the recursive > repr call, there shouldn’t be any mutation on the list object itself. The item may have or be able to a reference to the list object otherwise, as I demonstrated. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] List mutation in list_repr?
> and I also don’t see any clue in the source as to when [list mutation] > would actually happen. Since inside the loop, the list object `v` is > never accessed other than passing `v->ob_item[i]` to the recursive > repr call, there shouldn’t be any mutation on the list object itself. The individual object can have a reference to the list and (in extreme cases) do with it what it pleases: class Evil: def __init__(self, l): self.l = l def __repr__(self): del l[:] return "evil" l = [] l.append(Evil(l)) l.append(Evil(l)) print(l) That is not something normal Python code does, but it shouldn't be allowed to crash the interpreter, either. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASE] Python 3.6.0rc1 is now available
On behalf of the Python development community and the Python 3.6 release team, I'm excited to announce the availability of Python 3.6.0rc1. 3.6.0rc1 is the release candiate for Python 3.6, the next major release of Python. Code for 3.6.0 is now frozen. Assuming no release critical problems are found prior to the 3.6.0 final release date, currently 2016-12-16, the 3.6.0 final release will be the same code base as this 3.6.0rc1. Maintenance releases for the 3.6 series will follow at regular intervals starting in the first quarter of 2017. Among the new major new features in Python 3.6 are: * PEP 468 - Preserving the order of **kwargs in a function * PEP 487 - Simpler customization of class creation * PEP 495 - Local Time Disambiguation * PEP 498 - Literal String Formatting * PEP 506 - Adding A Secrets Module To The Standard Library * PEP 509 - Add a private version to dict * PEP 515 - Underscores in Numeric Literals * PEP 519 - Adding a file system path protocol * PEP 520 - Preserving Class Attribute Definition Order * PEP 523 - Adding a frame evaluation API to CPython * PEP 524 - Make os.urandom() blocking on Linux (during system startup) * PEP 525 - Asynchronous Generators (provisional) * PEP 526 - Syntax for Variable Annotations (provisional) * PEP 528 - Change Windows console encoding to UTF-8 * PEP 529 - Change Windows filesystem encoding to UTF-8 * PEP 530 - Asynchronous Comprehensions Please see "What’s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.0rc1 here: https://www.python.org/downloads/release/python-360rc1/ Note that 3.6.0rc1 is still a preview release and thus its use is not recommended for production environments. More information about the release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily n...@python.org -- [] ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
