Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://groups.google.com/group/comp.lang.python/msg/ee80ba95b76d76b below:

C#3.0 and lambdas

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

Wolfgang Langner a écrit :

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.

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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.

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to Steven D'Aprano

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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)

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

"Fredrik Lundh" <

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

Paul Rubin wrote:

> "Fredrik Lundh" <

> 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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

> 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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

"Paul Rubin" <"

"@NOSPAM.invalid> wrote in message

news:7xll1sw...@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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to Diez B. Roggisch, pytho...@python.org

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

Michael Ekstrand <

> 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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

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>

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

--
Serhiy Storchaka

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

Serhiy Storchaka a écrit :

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.

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

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>

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

Fredrik Lundh a écrit :

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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 ?

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

This is rubbish.

foo(*p1)

is *exactly* equivalent to

and similarly

bar(p2)

is *exactly* equivalent to

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?

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

Christophe schreef:

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)

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

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>

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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
Scott....@Acm.Org

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

Dennis Lee Bieber a écrit :

> On Wed, 21 Sep 2005 17:08:14 +0200, Christophe <

>

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to Python List

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

"Fredrik Lundh" <

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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.

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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)

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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.

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

Reinhold

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

Reinhold Birkenfeld wrote:
>
> This is Open Source. If you want an initiative, start one.

+1 QOTW.

STeVe

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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?

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

Reinhold Birkenfeld wrote:

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

</F>

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

On Fri, 23 Sep 2005 15:46:54 +0530,

Ganesan Rajagopal <

> 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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to pytho...@python.org

[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
ric...@entrian.com

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

"A.M. Kuchling" <

> 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 <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to

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

You do not have permission to delete messages in this group

Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message

to Mike Meyer

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

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4