Re: For loop extended syntax
On Sun, 20 Mar 2005 13:16:37 -0500, George Sakkis [EMAIL PROTECTED] wrote: I'm sure there must have been a past thread about this topic but I don't know how to find it: How about extending the for X in syntax so that X can include default arguments ? This would be very useful for list/generator comprehensions, for example being able to write something like: [x*y-z for (x,y,z=0) in (1,2,3), (4,5), (6,7,8)] instead of the less elegant explicit loop version that has to check for the length of each sequence. What do you think ? George How would this examples work? for x=5,y,z in (123),(4,5),(6,7,8,9) Would the x default over ride the first value? Should, the 4 element in the third tuple be dropped without an error? A general reusable function might be something like this: def formatlistofargs(arglist, nargs=1, defvalue=0): returnvalues = [] for i in arglist: ii = list(i) while len(ii)nargs: ii.append(defvalue) ii=ii[:nargs] returnvalues.append(ii) return returnvalues for x,y,z in formatlistofargs(((1,2,3),(3,4),(5,6,7,8)),3): print x,y,z Ron -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
George Sakkis wrote: A generalization of the 'for .. in' syntax that would handle extra arguments the same way as functions would be: for (x,y,z=0,*rest) in (1,2,3), (3,4), (5,6,7,8): print x, y, z, rest I'd love to see this in python one day; it is pretty obvious what it would do for anyone familiar with function argument tuples. Let's all keep in mind that for...in... is using standard tuple unpacking rules (you're getting the next tuple from a list of tuples, and then unpacking that tuple), so what is really being proposed are extensions to tuple unpacking. (Making this work in the context of a for loop but not work in other tuple-unpacking situations would create inconsistency.) Function arguments are *not* (in general) a case of tuple unpacking, on the other hand, so the parallels between function arguments and for loop control-variable tuples are not so straightforward as is being claimed. There may be valid arguments in favor of enhancing tuple unpacking in this way (indeed, I believe I recall a thread or two on this subject), but it's important to consider the general consequences, not just the single aspect of for-loop usage. Jeff Shannon -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
George Sakkis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] A generalization of the 'for .. in' syntax that would handle extra arguments the same way as functions would be: for (x,y,z=0,*rest) in (1,2,3), (3,4), (5,6,7,8): print x, y, z, rest I'd love to see this in python one day; it is pretty obvious what it would do for anyone familiar with function argument tuples. Jeff covered the obvious objection that this is a change from assignment sematics to function call semantics. Slightly less obvious is that this will slow down everyone's for loops for the benefit of the very few who would want to do such a thing. (Is the above based on a real use case?) Python function calls are 'slow' (relative to assignment, certainly) in part *because* of the great flexibility in call signatures. In any case, one can now write (with hardcoded format and types, untested): def argify(*tups): for tup in tups: ltup = len(tup) ifltup = 4: yield tup[0:3] + (tup[3:],) elif ltup == 3: yield tup + ((),) elif ltup == 2: yield tup + (0, ()) else:raise TypeError(Tuple %s needs at least 2 items % (tup,) for x,y,z,rest in argify(): print x,y,x,rest Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
Jeff Shannon wrote: Function arguments are *not* (in general) a case of tuple unpacking, on the other hand, so the parallels between function arguments and for loop control-variable tuples are not so straightforward as is being claimed. It seems to me the parallel is close enough that no confusion would result. Can you think of any situation in which surprising behaviour would occur through someone thinking the parallel was closer than it is? -- Greg Ewing, Computer Science Dept, University of Canterbury, Christchurch, New Zealand http://www.cosc.canterbury.ac.nz/~greg -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
Terry Reedy wrote: Jeff covered the obvious objection that this is a change from assignment sematics to function call semantics. Slightly less obvious is that this will slow down everyone's for loops for the benefit of the very few who would want to do such a thing. If the action of (x,y,z=0) on a tuple is regarded as a function call why not letting resolve it by the compiler in an appropriate manner? The tuple assignment is just a special case of this and can be resolved in a different way. There would be no slowdown at all. Regards Kay -- http://mail.python.org/mailman/listinfo/python-list
For loop extended syntax
I'm sure there must have been a past thread about this topic but I don't know how to find it: How about extending the for X in syntax so that X can include default arguments ? This would be very useful for list/generator comprehensions, for example being able to write something like: [x*y-z for (x,y,z=0) in (1,2,3), (4,5), (6,7,8)] instead of the less elegant explicit loop version that has to check for the length of each sequence. What do you think ? George -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
George Sakkis wrote: This would be very useful for list/generator comprehensions, for example being able to write something like: [x*y-z for (x,y,z=0) in (1,2,3), (4,5), (6,7,8)] Looks very appealing, but what to do with [x*y-z for (x=0,y,z) in (1,2,3), (4,5), (6,7,8)] ? Should it raise an exception due to a pattern mismatch? If not how should matching rules apply here? [x*y-z for (x=0,y=0,z=0) in (1,2,3), (4,5), (6,7,8)] If in doubt write a vector class that cares about the correct padding ( or more general and with geometric meaning: select the right hyperplane ) and enable to switch between different paddings. This solution is both flexible and reusable. Regards Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
George Sakkis wrote: I'm sure there must have been a past thread about this topic but I don't know how to find it: How about extending the for X in syntax so that X can include default arguments ? This would be very useful for list/generator comprehensions, for example being able to write something like: [x*y-z for (x,y,z=0) in (1,2,3), (4,5), (6,7,8)] instead of the less elegant explicit loop version that has to check for the length of each sequence. What do you think ? How did you get the data in that format in the first place? It looks a bit strange to me. Wouldn't it be easier to fill in default values when you gather data as opposed to when you use it? -- Ciao, Matteo -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
Kay Schluehr [EMAIL PROTECTED] wrote: George Sakkis wrote: This would be very useful for list/generator comprehensions, for example being able to write something like: [x*y-z for (x,y,z=0) in (1,2,3), (4,5), (6,7,8)] Looks very appealing, but what to do with [x*y-z for (x=0,y,z) in (1,2,3), (4,5), (6,7,8)] ? Should it raise an exception due to a pattern mismatch? I didn't have in mind to generalize the syntax even more than the respective for function signatures, therefore this would be syntax error: SyntaxError: non-keyword arg after keyword arg If not how should matching rules apply here? [x*y-z for (x=0,y=0,z=0) in (1,2,3), (4,5), (6,7,8)] If in doubt write a vector class that cares about the correct padding ( or more general and with geometric meaning: select the right hyperplane ) and enable to switch between different paddings. This solution is both flexible and reusable. Regards Kay This was just an example; I think the proposed functionality will be helpful in far more cases than dealing with geometry or vectors, so I would prefer it to be supported by the language itself. Regards, George -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
Matteo Dell'Amico [EMAIL PROTECTED] wrote: George Sakkis wrote: I'm sure there must have been a past thread about this topic but I don't know how to find it: How about extending the for X in syntax so that X can include default arguments ? This would be very useful for list/generator comprehensions, for example being able to write something like: [x*y-z for (x,y,z=0) in (1,2,3), (4,5), (6,7,8)] instead of the less elegant explicit loop version that has to check for the length of each sequence. What do you think ? How did you get the data in that format in the first place? It looks a bit strange to me. Wouldn't it be easier to fill in default values when you gather data as opposed to when you use it? Not always. Say for example that you're doing some 2D geometry stuff, and later you have to extend it to 3D. In this case you may have to deal with both 2D and 3D objects, and map the former to the latter when necessary. George -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
On Sunday 20 March 2005 20:47, George Sakkis wrote: Not always. Say for example that you're doing some 2D geometry stuff, and later you have to extend it to 3D. In this case you may have to deal with both 2D and 3D objects, and map the former to the latter when necessary. But this rather sounds like you'd want an adaptor iterator, like the following: class AdaptPossible2D(object): ... def __init__(self,data): ... self.data = data ... def __iter__(self): ... for item in self.data: ... if len(item) == 2: ... yield item+(0,) ... else: ... yield item ... for x,y,z in AdaptPossible2D([(1,2),(1,2,3),(3,4)]): ... print x,y,z ... 1 2 0 1 2 3 3 4 0 Using the above code makes it absolutely clear what you want, and doesn't need any new syntax which can be ambiguous like (x=0,y,z=0), etc. The above idiom also takes only constant extra space, as it doesn't duplicate the list during iteration. -- --- Heiko. pgpiKidxAK8Og.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
Am Sonntag, 20. März 2005 22:22 schrieb George Sakkis: Once more, the 2D/3D example was just that, an example; my point was not to find a specific solution to a specific problem. And my point being: it's simple enough to give a general recipe (which my example was) without extending Python's syntax, so why extend the syntax and not just use a solution derived from that recipe that's working now (and is backwards compatible at least to 2.3), and which is also clear in itself? I'm not saying that your syntax looks strange or bad, but there are means to do what you want to do now, without cumbersome syntax or duplicating code, and as such I'm -1 on syntactic sugar (TOWTDI and all)... Don't take this the wrong way, but I think introducing syntax is the wrong solution to a non-existant problem with the language. -- --- Heiko. pgpKzqC7Aa4ue.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
Heiko Wundram [EMAIL PROTECTED] wrote:
Am Sonntag, 20. März 2005 22:22 schrieb George Sakkis:
Once more, the 2D/3D example was just that, an example; my point was not to
find a specific solution to a specific problem.
And my point being: it's simple enough to give a general recipe (which my
example was) without extending Python's syntax, so why extend the syntax and
not just use a solution derived from that recipe that's working now (and is
backwards compatible at least to 2.3), and which is also clear in itself?
I'm not saying that your syntax looks strange or bad, but there are means
to do what you want to do now, without cumbersome syntax or duplicating code,
and as such I'm -1 on syntactic sugar (TOWTDI and all)...
Don't take this the wrong way, but I think introducing syntax is the wrong
solution to a non-existant problem with the language.
The way I see it, it's closer to applying existing syntax (from function
signatures) in a new
context than introducing new syntax, but that's a detail. I guess it's a matter
of personal
preference to syntactic sugar then. Still, python is rife with syntactic sugar:
iterators, default
function arguments, *varargs, **kwdargs, [list]/(tuple)/{dict} literals,
recently @decorators, and
more. If syntactic sugar didn't matter, we would be happy with scheme's syntax.
George
--
http://mail.python.org/mailman/listinfo/python-list
Re: For loop extended syntax
George Sakkis wrote: Looks very appealing, but what to do with [x*y-z for (x=0,y,z) in (1,2,3), (4,5), (6,7,8)] ? Should it raise an exception due to a pattern mismatch? I didn't have in mind to generalize the syntax even more than the respective for function signatures, therefore this would be syntax error: SyntaxError: non-keyword arg after keyword arg O.K. Allthough it has fallen out of Guidos favor one can use a lambda to obtain the same solution: [(lambda x,y,z=0:x*y-z)(*vec) for vec in (1,2,3), (4,5), (6,7,8)] This inspires to examine Your list comprehension not as plain 'syntax suggar' but in a clear operational perspective. Since (x,y,z=0) is not a valid Python tuple we have to replace it by lambda x,y,z=0:(x,y,z) This acts on the list elements of the comprehension like the proposed (x,y,z=0) whereas the valid (x,y,z) acts like lambda x,y,z:(x,y,z) So we have generalized tuples to lambdas. If we let lambda x,y,z=0:(x,y,z) iterate over the list elements, why not the generalized lambda x,y,z=0:(lambda x,a=0:(x,a),y,z) ? Returning to Your soluion and translating back the lambda: [x*y-z for ((x,a=0),y,z=0) in (1,2,3), (4,5), (6,7,8)] should also be possible from an operational perspective. Regards Kay -- http://mail.python.org/mailman/listinfo/python-list
