C#3.0 and lambdas

B

bearophileHUGS

On Slashdot there is a discussion about the future C#3.0:
http://developers.slashdot.org/developers/05/09/18/0545217.shtml?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/downl...5d0-ffe749822f1b/csharp 3.0 specification.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
 
F

Fredrik Lundh


"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/downl...5d0-ffe749822f1b/csharp 3.0 specification.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>
 
W

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
 
R

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])
 
C

Christophe

Wolfgang Langner a écrit :
Hello,



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

Max M

Steven said:
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
 
S

Steven D'Aprano

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

Paul Rubin

Fredrik Lundh said:
"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.
 
C

Christophe

Max M a écrit :
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)
 
S

Steven Bethard

Paul said:
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
 
S

Steven Bethard

Steven said:
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
 
D

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
 
M

Michael Ekstrand

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
 
B

Bill Mill

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
 
P

Paul Rubin

Michael Ekstrand said:
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.
 
T

Terry Reedy

Paul Rubin said:
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
 
B

Bryan

Diez said:
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
 
K

Kay Schluehr

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


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
 
F

Fredrik Lundh

Kay said:
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>
 
S

Serhiy Storchaka

Roel said:
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)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top