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
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
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,
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,
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
[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:
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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 -
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
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,
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,
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
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
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
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
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
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
[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
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.
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
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
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
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
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
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
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
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
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
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
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
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:
49 matches
Mail list logo
