RetroSearch Browse

Thu Mar 22 00:55:43 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-March/117931.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-March/117931.html below:

[Python-Dev] New PEP