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 shelte
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 buil
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,
> rew
> 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 wan
"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
[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 effe
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 e
> "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 do
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 module
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
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
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
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
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 men
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
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 near
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 tu
"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 t
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 eu
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
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 suc
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 +
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
t
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], p
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],
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
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,
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
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(*
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
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 wen
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
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 abo
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=109&tid=8
> >
> > http://msdn.microsoft.com/vcsharp/future/
>
> "The extensions enable construction of composi
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.
"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
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 u
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
>
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
> 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
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 onc
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
"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
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.
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 h
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 w
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
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 i
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
[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=109&tid=8
>
> http://msdn.microsoft.com/vcsharp/future/
"The extensions enable construction of compositional APIs that
have equal exp
On Slashdot there is a discussion about the future C#3.0:
http://developers.slashdot.org/developers/05/09/18/0545217.shtml?tid=109&tid=8
http://msdn.microsoft.com/vcsharp/future/
There are many differences, but it looks a bit more like Python:
http://download.microsoft.com/download/9/5/0/9503e33e
51 matches
Mail list logo
