Re: C#3.0 and lambdas
Mike Meyer wrote: This is a well-known phenomenon, having picked up the name bikeshed something like 40 years ago. Google for bikeshed color. My favourite bikeshed story: A colleague just joined his local Primary School council. On the agenda for his first meeting was that the shelter shed needed painting. There were groans all around and someone said with a loud sigh, I suppose we'll have to get the colour consultants back. -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
Fredrik == Fredrik Lundh [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
On Fri, 23 Sep 2005 15:46:54 +0530, Ganesan Rajagopal [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
[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 [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
A.M. Kuchling [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
A M Kuchling [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
Fredrik Lundh wrote: 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. If I had wanted to say you have opinions? fuck off!, I would have said you have opinions? fuck off!. All I wanted to say is that if you want a common documentation format, and you want it badly, you should show up on python-dev and offer help. Unfortunately, there are not as many Python core developers as Perl core developers, and things move at a slower pace. That's mostly not their fault, and not anyone's fault. It's a consequence of the amount of time that is spent on Python-the-core itself. And why? Well, because it's more fun to program in Python than to program Python. Reinhold -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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_FAST0 (.0) 3 UNPACK_SEQUENCE 2 6 STORE_FAST 1 (x) 9 STORE_FAST 2 (y) 2 12 LOAD_FAST1 (x) 15 PRINT_ITEM 16 LOAD_FAST2 (y) 19 PRINT_ITEM 20 PRINT_NEWLINE 21 LOAD_CONST 0 (None) 24 RETURN_VALUE dis.dis(f2) 2 0 LOAD_FAST0 (x_y) 3 UNPACK_SEQUENCE 2 6 STORE_FAST 2 (x) 9 STORE_FAST 1 (y) 3 12 LOAD_FAST2 (x) 15 PRINT_ITEM 16 LOAD_FAST1 (y) 19 PRINT_ITEM 20 PRINT_NEWLINE 21 LOAD_CONST 0 (None) 24 RETURN_VALUE dis.dis(f3) 2 0 LOAD_FAST0 (x_y) 3 LOAD_CONST 1 (0) 6 BINARY_SUBSCR 7 PRINT_ITEM 8 LOAD_FAST0 (x_y) 11 LOAD_CONST 2 (1) 14 BINARY_SUBSCR 15 PRINT_ITEM 16 PRINT_NEWLINE 17 LOAD_CONST 0 (None) 20 RETURN_VALUE -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
Reinhold Birkenfeld wrote: This is Open Source. If you want an initiative, start one. +1 QOTW. STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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? -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.pycon.org -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 ? -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.pycon.org -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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) -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 [EMAIL PROTECTED] In the fields of hell where the grass grows high Are the graves of dreams allowed to die. -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
Dennis Lee Bieber a écrit : On Wed, 21 Sep 2005 17:08:14 +0200, Christophe [EMAIL PROTECTED] 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 ) -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
On 9/21/05, Scott David Daniels [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Removing nested tuple function parameters (was: C#3.0 and lambdas)
Fredrik Lundh [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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_FAST0 (.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_FAST0 (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
Fredrik Lundh wrote: [EMAIL PROTECTED] wrote: On Slashdot there is a discussion about the future C#3.0: http://developers.slashdot.org/developers/05/09/18/0545217.shtml?tid=109tid=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/download/9/5/0/9503e33e-fde6-4aed-b5d0-ffe749822f1b/csharp%203.0%20specification.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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
[EMAIL PROTECTED] wrote: On Slashdot there is a discussion about the future C#3.0: http://developers.slashdot.org/developers/05/09/18/0545217.shtml?tid=109tid=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/download/9/5/0/9503e33e-fde6-4aed-b5d0-ffe749822f1b/csharp%203.0%20specification.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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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) -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
Paul Rubin wrote: Fredrik Lundh [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
On 9/19/05, Diez B. Roggisch [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
Michael Ekstrand [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: C#3.0 and lambdas
Paul Rubin http://phr.cx@NOSPAM.invalid wrote in message news:[EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
C#3.0 and lambdas
On Slashdot there is a discussion about the future C#3.0:
http://developers.slashdot.org/developers/05/09/18/0545217.shtml?tid=109tid=8
http://msdn.microsoft.com/vcsharp/future/
There are many differences, but it looks a bit more like Python:
http://download.microsoft.com/download/9/5/0/9503e33e-fde6-4aed-b5d0-ffe749822f1b/csharp%203.0%20specification.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 * yMultiple parameters
() = Console.WriteLine() No parameters
The syntax seems nice, but for python the Statement body syntax can
be a problem.
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
