Re: Nested Parameter Definitions

2007-02-26 Thread Paddy
On Feb 25, 11:41 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:

> 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Nested Parameter Definitions

2007-02-25 Thread 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Nested Parameter Definitions

2007-02-25 Thread Hendrik van Rooyen
"Arnaud Delobelle" <[EMAIL PROTECTED]> wrote:


> On Feb 25, 6:00 pm, "Paddy" <[EMAIL PROTECTED]> wrote:
> > 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


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Nested Parameter Definitions

2007-02-25 Thread Gabriel Genellina
En Sun, 25 Feb 2007 15:00:31 -0300, Paddy <[EMAIL PROTECTED]>  
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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Nested Parameter Definitions

2007-02-25 Thread Steven D'Aprano
On Sun, 25 Feb 2007 11:06:03 -0800, Virgil Dupras wrote:

> On Feb 25, 1:00 pm, "Paddy" <[EMAIL PROTECTED]> wrote:
>> 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 

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Nested Parameter Definitions

2007-02-25 Thread 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 

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Nested Parameter Definitions

2007-02-25 Thread Paddy
On Feb 25, 7:06 pm, "Virgil Dupras" <[EMAIL PROTECTED]>
wrote:
> On Feb 25, 1:00 pm, "Paddy" <[EMAIL PROTECTED]> wrote:
>
>
>
> > 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Nested Parameter Definitions

2007-02-25 Thread Arnaud Delobelle
On Feb 25, 6:00 pm, "Paddy" <[EMAIL PROTECTED]> wrote:
> 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Nested Parameter Definitions

2007-02-25 Thread Virgil Dupras
On Feb 25, 1:00 pm, "Paddy" <[EMAIL PROTECTED]> wrote:
> 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.

-- 
http://mail.python.org/mailman/listinfo/python-list