C#3.0 and lambdas

[bearophileHUGS]

On Slashdot there is a discussion about the future C#3.0:
http://developers.slashdot.org/devel...?tid=109&tid=8

http://msdn.microsoft.com/vcsharp/future/

There are many differences, but it looks a bit more like Python:
http://download.microsoft.com/downlo...cification.doc

I like the lambda sintax enough. If there is a single parameter the
parentheses may be omitted. They are required if there aren't
parameters. The statement body allows the lambda to do anything.

x => x + 1 Expression body
x => { return x + 1; } Statement body
(x, y) => x * y Multiple parameters
() => Console.WriteLine() No parameters

The syntax seems nice, but for python the "Statement body" syntax can
be a problem.

Bye,
bearophile

[Fredrik Lundh]

be************@lycos.com wrote:

On Slashdot there is a discussion about the future C#3.0:
http://developers.slashdot.org/devel...?tid=109&tid=8

http://msdn.microsoft.com/vcsharp/future/
"The extensions enable construction of compositional APIs that
have equal expressive power of query languages in domains such
as relational databases and XML."
There are many differences, but it looks a bit more like Python:
http://download.microsoft.com/downlo...cification.doc

meanwhile, over in python-dev land:

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

</F>

[Wolfgang Langner]

Hello,

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

First I missed the def and thought "Oh no don't remove it
sometimes I pass a tuple to my functions".
But the I saw the "def" keyword and realized I never
used such a function syntax.

So, in one line (my mailer truncated it):

def fxn((a,b)): print a,b'

for removal, not:

'fxn((a,b)' function calls
I'm ok with removal.
bye by Wolfgang

[Roel Schroeven]

Fredrik Lundh schreef:

meanwhile, over in python-dev land:

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

I for one would not like to see that disappear. I like being able to
write, for example:

def drawline((x1, y1), (x2, y2)):
# draw a line from x1, y1 to x2, y2
foo(x1, y1)
bar(x2, y2)

instead of

def drawline(p1, p2):
x1, y1 = p1
x2, y2 = p2
# draw a line from x1, y1 to x2, y2
foo(x1, y1)
bar(x2, y2)

or

def drawline(p1, p2):
# draw a line from p1[0], p1[1] to p2[0], p2[1]
foo(p1[0], p1[1])
bar(p2[0], p2[1])
--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven

[Christophe]

Wolfgang Langner a écrit :

Hello,

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

First I missed the def and thought "Oh no don't remove it
sometimes I pass a tuple to my functions".
But the I saw the "def" keyword and realized I never
used such a function syntax.

So, in one line (my mailer truncated it):

def fxn((a,b)): print a,b'

for removal, not:

'fxn((a,b)' function calls
I'm ok with removal.
bye by Wolfgang

I use them a lot myself and I wouldn't want to see them removed. It is
just so convenient to have 2D coordinates be simple tuples and have
functions which alternatively take pos or (x,y) as a parameter.

