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

[François Pinard]

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

[George Sakkis]
[color=blue]
> Allowing non-default arguments after *varargs doesn't make sense,[/color]

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
eventually understand R enough that I could break that habit.
[color=blue][color=green]
> > keywords may be abbreviated, and much more hairy,[/color][/color]
[color=blue]
> Hmm.. -1 on this. It may save a few keystrokes, but it's not good for
> readability and maintenability.[/color]

That was my first impression too. Yet, interactively, I found that
feature very convenient. Already with Python, I use shortcuts
interactively that I would not write nor keep in real, saved, permanent
programs. And for very common functions and features, which are not
really fluctuating anymore, some abbreviations became well known idioms.
[color=blue][color=green]
> > the computation of actual expressions given as arguments is lazily
> > postponed until their first use within the function.[/color][/color]
[color=blue]
> Is this like an implicit lambda before each argument ?[/color]

Not exactly true, but that's surely a way of understanding it. Such
things are not new: I first saw them in Algol-60, except that once an
argument has been evaluated, it is cached and not evaluated again. It's
true that in R, much more than in Python, evaluation of an argument may
often be computationally expensive.

Moreover, in R, the initial writing of the argument is preserved on
the form of a parsed tree which can be operated upon. This allow
for strange things (at least for a Python eye), like computing the
symbolic derivative of an argument. I toyed with this facility to build
mathematical images, and then, animations. For an exemple, see:

http://pinard.progiciels-bpi.ca/plaisir/NRart/

and from there, click on `nr.image' near the end.
[color=blue]
> If so, why does it have to be restricted to function arguments ? It
> seems to me that argument passing and lazy evaluation are orthogonal
> dimensions.[/color]

In R, laziness is automatic while calling functions, but not otherwise,
and from what I saw so far, less meaningful in other contexts anyway.
However, I think laziness is available explicitely if needed (there is
library function that returns a "promise" of its argument).
[color=blue]
> Or for a more exotic use:[/color]
[color=blue]
> def prologLikeSum(a =s-b, b=s-a, s=a+b):
> return a,b,s
> prologLikeSum(1 ,2) == prologLikeSum(1 ,s=3) == prologLikeSum(b =2,s=3) ==
> (1,2,3)[/color]

This is exactly how R people use the feature most of the times (at least
so far that I naively saw, as I'm still pretty new at all this).
[color=blue]
> This seems pretty hard to change though.[/color]

Oh, I would not even dream about it for Python. The idea would have to
make its way first within the developers, and this might take years, if
ever. The best I (we) could do is keep the idea in the air, for a good
while. It would likely never survive all the debates it would generate.
But who knows! :-)
[color=blue]
> [...] and even worse, [bindings] would have to be computed for each
> call, as the prologLikeSum example shows.[/color]

Yet, already, as it stands, argument passing in Python is not innocuous.
A bit more, a bit less, nobody would notice! :-)

--
François Pinard http://pinard.progiciels-bpi.ca

[George Sakkis]

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

"François Pinard" wrote:[color=blue][color=green][color=darkred]
> > > keywords may be abbreviated, and much more hairy,[/color][/color]
>[color=green]
> > Hmm.. -1 on this. It may save a few keystrokes, but it's not good[/color][/color]
for[color=blue][color=green]
> > readability and maintenability.[/color]
>
> That was my first impression too. Yet, interactively, I found that
> feature very convenient. Already with Python, I use shortcuts
> interactively that I would not write nor keep in real, saved,[/color]
permanent[color=blue]
> programs. And for very common functions and features, which are not
> really fluctuating anymore, some abbreviations became well known[/color]
idioms.

Yes, interactive use can be very different from saved modules to be
used, read and modified in the future. However if such a feature is
part of the language, it is up to the programmer's experience and
responsibility to use it only interactively. As for interactive
shortcuts, I've been using IPython for some months now as my standard
interpreter; with features such as tab completion, logged history,
'macros' and integration with the shell, shortcuts are everywhere ! Tab
completion does not work for named function arguments yet, but it
should be possible with introspection.

George

[Bengt Richter]

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

On 19 Apr 2005 01:10:11 -0700, "George Sakkis" <gsakkis@rutger s.edu> wrote:
[color=blue]
>Fran=E7ois Pinard wrote:
>[color=green]
>> 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).[/color]
>
>.=2E. and would be nicest (IMO) if default arguments and *varargs were
>allowed too; check http://tinyurl.com/dcb2q for a relevant thread.
>[/color]
You can be a little devious about the left of the 'in' in 'for' statements:

----< tupk.py >------------------------------
class Tupk(object):
def _fset(self, arg):
# implement unpacking (a, (x, y='default'))
self.a = arg[0]
if type(arg[1]) is not tuple: # accept (a, x) in place of (a,(x,))
self.x = arg[1]
self.y = 'default for non-tuple'
else:
self.x = arg[1][0]
self.y = len(arg[1])==2 and arg[1][1] or 'default'
u = property(fset=_ fset)
def __iter__(self):
return iter((self.a, self.x, self.y))

def test():
upk = Tupk()
for upk.u in [(1,(2,3)), (4,(5,)), (7,8)]:
print upk.a, upk.x, upk.y
upk.u = (9,10)
a,b,c = upk
print 'a=%r, b=%r, c=%r' % (a,b,c)
print list(upk), tuple(upk)

if __name__=='__ma in__': test()
---------------------------------------------
Output:[color=blue][color=green][color=darkred]
>>> import tupk
>>> tupk.test()[/color][/color][/color]
1 2 3
4 5 default
7 8 default for non-tuple
a=9, b=10, c='default for non-tuple'
[9, 10, 'default for non-tuple'] (9, 10, 'default for non-tuple')[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

You could obviously give Tupk an __init__(fmt, defaults) method that would accept
an unpacking spec like 'a, (x, y=%0))', [<default-value 0>]
And give its instances a __call__ method so you can use it like
a,b,c = upk('a, (x, y=%0))', [555])((7,8)) => a,b,c == (7, 8, 555)

How useful how often though?

Regards,
Bengt Richter

[Greg Ewing]

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

AdSR wrote:[color=blue]
> 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?[/color]

Yes. In PyGUI I have some point and rectangle manipulation
utilities that do things like

def add_pt((x1, y1), (x2, y2)):
return (x1 + y1, x2 + y2)

In cases like this, it can help to make things more concise
and probably also slightly more efficient.
[color=blue]
> it looks like one of those language features that make
> committing atrocities an order of magnitude easier.[/color]

I don't remember ever being seriously burned by using it.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg