Nested Parameter Definitions

[Paddy]

I blogged on finding a new-to-me feature of Python, in that you are
allowed to nnest parameter definitions:

>>def x ((p0, p1), p2):

.... return p0,p1,p2
....

>>x(('Does', 'this'), 'work')

('Does', 'this', 'work')

>>>

Ruben commented that there was a poll on this features continued
existence taken at PyCon and it could go.

Just as I found it, it could go

I wondered if those of you with some Python experience new of nested
parameters and don't use them; or just forgot/don't know it is
possible?

- Paddy.

Oh - the blog entry is at http://paddy3118.blogspot.com/2007/0...parameter.html

[Virgil Dupras]

On Feb 25, 1:00 pm, "Paddy" <[e-mail]:

I blogged on finding a new-to-me feature of Python, in that you are
allowed to nnest parameter definitions:

>def x ((p0, p1), p2):

... return p0,p1,p2
...>>x(('Does', 'this'), 'work')

('Does', 'this', 'work')

Ruben commented that there was a poll on this features continued
existence taken at PyCon and it could go.

Just as I found it, it could go

I wondered if those of you with some Python experience new of nested
parameters and don't use them; or just forgot/don't know it is
possible?

- Paddy.

Oh - the blog entry is athttp://paddy3118.blogspot.com/2007/02/pythons-function-nested-paramet...

I didn't know about it either. Without the call example, I would have
had a hard time to try to figure out what these extra brackets are
for. For this reason, I think that an explicit unpack is more
readable, and thus better.

[Arnaud Delobelle]

On Feb 25, 6:00 pm, "Paddy" <[e-mail]:

I blogged on finding a new-to-me feature of Python, in that you are
allowed to nnest parameter definitions:

>def x ((p0, p1), p2):

... return p0,p1,p2
...>>x(('Does', 'this'), 'work')

('Does', 'this', 'work')

Reminds me of LeLisp! It had a similar feature. IIRC you could write
for example (I think 'df' was LeLisp for 'defun'):
(df mycar (a . b) a)
or
(df mylist L L)
or
(df mycaadr (a (b . c) . e) b)

I didn't know that this was possible in python and it does surprise
me. It feels at odd with the python philosophy.

--
Arnaud

[Paddy]

On Feb 25, 7:06 pm, "Virgil Dupras" <[e-mail]>
wrote:

On Feb 25, 1:00 pm, "Paddy" <[e-mail]:

I blogged on finding a new-to-me feature of Python, in that you are
allowed to nnest parameter definitions:

>>def x ((p0, p1), p2):

... return p0,p1,p2
...>>x(('Does', 'this'), 'work')

('Does', 'this', 'work')

Ruben commented that there was a poll on this features continued
existence taken at PyCon and it could go.

Just as I found it, it could go

I wondered if those of you with some Python experience new of nested
parameters and don't use them; or just forgot/don't know it is
possible?

- Paddy.

Oh - the blog entry is athttp://paddy3118.blogspot.com/2007/02/pythons-function-nested-paramet...

I didn't know about it either. Without the call example, I would have
had a hard time to try to figure out what these extra brackets are
for. For this reason, I think that an explicit unpack is more
readable, and thus better.

The following example shows three possible ways of accessing nested
data. i think , after now knowing how to use it, that the f0 function
with nested parameters and its subsequent use is the most readable.
Manual unpacking in the list comprehension for f1 is messy. No real
reason for liking f0 over f2 except its shiny!

>>def f0 ((p0, p1), p2):

.... pass
....

>>def f1 (p0, p1, p2):

.... pass
....

>>def f2(p):

.... (p0, p1), p2 = p
....

>>data = [ ((1, 2), 3), ((4, 5), 6)]
[ f0(*datum) for datum in data]

[None, None]

>>[ f1(datum[0][0], datum[0][1], datum[1]) for datum in data]

[None, None]

>>[ f2(datum) for datum in data]

[None, None]

>>>

- Paddy.