[Steven D'Aprano]

On Mon, 19 Sep 2005 10:31:48 +0200, Fredrik Lundh wrote:

meanwhile, over in python-dev land:

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

Consider this:

def func(some_tuple):

How many items should you pass in the tuple? If it takes variable
arguments, then that works, but if you always expect a fixed number, then

def func((x, y))

is more explicit.

The only problem I have is that once you unroll the tuple like that, it is
hardly necessary to pass the argument as a tuple. Why not just pass x and
y as two arguments?

def func(x, y)

I think tuple unrolling would work better if there was a way to refer to
the argument as both a tuple and by the components. Eg, making up a
hypothetical syntax for it:

def func(pt?(x,y)):
print "Tuple", pt
print "Items", x, y

Calling func((2,3)) prints:

"Tuple" (2, 3)
"Items" 2 3

Of course, this opens a can of worms, what happens if you pass a mutable
object like a list instead of a tuple or string?

Still, if Python is eventually to get something static types, it probably
makes sense to keep the def func((x,y)) idiom, because it will come in
handy for ensuring that your sequence arguments have the right number of
items.

--
Steven.

[Max M]

Steven D'Aprano wrote:

On Mon, 19 Sep 2005 10:31:48 +0200, Fredrik Lundh wrote:

How many items should you pass in the tuple? If it takes variable
arguments, then that works, but if you always expect a fixed number, then

def func((x, y))

is more explicit.

The only problem I have is that once you unroll the tuple like that, it is
hardly necessary to pass the argument as a tuple. Why not just pass x and
y as two arguments?

def func(x, y)

why not just pass the tuple as arguments then?

def func(*(x, y))

or as it would normally look:

def func(*arg)

That should work just as well for those cases.

--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

[Christophe]

Max M a écrit :

Steven D'Aprano wrote:

On Mon, 19 Sep 2005 10:31:48 +0200, Fredrik Lundh wrote:

How many items should you pass in the tuple? If it takes variable
arguments, then that works, but if you always expect a fixed number, then

def func((x, y))

is more explicit.

The only problem I have is that once you unroll the tuple like that,
it is
hardly necessary to pass the argument as a tuple. Why not just pass x and
y as two arguments?

def func(x, y)

why not just pass the tuple as arguments then?

def func(*(x, y))

or as it would normally look:

def func(*arg)

That should work just as well for those cases.

I don't want to unroll x, y in the function API because the function
signature is that it takes a position object. The fact that the position
object just happens to be a 2 element tuples as no incidence on that. I
want the function API to be that. Why would you ask ? Because it make
sense to do it like that when I create a second function which takes 2
posiiton objets.

Why should I call the first with that sytnax : f(*pos) and the second
with that one : g(pos1, pos2)

[Paul Rubin]

"Fredrik Lundh" <fr*****@pythonware.com> writes:

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

It's not just function parameters, it works in assignments too:

s = ((1,2), (3,4))
...
((x1,y1), (x2,y2)) = s

Why is there such eagerness to remove it?

The corresponding feature in Lisp is called destructuring-bind and
it's quite useful.

[Steven Bethard]

Paul Rubin wrote:

"Fredrik Lundh" <fr*****@pythonware.com> writes:

"Is anyone truly attached to nested tuple function parameters;
'def fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

It's not just function parameters, it works in assignments too:

s = ((1,2), (3,4))
...
((x1,y1), (x2,y2)) = s

Why is there such eagerness to remove it?

The eagerness is only to remove it from function parameters, not from
tuple unpacking in general. I'm not sure I fully understand why people
are eager to do this, but it has to do something with making the AST
simpler, and that the form itself is not used all that often.

But since I'm on the don't-remove-it side, my understanding of the
arguments against it is probably lacking. ;)

STeVe

[Steven Bethard]

Steven D'Aprano wrote:

Consider this:

def func(some_tuple):

How many items should you pass in the tuple? If it takes variable
arguments, then that works, but if you always expect a fixed number, then

def func((x, y))

is more explicit.

The only problem I have is that once you unroll the tuple like that, it is
hardly necessary to pass the argument as a tuple. Why not just pass x and
y as two arguments?

def func(x, y)

I generally agree with this (and follow the same guideline in my own
APIs), but sometimes you don't have this option. If I have a class that
I'd like to support an indexing operation like:

obj[x, y]

then the natural __getitem__ signature will look like:

def __getitem__(self, (x, y)):
...

STeVe

[Diez B. Roggisch]

> meanwhile, over in python-dev land:

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

I am - I think that feature is sort of an orthogonality which should be
preserved. No doubt its not one of the most important ones - but if I
can write

a, (b ,c) = 1, (2,3)

I'd like to write

def foo(a, (b,c)):
...

foo(1, (2,3))

too.

Diez

[Michael Ekstrand]

On Monday 19 September 2005 08:18, Roel Schroeven wrote:

def drawline((x1, y1), (x2, y2)):
# draw a line from x1, y1 to x2, y2
foo(x1, y1)
bar(x2, y2)

Yow! I did not know you could even do this.

My vote would be +1 for keeping them in the language... they look far
too useful to deprecate/remove...

-Michael

[Bill Mill]

On 9/19/05, Diez B. Roggisch <de***@nospam.web.de> wrote:

meanwhile, over in python-dev land:

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

I am - I think that feature is sort of an orthogonality which should be
preserved. No doubt its not one of the most important ones - but if I
can write

a, (b ,c) = 1, (2,3)

I'd like to write

def foo(a, (b,c)):
...

foo(1, (2,3))

Agreed. I discovered them when I wondered "wouldn't it be neat if
functions unpacked tuples just like regular code does?" And was
pleasantly surprised to find that they did.

+1 on keeping them.

Peace
Bill Mill
bill.mill at gmail.com

[Paul Rubin]

Michael Ekstrand <me******@iastate.edu> writes:

def drawline((x1, y1), (x2, y2)):
# draw a line from x1, y1 to x2, y2
foo(x1, y1)
bar(x2, y2)

Yow! I did not know you could even do this.

My vote would be +1 for keeping them in the language... they look far
too useful to deprecate/remove...

I'm +1 for keeping them in the language and +1000 on keeping them
in Python 2.5. Removing them would break existing code and therefore
should not be done until Python 3.0 if at all.

[Terry Reedy]

"Paul Rubin" <"http://phr.cx"@NOSPAM.invalid> wrote in message
news:7x************@ruckus.brouhaha.com...

I'm +1 for keeping them in the language and +1000 on keeping them
in Python 2.5. Removing them would break existing code and therefore
should not be done until Python 3.0 if at all.

