[Python-Dev] New PEP
Etienne Robillard
animelovin at gmail.com
Thu Mar 22 00:55:43 CET 2012
On 03/21/2012 07:39 PM, Huan Do wrote:
> *Hi,
>> I am a graduating Berkeley student that loves python and would like to
> propose an enhancement to python. My proposal introduces a concept of
> slicing generator. For instance, if one does x[:] it returns a list
> which is a copy of x. Sometimes programmers would want to iterate over a
> slice of x, but they do not like the overhead of constructing another
> list. Instead we can create a similar operator that returns a generator.
> My proposed syntax is x(:). The programmers are of course able to set
> lower, upper, and step size like the following.
>> x(1::-1)
>>> This would make code much cleaner in a lot of instances, one example
> lets say we have a very large list x and we want to sum all the numbers
> but the last 20, and we only want to loop through the even indices.
>> We would have to do something like this.
>> sum(x[:-20:2])
>>> or we can do a workaround to save space for time and do something like this.
>> sum( value for i, value in enumerate(x) if i < -20 and not i % 2 )
>>> But with my proposal we are able do the following.
>> sum(x(:-20:2))
>>> Which affords space without sacrificing expressiveness.
>> For another example lets say we have a problem that we want to check a
> condition is true for every pairwise element in a list x.
>> def allfriends(x):
>> for i in range(len(x)):
>> for j in range(i+1, len(x)):
>> if not friends(x[i], x[j]):
>> return False
>> return True
>>> A more pythonic way is to actually loop through the values instead of
> the indices like this.
>> def allfriends(x):
>> for i, a in enumerate(x):
>> for j, b in enumerate(x[i+1:]):
>> if not friends(a, b):
>> return False
>> return True
>>> This however bring a lot of overhead because we have to construct a new
> list for every slice call. With my proposal we are able to do this.
>> def allfriends(x):
>> for i, a in enumerate(x):
>> for j, b in enumerate(x(i+1:)):
>> if not friends(a, b):
>> return False
>> return True
>>> This proposal however goes against one heuristic in the zen of python,
> namely “Special cases aren’t special enough to break the rules.” The way
> that the proposal breaks this rule is because the syntax x(:), uses a
> function call syntax but would be a special case here. I chose using
> parenthesis because I wanted this operation to be analogous to the
> generator syntax in list comprehensions.
>> List Generators
> Comprehension [ x for x in L ] ( x for x in L )
> Slicing L[a:b:c] L(a:b:c)
>>>> Tell me what you guys think.
>> Thanks!*
>>>> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/animelovin%40gmail.com
Hi,
I'm not sure i get it.. Assuming your PEP is accepted, what should
happens then to the lambda op and standard function calls ? Or Is this
merely another case of metaprogramming, which obviously should not be
confused with languages such as lisp?
Thank you,
Etienne
More information about the Python-Dev
mailing list