[Python-ideas] PEP for issue2292, "Missing *-unpacking generalizations"

[Guido van Rossum]

On Mon, Jul 15, 2013 at 12:53 PM, Oscar Benjamin
<oscar.j.benjamin at gmail.com> wrote:
> On 15 July 2013 18:39, Guido van Rossum <guido at python.org> wrote:
>> On Mon, Jul 15, 2013 at 3:40 AM, Oscar Benjamin
>> <oscar.j.benjamin at gmail.com> wrote:
>>> I would like it if the
>>> unpacking syntax could somehow be used for iterators. For example:
>>>
>>>     first_line = next(inputfile)
>>>     # inspect first_line
>>>     for line in chain([first_line], inputfile):
>>>         # process line
>>>
>>> could be rewritten as
>>>
>>>     first_line = next(inputfile):
>>>     for line in first_line, *inputfile:
>>>         pass
>>>
>>> without reading the whole file into memory. Using the tuple syntax is
>>> probably confusing but it would be great if there were some way to
>>> spell this and get an iterator instead of a concrete collection.
>>
>> I think this is going down a slippery slope that could jeopardize the
>> whole PEP, which is nice and non-controversial so far. The problem is
>> that "tuples" (more precisely, things separated by commas) are already
>> overloaded to the point where both the parser and most human readers
>> are strained to the max to tell the different cases apart. For
>> example, this definitely creates a tuple:
>>
>> a = 1, 2, 3
>>
>> Now consider this:
>>
>> b = 2, 3
>> a = 1, *b
>>
>> Why would that not create the same tuple?
>
> Yeah, this is what I mean that tuple syntax is confusing. I think,
> though, that it would be good if some way of creating iterators
> evolved from this.
>
> Consider that while list, set and dict comprehensions can create
> lists, sets and dicts. Generator expressions can create tuples,
> OrderedDicts, blists, deques and many more. They can also be used with
> folds like min, max, sum, any, all and many more. Creating an iterator
> provides a much more general tool then creating a particular concrete
> type.

But the point remains that I see no way to creatively reuse the *x
notation to serve both purposes. So I recommend that you think of a
different way to obtain your goal, proposing a different PEP, which
can be discussed independently from PEP 448. (And I don't mean this in
the sense of "go away, I don't want to listen to you". I do want to
hear your ideas. I just think that it is better for PEP 448 to be more
limited in scope.)

Regarding the importance of more general/abstract tools, I have just
started reading Seymour Papert's Mindstorms, and one of his early
insights about learning programming seems to be that the learner's
path goes from more concrete things to more abstract things. In this
context it feels appropriate that Python's syntax has notations to
create concrete objects such as lists, tuples, dicts but that the more
general concepts like iterators must be created without much syntactic
help (generator expressions notwithstanding).

-- 
--Guido van Rossum (python.org/~guido)