I believe the idea of removing nested tuple parameters before 3.0 has been
withdrawn. Guido is mildly considering the possibility for 3.0.

Terry J. Reedy

[Bryan]

Diez B. Roggisch wrote:

meanwhile, over in python-dev land:

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

I am - I think that feature is sort of an orthogonality which should be
preserved. No doubt its not one of the most important ones - but if I
can write

a, (b ,c) = 1, (2,3)

I'd like to write

def foo(a, (b,c)):
...

foo(1, (2,3))

too.

Diez

exactly... consistency is the most important thing here. i use this style all
the time. i will be very disappointed to find this removed from python. i'm +1
for keeping it.

bryan

[Kay Schluehr]

Fredrik Lundh wrote:

be************@lycos.com wrote:

On Slashdot there is a discussion about the future C#3.0:
http://developers.slashdot.org/devel...?tid=109&tid=8

http://msdn.microsoft.com/vcsharp/future/

"The extensions enable construction of compositional APIs that
have equal expressive power of query languages in domains such
as relational databases and XML."

There are many differences, but it looks a bit more like Python:
http://download.microsoft.com/downlo...cification.doc

meanwhile, over in python-dev land:

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

</F>

I won't get nervous if they will be refused in their poor current state
but I would get excited if they will be extended to something becoming
close to algebraic data types enabling pattern matching. Maybe it's an
irony of the Python development process that it tries to refuse
functional programming facilities in just a moment where mainstream
languages start to embrace them. Besides C# also VisualBasic gets
improved:

http://lambda-the-ultimate.org/node/view/967

For the Java platform Scala raises some attention too, after the
failure of the Java design team of integrating generics in a clean and
comprehensible way with the existing language.

Here is Scalas attempt for pattern matching called "case classes":

http://scala.epfl.ch/intro/caseclasses.html

I do think that gimmicks, syntax permutations and refusals of so called
"Python warts" are not sufficient to preserve language attraction in a
competing field that tries to make fast progress.

Kay

[Fredrik Lundh]

Kay Schluehr wrote:

Maybe it's an irony of the Python development process that it tries
to refuse functional programming facilities in just a moment where
mainstream languages start to embrace them.

hey, at least one other person got my point ;-)

(fwiw, today's python-dev discussion is about changing the behaviour
of the "and" and "or" operators. priorities, priorities...)

</F>

[Serhiy Storchaka]

Roel Schroeven wrote:

Fredrik Lundh schreef:

meanwhile, over in python-dev land:

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

I for one would not like to see that disappear. I like being able to
write, for example:

def drawline((x1, y1), (x2, y2)):
# draw a line from x1, y1 to x2, y2
foo(x1, y1)
bar(x2, y2)

instead of

def drawline(p1, p2):
x1, y1 = p1
x2, y2 = p2
# draw a line from x1, y1 to x2, y2
foo(x1, y1)
bar(x2, y2)

or

def drawline(p1, p2):
# draw a line from p1[0], p1[1] to p2[0], p2[1]
foo(p1[0], p1[1])
bar(p2[0], p2[1])

def drawline(p1, p2):
# draw a line from p1 to p2
foo(*p1)
bar(*p2)

--
Serhiy Storchaka

[Christophe]

Serhiy Storchaka a écrit :

Roel Schroeven wrote:

Fredrik Lundh schreef:

meanwhile, over in python-dev land:

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../

Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

I for one would not like to see that disappear. I like being able to
write, for example:

def drawline((x1, y1), (x2, y2)):
# draw a line from x1, y1 to x2, y2
foo(x1, y1)
bar(x2, y2)

instead of

def drawline(p1, p2):
x1, y1 = p1
x2, y2 = p2
# draw a line from x1, y1 to x2, y2
foo(x1, y1)
bar(x2, y2)

or

def drawline(p1, p2):
# draw a line from p1[0], p1[1] to p2[0], p2[1]
foo(p1[0], p1[1])
bar(p2[0], p2[1])

def drawline(p1, p2):
# draw a line from p1 to p2
foo(*p1)
bar(*p2)

That one is stupid. I don't see how you can make it work without some
global storing the p1 information in foo which I would consider as very
ugly code.

[Fredrik Lundh]

Christophe wrote:

def drawline(p1, p2):
# draw a line from p1 to p2
foo(*p1)
bar(*p2)

That one is stupid. I don't see how you can make it work without some
global storing the p1 information in foo which I would consider as very
ugly code.

if you cannot see how that can work, you clearly haven't done much graphics
programming in your days...

</F>

[Steve Holden]

Christophe wrote:

Serhiy Storchaka a écrit :

Roel Schroeven wrote: [...]

or

def drawline(p1, p2):
# draw a line from p1[0], p1[1] to p2[0], p2[1]
foo(p1[0], p1[1])
bar(p2[0], p2[1])

