Re: def a((b,c,d),e):

AdSR wrote: if you haven't done so yet. It appears that you can specify a function explicitly to take n-tuples as arguments. Has anyone actually used it in real code? Yes. In PyGUI I have some point and rectangle manipulation utilities that do things like def add_pt((x1, y1), (x2, y2)): retur

Re: def a((b,c,d),e):

On 19 Apr 2005 01:10:11 -0700, "George Sakkis" <[EMAIL PROTECTED]> wrote: >Fran=E7ois Pinard wrote: > >> The most useful place for implicit tuple unpacking, in my experience, >> is likely at the left of the `in' keyword in `for' statements (and >> it is even nicer when one avoids extraneous paren

Re: def a((b,c,d),e):

"François Pinard" wrote: > > > keywords may be abbreviated, and much more hairy, > > > Hmm.. -1 on this. It may save a few keystrokes, but it's not good for > > readability and maintenability. > > That was my first impression too. Yet, interactively, I found that > feature very convenient. Alread

Re: def a((b,c,d),e):

[George Sakkis] > Allowing non-default arguments after *varargs doesn't make sense, In R, one may use the ... format argument anywhere in the argument list, but may later test if a non-default argument was provided or not. I tend to write R a bit like I would write Python, but hopefully, I'll ev

Re: def a((b,c,d),e):

"François Pinard" wrote: > > I started recently to study the R system and language, and saw many good > ideas in there about argument passing. Translated in Python terms, it > would mean that `*varargs' and `**keywords' are not necessary last, > that named keywords may be intermixed with positiona

Re: def a((b,c,d),e):

[George Sakkis] > François Pinard wrote: > > The most useful place for implicit tuple unpacking, in my > > experience, is likely at the left of the `in' keyword in `for' > > statements (and it is even nicer when one avoids extraneous > > parentheses). > ... and would be nicest (IMO) if default ar

Re: def a((b,c,d),e):

François Pinard wrote: > The most useful place for implicit tuple unpacking, in my experience, > is likely at the left of the `in' keyword in `for' statements (and > it is even nicer when one avoids extraneous parentheses). ... and would be nicest (IMO) if default arguments and *varargs were all

Re: def a((b,c,d),e):

> Thanks for pointing this out. However I see no atrocity potential here > -- what did you have in mind? Bad choice of words. I meant obfuscated, something like def z(((a, b), (c, d)), e, f): pass but much worse. But it looks like there is nothing unusual about it after all. Oh, well... AdS

Re: def a((b,c,d),e):

AdSR wrote: >> Yes, but usually not so much in function arguments but more in >> list-comprehensions or other places where unpacking was useful. I > love the >> feature - I just don't have nested enough data to use it more :) > > I use tuple unpacking in its typical uses, it's one of the first >

Re: def a((b,c,d),e):

On 18 Apr 2005 13:05:57 -0700, "AdSR" <[EMAIL PROTECTED]> wrote: >Fellow Pythonistas, > >Please check out > >http://spyced.blogspot.com/2005/04/how-well-do-you-know-python-part-3.html > >if you haven't done so yet. It appears that you can specify a function >explicitly to take n-tuples as argument

Re: def a((b,c,d),e):

[Diez B. Roggisch] > AdSR wrote: > > It appears that you can specify a function explicitly to take > > n-tuples as arguments. [...] Has anyone actually used it in real > > code? I do not use it often in practice, but sometimes, yes. If the feature was not there, it would be easy to do an explici

Re: def a((b,c,d),e):

> Yes, but usually not so much in function arguments but more in > list-comprehensions or other places where unpacking was useful. I love the > feature - I just don't have nested enough data to use it more :) I use tuple unpacking in its typical uses, it's one of the first language features I lear

Re: def a((b,c,d),e):

AdSR wrote: > Fellow Pythonistas, > > Please check out > > http://spyced.blogspot.com/2005/04/how-well-do-you-know-python-part-3.html > > if you haven't done so yet. It appears that you can specify a function > explicitly to take n-tuples as arguments. It actually works, checked > this myself.

Re: def a((b,c,d),e):

> if you think this is an "atrocity", maybe programming isn't for you. My resume might suggest otherwise but I guess that's not the main topic here. Maybe I got carried away -- this one took me completely by surprise. Anyway, this gets interesting: def z(((a, b), (c, d)), (e, f)): pass alth

Re: def a((b,c,d),e):

Michael Spencer wrote: See also the source of inspect.getargs for just how much this complicates the argument-passing logic! it doesn't complicate the argument-passing in any way at all -- it complicates the reverse engineering code a bit, though, since it has to convert the bytecode for def f

Re: def a((b,c,d),e):

"AdSR" <[EMAIL PROTECTED]> wrote: Small wonder since it looks like one of those language features that make committing atrocities an order of magnitude easier. eh? def f((a, b)): ... is short for def f(tmp): a, b = tmp ... if you think this is an "atrocity", maybe program

Re: def a((b,c,d),e):

AdSR wrote: Fellow Pythonistas, Please check out http://spyced.blogspot.com/2005/04/how-well-do-you-know-python-part-3.html if you haven't done so yet. It appears that you can specify a function explicitly to take n-tuples as arguments. It actually works, checked this myself. If you read the refere

Re: def a((b,c,d),e):

You can always unpack a tuple that way, like in: .>>> import sys .>>> for (index, (key, value)) in enumerate(sys.modules.iteritems()): pass -- http://mail.python.org/mailman/listinfo/python-list