[Steven D'Aprano]

On Sun, 25 Feb 2007 10:00:31 -0800, Paddy wrote:

I wondered if those of you with some Python experience new of nested
parameters and don't use them; or just forgot/don't know it is
possible?

I learnt about this some time ago. I don't often use it, although it makes
sense to write this:

def parrot(x, (y, z)):
pass

instead of this:

def parrot(x, a2tuple):
y, z = a2tuple
pass

--
Steven D'Aprano

[Steven D'Aprano]

On Sun, 25 Feb 2007 11:06:03 -0800, Virgil Dupras wrote:

On Feb 25, 1:00 pm, "Paddy" <[e-mail]:

>I blogged on finding a new-to-me feature of Python, in that you are
allowed to nnest parameter definitions:

>>def x ((p0, p1), p2):

... return p0,p1,p2

[snip]

I didn't know about it either. Without the call example, I would have
had a hard time to try to figure out what these extra brackets are
for. For this reason, I think that an explicit unpack is more
readable, and thus better.

And now that you do know, it is not hard to figure it out at all.

Nested parameters are no harder to figure out than *args or arg=value.
It's something that you learn, once, and then it is easy forever.

To my mind, def x ((p0, p1), p2) _is_ an explicit unpack. It just takes
place in the parameter definition, where you can see it even if the
source code is not available, not in the body of the function code, where
you may or may not even be able to find it.

--
Steven D'Aprano

[Gabriel Genellina]

En Sun, 25 Feb 2007 15:00:31 -0300, Paddy <pa*******@googlemail.com>
escribió:

>>>def x ((p0, p1), p2):

... return p0,p1,p2

The first time I saw it used was in Zope, a long time ago. And I like it.
Of course it only has any sense if you expect the tuple (p0,p1) to exist
*before* the function is called; by example, when it's the return value of
some other function.

--
Gabriel Genellina

[Hendrik van Rooyen]

"Arnaud Delobelle" <ar*****@googlemail.comwrote:

On Feb 25, 6:00 pm, "Paddy" <[e-mail]:

I blogged on finding a new-to-me feature of Python, in that you are
allowed to nnest parameter definitions:

>>def x ((p0, p1), p2):

... return p0,p1,p2
...>>x(('Does', 'this'), 'work')

('Does', 'this', 'work')

Reminds me of LeLisp! It had a similar feature. IIRC you could write
for example (I think 'df' was LeLisp for 'defun'):
(df mycar (a . b) a)
or
(df mylist L L)
or
(df mycaadr (a (b . c) . e) b)

I didn't know that this was possible in python and it does surprise
me. It feels at odd with the python philosophy.

Not at all - it much nicer than you think, and there is no "nesting"
involved - Penguins carry their eggs on their feet.

The original function definition describes a function that has a two element
tuple as a first parameter, and something else as a second one.
The first two names provide a means of accessing the elements of the
tuple, instead of using slicing.

look at this:

>>def f((a,b),c):

return a,b,c

>>tup = ('hi','there')
f(tup,'foo')

('hi', 'there', 'foo')

>>lis = ['hi','there']
f(lis,'foo')

('hi', 'there', 'foo')

>>d,e,f = f(lis,42)
print d,e,f

hi there 42

>>e

'there'

>>s = 'go'
f(s,'back')

('g', 'o', 'back')

>>>

Long live duck typing...

- Hendrik

[bearophileHUGS]

Virgil Dupras:

Without the call example, I would have
had a hard time to try to figure out what these extra brackets are
for. For this reason, I think that an explicit unpack is more
readable, and thus better.

I can't agree.

Bye,
bearophile

[Paddy]

On Feb 25, 11:41 pm, Dennis Lee Bieber <[e-mail]:

Just looks like an extension of the normal tuple unpacking feature
of the language.

Yep, it looks like good Python to me too. Maybe the tutorial could be
extended to cover this form of parameter too?
It would be good if Brett Cannon could add some comments on why he
asked for a show of hands on the features use?
I'd hate for the feature to be removed because it is not often used,
when the reason it is not often used is because it is hard to find
examples of its use, because its buried in the language reference
manual.

Do any Python books mention nested parameters?

- Paddy.