def drawline(p1, p2):
# draw a line from p1 to p2
foo(*p1)
bar(*p2)

That one is stupid. I don't see how you can make it work without some
global storing the p1 information in foo which I would consider as very
ugly code.

In which case perhaps you should actually try the code. Then once you
realise it works you can start to figure out why :-). Hint: f(*p1)
appears as len(p1) separate arguments to the called function.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.pycon.org

[Christophe]

Fredrik Lundh a écrit :

Christophe wrote:

def drawline(p1, p2):
# draw a line from p1 to p2
foo(*p1)
bar(*p2)

That one is stupid. I don't see how you can make it work without some
global storing the p1 information in foo which I would consider as very
ugly code.

if you cannot see how that can work, you clearly haven't done much graphics
programming in your days...

You should probably notice that graphics library have changed a lot in
the last 20 years. Also, that one was an example but it could have been :

def draw_circle(c, p):
"""Draws a circle centered on c and which goes through p"""
pass

[Christophe]

Steve Holden a écrit :

Christophe wrote:

Serhiy Storchaka a écrit :

Roel Schroeven wrote:
[...]
or

def drawline(p1, p2):
# draw a line from p1[0], p1[1] to p2[0], p2[1]
foo(p1[0], p1[1])
bar(p2[0], p2[1])

def drawline(p1, p2):
# draw a line from p1 to p2
foo(*p1)
bar(*p2)

That one is stupid. I don't see how you can make it work without some
global storing the p1 information in foo which I would consider as
very ugly code.

In which case perhaps you should actually try the code. Then once you
realise it works you can start to figure out why :-). Hint: f(*p1)
appears as len(p1) separate arguments to the called function.

You should also notice that foo knows the starting point of the line but
not the ending point and so it can't draw the line. On the other hand,
bar knows the end point but not the starting point so it can't do the
job either.

And what about a function which computes the line length ?

[Steve Holden]

Christophe wrote:

Steve Holden a écrit :

Christophe wrote:

Serhiy Storchaka a écrit :
Roel Schroeven wrote:
[...]

>or
>
>def drawline(p1, p2):
> # draw a line from p1[0], p1[1] to p2[0], p2[1]
> foo(p1[0], p1[1])
> bar(p2[0], p2[1])

def drawline(p1, p2):
# draw a line from p1 to p2
foo(*p1)
bar(*p2)

That one is stupid. I don't see how you can make it work without some
global storing the p1 information in foo which I would consider as
very ugly code.

In which case perhaps you should actually try the code. Then once you
realise it works you can start to figure out why :-). Hint: f(*p1)
appears as len(p1) separate arguments to the called function.

You should also notice that foo knows the starting point of the line but
not the ending point and so it can't draw the line. On the other hand,
bar knows the end point but not the starting point so it can't do the
job either.

This is rubbish.

foo(*p1)

is *exactly* equivalent to

foo(p1[0], p1[1])

and similarly

bar(p2)

is *exactly* equivalent to

bar(p2[0], p2[1])

and consequently the second version of drawline is exactly equivalent to
the first. So, if the second one is useless then so is the first.
And what about a function which computes the line length ?

I'm not sure what point you are trying to make here. Can you explain?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.pycon.org

[Roel Schroeven]

Christophe schreef:

Steve Holden a écrit :

Christophe wrote:

Serhiy Storchaka a écrit :

Roel Schroeven wrote:

[...]

> or
>
> def drawline(p1, p2):
> # draw a line from p1[0], p1[1] to p2[0], p2[1]
> foo(p1[0], p1[1])
> bar(p2[0], p2[1])


def drawline(p1, p2):
# draw a line from p1 to p2
foo(*p1)
bar(*p2)

That one is stupid. I don't see how you can make it work without some
global storing the p1 information in foo which I would consider as
very ugly code.

In which case perhaps you should actually try the code. Then once you
realise it works you can start to figure out why :-). Hint: f(*p1)
appears as len(p1) separate arguments to the called function.

You should also notice that foo knows the starting point of the line but
not the ending point and so it can't draw the line. On the other hand,
bar knows the end point but not the starting point so it can't do the
job either.

It was just an example of tuples as arguments to a function and doing
something with the values of the tuples in the function itself. Even so,
many graphical environments offer MoveTo(x, y) and LineTo(x, y) or
equivalents. MoveTo moves some internal cursor to the specified position
without drawing a line; LineTo draws a line from the stored cursor
position to the specified position and moves the internal cursor to that
new position.
And what about a function which computes the line length ?

That would have been a better example indeed, since the *p1 trick
doesn't work there.

def euclidian_distance((x1, y1), (x2, y2)):
return math.sqrt((x2 - x1)**2 + (y2 - y1)**2)

