[Python-ideas] "While" suggestion

Josiah Carlson josiah.carlson at gmail.com
Fri Jul 11 18:59:45 CEST 2008


Not everything should be a 1-line function or operation.

And, in fact, your examples show that you really don't understand
*current* Python semantics, so trying to introduce new syntax is a
non-starter (never mind that it was killed earlier).

[int(line) for line in file if evenP(int(line)) until int(line)==0
with open(filename) as file]

Could be replaced by...

[int(line) for line in open(filename) if evenP(int(line)) until int(line)==0]

If you kept the until syntax.  But even then, since Python files
iterate lines with trailing newlines, it would raise an exception in
the first pass.

[int(line.rstrip('\r\n')) for line in open(filename) if
evenP(int(line.rstrip('\r\n')) until ...]

But now there's all this .rstrip() crap in there, an explicit evenP
call, etc.  At this point, it's probably *clearer* (and faster) to
pull everything out and be explicit about your cases.

out = []
for line in open(filename):
    val = int(line.rstrip('\r\n'))
    if val == 0:
        break
    if not val & 1:
        out.append(val)

 - Josiah

On Fri, Jul 11, 2008 at 2:10 AM, Andrew Akira Toulouse
<andrew at atoulou.se> wrote:
> Clearly, the list comprehension is intended to map and filter in a
> functional matter. My [-1] operation was a trivial reduce operation.
> Certainly another example could be concocted to demonstrate it used in such
> a matter that would not offend your sensibilities, but as far as I'm
> concerned it is simple, beautiful, readable, unambiguous, etc.
>
> Your counterpoint takes exception to the example rather than the suggestion.
> Say someone is going through a flat file with a large list of numbers, and
> they want to filter out all odd numbers, and stop once they encounter a 0
> value.
>
> [int(line) for line in file if evenP(int(line)) until int(line)==0]
>
> or
>
> [int(line) for line in file if evenP(int(line)) until int(line)==0 with
> open(filename) as file]
>
> Bam, one line to open the file, iterate through them, filter out unneeded
> entries, define the base case, and return value.
>
> Do you believe that this also abuses list comprehensions? If so, please
> explain your reasoning.
>
> There's nothing keeping a programmer from writing anything this syntax could
> do as a normal for loop, but neither is there anything stopping said
> programmer from using a for loop with ifs and breaks in place of a list
> comprehension.
>
> One can also make the reasoning that for infinitely iterable sequences, in
> order for the shorter syntax to remain useful it should be able to define a
> stopping point at which it ceases to map over said sequence. This is my
> justification for suggesting 'until'; say someone created a function that
> yielded the fibonacci numbers: it would be easy to iterate over this with a
> full for statement and forget or misplace the base case which in turn would
> lead to an infinite loop. 'until' offers a relatively simple solution that
> at worst adds a few words to a program; on average, could reduce a little
> bit of processing time; and at best, prevents an infinite for loop -- all in
> a simple, readable, and compact syntax that, as far as I know (I admit I am
> very new to python-ideas), would add little complexity to the interpreter.
>
> --Andy
>
> On Wed, Jul 9, 2008 at 4:59 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>
> wrote:
>>
>> Andrew Toulouse wrote:
>>
>>> tokenchecks = [token for regex,token in match_tok until regex.match(s)]
>>> # do whatever from this point forward.
>>>    return tokenchecks[-1]
>>
>> This is an abuse of list comprehensions, since
>> you're throwing away the produced list and only
>> keeping the last element.
>>
>> --
>> Greg
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>



More information about the Python-ideas mailing list