[Python-Dev] Re: syntactic shortcut list (original) (raw)

[Python-Dev] Re: syntactic shortcut - unpack to variably sized list

Nick Coghlan ncoghlan at iinet.net.au
Sat Nov 20 04:41:19 CET 2004

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.4Revision: 1.4 Revision:1.4 Last-Modified: Date:2003/09/2204:51:50Date: 2003/09/22 04:51:50 Date:2003/09/2204: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:

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

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:

More information about the Python-Dev mailing list