That's a lot nicer, I think, than this:

def euclidian_distance(p1, p2):
return math.sqrt((p2[0] - p1[0])**2 + (p2[1] - p1[1])**2)
--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven

[Christophe]

Steve Holden a écrit :

Christophe wrote:

Steve Holden a écrit :

Christophe wrote:
Serhiy Storchaka a écrit :
> Roel Schroeven wrote:
[...]
>> or
>>
>> def drawline(p1, p2):
>> # draw a line from p1[0], p1[1] to p2[0], p2[1]
>> foo(p1[0], p1[1])
>> bar(p2[0], p2[1])
>
>
>
>
> def drawline(p1, p2):
> # draw a line from p1 to p2
> foo(*p1)
> bar(*p2)
>
That one is stupid. I don't see how you can make it work without
some global storing the p1 information in foo which I would consider
as very ugly code.

In which case perhaps you should actually try the code. Then once you
realise it works you can start to figure out why :-). Hint: f(*p1)
appears as len(p1) separate arguments to the called function.

You should also notice that foo knows the starting point of the line
but not the ending point and so it can't draw the line. On the other
hand, bar knows the end point but not the starting point so it can't
do the job either.

This is rubbish.

foo(*p1)

is *exactly* equivalent to

foo(p1[0], p1[1])

and similarly

bar(p2)

is *exactly* equivalent to

bar(p2[0], p2[1])

and consequently the second version of drawline is exactly equivalent to
the first. So, if the second one is useless then so is the first.

Well, sorry about that but you are perfectly right. The point I was
trying to defend though was that such construct is very uncommon. It
isn't always possible to unpack the tuples like that because you usually
need all the info at once.

And what about a function which computes the line length ?

I'm not sure what point you are trying to make here. Can you explain?

As I said, the point was that in that specific case, you can do it like
that, but most of the time you need the unpack info for all the data in
the same function. For example to compute the line length.

def length((x1,y1),(x2,y2)):
return math.hypot(x1-x2,y1-y2)

No unpack trick ( that I know of ) can be used here. You only have 1 way
to do it without the unpack in function parameters syntax :

def length(p1, p2):
x1, y1 = p1
x2, y2 = p2
return math.hypot(x1-x2,y1-y2)

[Fredrik Lundh]

Christophe wrote:

if you cannot see how that can work, you clearly haven't done much graphics
programming in your days...

You should probably notice that graphics library have changed a lot in
the last 20 years.

yeah, nobody uses things like OpenGL and PDF and SVG and similar APIs
these days...

</F>

[Scott David Daniels]

Roel Schroeven wrote:

...
Christophe schreef:

...
And what about a function which computes the line length ?

That would have been a better example indeed, since the *p1 trick
doesn't work there.

def euclidian_distance((x1, y1), (x2, y2)):
return math.sqrt((x2 - x1)**2 + (y2 - y1)**2)

That's a lot nicer, I think, than this:

def euclidian_distance(p1, p2):
return math.sqrt((p2[0] - p1[0])**2 + (p2[1] - p1[1])**2)

But not massively nicer than:

def euclidian_distance(p1, p2):
(x1, y1), (x2, y2) = p1, p2
return math.sqrt((x2 - x1)**2 + (y2 - y1)**2)

--Scott David Daniels
Sc***********@Acm.Org

[Robert Kern]

Christophe wrote:

Steve Holden a écrit :

and consequently the second version of drawline is exactly equivalent to
the first. So, if the second one is useless then so is the first.

Well, sorry about that but you are perfectly right. The point I was
trying to defend though was that such construct is very uncommon. It
isn't always possible to unpack the tuples like that because you usually
need all the info at once.

Many, many drawing APIs use a Postscript-like model such that drawing a
line from p1 to p2 decomposes into something like this:

moveto(p1)
lineto(p2)

Almost always those are methods on some object that maintains the state
(no globals in sight):

gc.moveto(p1)
gc.lineto(p2)

I think it's much more common than you realize. You are right that there
are plenty of functions that you might want to call that would require
something like this:

low_level_drawline(x1, y1, x2, y2)

that isn't amenable to *argument unpacking.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Dennis Lee Bieber]

On Wed, 21 Sep 2005 17:08:14 +0200, Christophe <ch*************@free.fr>
declaimed the following in comp.lang.python:

No unpack trick ( that I know of ) can be used here. You only have 1 way
to do it without the unpack in function parameters syntax :

def length(p1, p2):
x1, y1 = p1
x2, y2 = p2
return math.hypot(x1-x2,y1-y2)

import math
def length(p1, p2): .... return math.hypot(p1[0] - p2[0], p1[1] - p2[1])
.... length((1,2),(4,6)) 5.0

Still no need for intermediate variables, you can index the tuple at
need.
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

