Terry Reedy wrote:
> This issue has come up enough that a PEP would be useful (if there isn't
> one already).
Nope, I had a look. I've got a draft one attached, though - it combines
rejecting the syntax change with adding the other changes Carlos and I have
suggested. If people think it's worth pursuing, I'll fire it off to the PEP editors.
Cheers,
Nick.
--
Nick Coghlan | Brisbane, Australia
Email: ncoghlan at email.com | Mobile: +61 409 573 268
-------------- next part --------------
PEP: XXX
Title: Unpacking sequence elements using tuple assignment
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/09/22 04:51:50 $
Author: Nick Coghlan <ncoghlan at email.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 20-Nov-2004
Python-Version: 2.5
Post-History: 20-Nov-2004
Abstract
========
This PEP addresses the repeated proposal that "a, b, *c = some_sequence"
be permissible Python syntax.
The PEP does NOT propose that this syntax be allowed. In fact, acceptance
of this PEP will indicate agreement that the above syntax will NOT
become part of Python.
However, this PEP does suggest two additions that will hopefully reduce
the demand for the above syntax:
- modify ``list.pop`` and ``array.pop`` to also accept slice objects as
the index argument
- add an ``itertools.iunpack`` function that accepts an arbitrary iterator,
yields a specified number of elements from it, and then yields the
partially consumed iterator.
Rationale
=========
The proposal to extend the tuple unpacking assignment syntax has now been
posted to python-dev on 3 separate occasions, and rejected on all 3
occasions.[1]_
The subsequent discussion on the most recent occasion yielded the two
suggestions documented in this PEP (modifying ``list.pop`` was suggested by the
PEP author, the ``itertools.iunpack`` function was suggested by Carlos Ribeiro).
Modifying ``list.pop`` to accept slice objects as well as integers brings it
in line with the standard sequence subscripting methods (``__getitem__``,
``__setitem__``, ``__delitem__``). It also makes ``list.pop`` consistent with
its current documentation (the Python code given as equivalent to ``list.pop``
accepts slice objects, but ``list.pop`` does not).
The modification of ``array.pop`` is mainly for consistency with the new
behaviour of ``list.pop``.
The ``itertools.iunpack`` function has the advantage of working for arbitrary
iterators, not just lists or arrays. However, it always yields copies of
the elements, while the ``pop`` methods are able to avoid unnecessary copying.
Proposed Semantics
==================
``list.pop`` would be updated to conform to its documentation as being
equivalent to::
x = L[i]
del L[i]
return x
In Python 2.4, the above equivalence does not hold if ``i`` is a slice object.
``array.pop`` would be updated similarly.
``itertools.iunpack`` would be equivalent to the following::
def iunpack(itr, numitems, defaultitem=None):
for i in range(numitems):
try:
yield itr.next()
except StopIteration:
yield defaultitem
yield itr
Reference Implementation
========================
As yet, no reference implementation is available for either part of the proposal.
Open Issues
===========
- Should ``itertools.iunpack`` call ``iter()`` on its first argument?
References
==========
.. [1] python-dev archives of tuple unpacking discussions
(http://mail.python.org/pipermail/python-dev/2002-November/030349.html)
(http://mail.python.org/pipermail/python-dev/2004-August/046684.html)
(http://mail.python.org/pipermail/python-dev/2004-November/049895.html)
Copyright
=========
This document has been placed in the public domain.
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4