[Christophe]

Dennis Lee Bieber a écrit :

On Wed, 21 Sep 2005 17:08:14 +0200, Christophe <ch*************@free.fr>
declaimed the following in comp.lang.python:

No unpack trick ( that I know of ) can be used here. You only have 1 way
to do it without the unpack in function parameters syntax :

def length(p1, p2):
x1, y1 = p1
x2, y2 = p2
return math.hypot(x1-x2,y1-y2)

import math
def length(p1, p2):
... return math.hypot(p1[0] - p2[0], p1[1] - p2[1])
...
length((1,2),(4,6))

5.0
Still no need for intermediate variables, you can index the tuple at
need.

Well, I prefer the explicit tuple unpack anyway. It gives better results
than using tuple indexing ( and better performance too most of the time )

[Bill Mill]

On 9/21/05, Scott David Daniels <Sc***********@acm.org> wrote:

Roel Schroeven wrote:

...
Christophe schreef:

...
And what about a function which computes the line length ?

That would have been a better example indeed, since the *p1 trick
doesn't work there.

def euclidian_distance((x1, y1), (x2, y2)):
return math.sqrt((x2 - x1)**2 + (y2 - y1)**2)

That's a lot nicer, I think, than this:

def euclidian_distance(p1, p2):
return math.sqrt((p2[0] - p1[0])**2 + (p2[1] - p1[1])**2)

But not massively nicer than:

def euclidian_distance(p1, p2):
(x1, y1), (x2, y2) = p1, p2
return math.sqrt((x2 - x1)**2 + (y2 - y1)**2)

But the question is - why go to the effort to remove the (by your
admission) slightly nicer version?

Peace
Bill Mill
bill.mill at gmail.com

[Dieter Maurer]

"Fredrik Lundh" <fr*****@pythonware.com> writes on Mon, 19 Sep 2005 10:31:48 +0200:

...
meanwhile, over in python-dev land:

"Is anyone truly attached to nested tuple function parameters; 'def
fxn((a,b)): print a,b'? /.../
Yes, I am...
Would anyone really throw a huge fit if they went away? I am willing
to write a PEP for their removal in 2.6 with a deprecation in 2.5 if
people are up for it."

I would think of it as a great stupidity.

[Steven D'Aprano]

On Wed, 21 Sep 2005 18:48:22 +0200, Christophe wrote:

Well, I prefer the explicit tuple unpack anyway. It gives better results
than using tuple indexing ( and better performance too most of the time )

I would love to see your test code and profiling results that demonstrate
that explicit tuple unpacking in the body of a function is faster than
tuple unpacking (implicit or explicit) in the header of a function.
--
Steven.

[Steven Bethard]

Steven D'Aprano wrote:

I would love to see your test code and profiling results that demonstrate
that explicit tuple unpacking in the body of a function is faster than
tuple unpacking (implicit or explicit) in the header of a function.

Should be pretty close. I believe the byte-code is nearly identical:

py> def f1((x, y)):
.... pass
....
py> def f2(x_y):
.... x, y = x_y
....
py> dis.dis(f1)
1 0 LOAD_FAST 0 (.0)
3 UNPACK_SEQUENCE 2
6 STORE_FAST 1 (x)
9 STORE_FAST 2 (y)

2 12 LOAD_CONST 0 (None)
15 RETURN_VALUE
py> dis.dis(f2)
2 0 LOAD_FAST 0 (x_y)
3 UNPACK_SEQUENCE 2
6 STORE_FAST 2 (x)
9 STORE_FAST 1 (y)
12 LOAD_CONST 0 (None)
15 RETURN_VALUE

STeVe

[Christophe]

Steven Bethard a écrit :

Steven D'Aprano wrote:

I would love to see your test code and profiling results that demonstrate
that explicit tuple unpacking in the body of a function is faster than
tuple unpacking (implicit or explicit) in the header of a function.

Should be pretty close. I believe the byte-code is nearly identical:

You forgot the most important function : f3

def f1((x,y)): .... print x,y
.... def f2(x_y): .... x,y = x_y
.... print x,y
.... def f3(x_y): .... print x_y[0], x_y[1]
.... import dis
dis.dis(f1) 1 0 LOAD_FAST 0 (.0)
3 UNPACK_SEQUENCE 2
6 STORE_FAST 1 (x)
9 STORE_FAST 2 (y)

2 12 LOAD_FAST 1 (x)
15 PRINT_ITEM
16 LOAD_FAST 2 (y)
19 PRINT_ITEM
20 PRINT_NEWLINE
21 LOAD_CONST 0 (None)
24 RETURN_VALUE dis.dis(f2) 2 0 LOAD_FAST 0 (x_y)
3 UNPACK_SEQUENCE 2
6 STORE_FAST 2 (x)
9 STORE_FAST 1 (y)

3 12 LOAD_FAST 2 (x)
15 PRINT_ITEM
16 LOAD_FAST 1 (y)
19 PRINT_ITEM
20 PRINT_NEWLINE
21 LOAD_CONST 0 (None)
24 RETURN_VALUE dis.dis(f3) 2 0 LOAD_FAST 0 (x_y)
3 LOAD_CONST 1 (0)
6 BINARY_SUBSCR
7 PRINT_ITEM
8 LOAD_FAST 0 (x_y)
11 LOAD_CONST 2 (1)
14 BINARY_SUBSCR
15 PRINT_ITEM
16 PRINT_NEWLINE
17 LOAD_CONST 0 (None)
20 RETURN_VALUE

[Erik Wilsher]

And I think the discussion that followed proved your point perfectly
Fredrik. Big discussion over fairly minor things, but no "big picture".
Where are the initiatives on the "big stuff" (common documentation
format, improved build system, improved web modules, reworking the
standard library to mention a few) Hey, even Ruby is passing us here.

[Reinhold Birkenfeld]

Erik Wilsher wrote:

And I think the discussion that followed proved your point perfectly
Fredrik. Big discussion over fairly minor things, but no "big picture".
Where are the initiatives on the "big stuff" (common documentation
format, improved build system, improved web modules, reworking the
standard library to mention a few) Hey, even Ruby is passing us here.

This is Open Source. If you want an initiative, start one.

Reinhold

[Steven Bethard]

Reinhold Birkenfeld wrote:

This is Open Source. If you want an initiative, start one.

+1 QOTW.

STeVe

[Erik Wilsher]

Python developement is discussed, decided and usually developed within
the members of python-dev. Have you seen any discussions about
xml-literals in python-dev lately?

[Reinhold Birkenfeld]

Erik Wilsher wrote:

Python developement is discussed, decided and usually developed within
the members of python-dev. Have you seen any discussions about
xml-literals in python-dev lately?

No. I don't need them, so I don't start a discussion. If you need them, or
you want them, feel free to do so.

Reinhold

[Fredrik Lundh]

Reinhold Birkenfeld wrote:

And I think the discussion that followed proved your point perfectly
Fredrik. Big discussion over fairly minor things, but no "big picture".
Where are the initiatives on the "big stuff" (common documentation
format, improved build system, improved web modules, reworking the
standard library to mention a few) Hey, even Ruby is passing us here.

This is Open Source. If you want an initiative, start one.

you know, this "you have opinions? fuck off!" attitude isn't really helping.

</F>

[Ganesan Rajagopal]

>>>>> "Fredrik" == Fredrik Lundh <fr*****@pythonware.com> writes:

Reinhold Birkenfeld wrote:

And I think the discussion that followed proved your point perfectly
Fredrik. Big discussion over fairly minor things, but no "big picture".
Where are the initiatives on the "big stuff" (common documentation
format, improved build system, improved web modules, reworking the
standard library to mention a few) Hey, even Ruby is passing us here.
This is Open Source. If you want an initiative, start one.

you know, this "you have opinions? fuck off!" attitude isn't really
helping.

I agree. I am a lurker in this list and the python-devel list and I've also
noticed that increasingly big discussions happen over fairly minor
things. Python's DB API is still stuck at 2.0 and we can't even agree on a
single parameter style while C# is innovating and moving ahead with the "big
picture" stuff.

I mean who really cares what's the exact syntax for the ternary
operator. Python's white space significance was a shock when I first learnt
python. I have learnt to live with it because there are a lot other things
to like about the language. I'll live with whatever final decision on the
ternary syntax or whether "and" and "or" should a boolean or the last
expression.

I'd like to see the DB API move forward, and experimental new innovations
like static typing (with automatic type inferencing), stackless python
etc. If the experiments don't survive, fine. It's still better than
quibbling over minor syntactic detail.

Ganesan
--
Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA
Web: http://employees.org/~rganesan | http://rganesan.blogspot.com

[A.M. Kuchling]

On Fri, 23 Sep 2005 15:46:54 +0530,
Ganesan Rajagopal <rg******@myrealbox.com> wrote:

I agree. I am a lurker in this list and the python-devel list and I've also
noticed that increasingly big discussions happen over fairly minor
things. Python's DB API is still stuck at 2.0 and we can't even agree on a
single parameter style while C# is innovating and moving ahead with the "big
picture" stuff.
The group of committers is a diverse group of people, and not every one of
them uses a relational database; that effort would be better done on the
DB-SIG mailing list, because the people there presumably do all use an
RDBMS. (Now, if you wanted to include SQLite in core Python, that *would*
be a python-dev topic, and ISTR it's been brought up in the past.)

This is also something the PSF might fund. The next time the PSF calls for
grant proposals, someone could request funding to edit a new revision of the
DB-API.
I'd like to see the DB API move forward, and experimental new innovations
like static typing (with automatic type inferencing), stackless python
etc. If the experiments don't survive, fine. It's still better than
quibbling over minor syntactic detail.

Agreed; python-dev has gotten pretty boring with all the endless discussions
over some minor point. Of course, it's much easier and lower-effort to
propose a syntax or nitpick a small point issue than to tackle a big
complicated issue like static typing.

Similar things happen on the catalog SIG: people suggest, or even implement,
an automatic package management system, But bring up the question of whether
it should be called PyPI or Cheeseshop or the Catalog, and *everyone* can make
a suggestion.

--amk

[Richie Hindle]

[amk]

Similar things happen on the catalog SIG: people suggest, or even implement,
an automatic package management system, But bring up the question of whether
it should be called PyPI or Cheeseshop or the Catalog, and *everyone* can make
a suggestion.

This is known as the "bike shed effect":

http://linuxmafia.com/~rick/lexicon.html#bikeshed

--
Richie Hindle
ri****@entrian.com

[Mike Meyer]

"A.M. Kuchling" <am*@amk.ca> writes:

Agreed; python-dev has gotten pretty boring with all the endless discussions
over some minor point. Of course, it's much easier and lower-effort to
propose a syntax or nitpick a small point issue than to tackle a big
complicated issue like static typing.

Similar things happen on the catalog SIG: people suggest, or even implement,
an automatic package management system, But bring up the question of whether
it should be called PyPI or Cheeseshop or the Catalog, and *everyone* can make
a suggestion.

This is a well-known phenomenon, having picked up the name "bikeshed"
something like 40 years ago. Google for "bikeshed color". Or just
check out the FreeBSD FAQ entry at <URL: http://www.bikeshed.com/ >.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Ganesan Rajagopal]

>>>>> A M Kuchling <am*@amk.ca> writes:

The group of committers is a diverse group of people, and not every one of
them uses a relational database; that effort would be better done on the
DB-SIG mailing list, because the people there presumably do all use an
RDBMS. (Now, if you wanted to include SQLite in core Python, that *would*
be a python-dev topic, and ISTR it's been brought up in the past.)
I would definitely love to see SQLite included in core python. I am a Unix
systems/networking programmer myself. Just like the fact that everything
looks like a database programmers to most database, I've observed that the
reverse is true for non database programmers. In other words, most non RDMS
normally don't think of a database even the solution screams for a
database. I think SQLite does an amazing job in bridging this gap.
Agreed; python-dev has gotten pretty boring with all the endless discussions
over some minor point. Of course, it's much easier and lower-effort to
propose a syntax or nitpick a small point issue than to tackle a big
complicated issue like static typing.
You have a point there :-).
Similar things happen on the catalog SIG: people suggest, or even
implement, an automatic package management system, But bring up the
question of whether it should be called PyPI or Cheeseshop or the Catalog,
and *everyone* can make a suggestion.

My memory may not be perfect but I remember reading that Python 2.5's focus
is libraries and no language changes. If that's correct, I can understand
why core python folks are more interested in discussing language features
for Python 3000 ;-). Speaking of libraries, I haven't seen many discussions
on libraries in python-dev. Is there some other list with more discussions
on libraries?

Ganesan

--
Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA
Web: http://employees.org/~rganesan | http://rganesan.blogspot.com

[Steven Bethard]

Erik Wilsher wrote:

And I think the discussion that followed proved your point perfectly
Fredrik. Big discussion over fairly minor things, but no "big
picture". Where are the initiatives on the "big stuff" (common
documentation format, improved build system, improved web modules,
reworking the standard library to mention a few) Hey, even Ruby is
passing us here.
Reinhold Birkenfeld wrote: This is Open Source. If you want an initiative, start one.
Fredrik Lundh wrote: you know, this "you have opinions? fuck off!" attitude isn't really helping.

While I should know better than replying to </F>, ;) I have to say that
I don't think "you have opinions? fuck off!" was the intent at all. I
don't know many people who'd argue that we don't need:

* more complete and better organized documentation
* a simpler build/install system
* etc.

But they'll never get done if no one volunteers to work on them.
Recently, I saw a volunteer on python-dev looking to help make the docs
more complete, and he was redirected to the docs SIG to help out. This
is good. I know that there's been a bunch of work on setuptools[1]
that's supposed to be a real improvement on distutils. This is also goood.

But there're only so many man-hours available to work on these projects.
If you see a problem, and you want it fixed, the right thing to do is
to donate some of your time to a project that needs it. This, I
believe, is the essence of Reinhold Birkenfeld's comment.

STeVe
[1]http://peak.telecommunity.com/DevCenter/setuptools