Re: [Python-Dev] removing nested tuple function parameters

2005-09-17 Thread Steven Bethard
Brett Cannon wrote: > Is anyone truly attached to nested tuple function parameters; ``def > fxn((a,b)): print a,b``? I find 54 instances in my Python installation. >grep -r "def.*([^=]*([^)]*,[^)]*).*):" * aifc.py:def setparams(self, (nchannels, sampwidth, framerate, nframes, comptype, compna

Re: [Python-Dev] removing nested tuple function parameters

2005-09-17 Thread Andrew Bennetts
On Sat, Sep 17, 2005 at 06:20:08PM -0700, Brett Cannon wrote: > Is anyone truly attached to nested tuple function parameters; ``def > fxn((a,b)): print a,b``? At one of the PyCon sprints Guido seemed > okay with just having them removed when Jeremy asked about ditching > them thanks to the pain th

[Python-Dev] removing nested tuple function parameters

2005-09-17 Thread Brett Cannon
Is anyone truly attached to nested tuple function parameters; ``def fxn((a,b)): print a,b``? At one of the PyCon sprints Guido seemed okay with just having them removed when Jeremy asked about ditching them thanks to the pain they caused in the AST branch. I personally don't see them being overly

[Python-Dev] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)

2005-09-17 Thread John J Lee
On Fri, 16 Sep 2005, "Martin v. Löwis" wrote: > Sokolov Yura wrote: > > I think I know how to remove GIL Obviously I am an idiot. > > Not an idiot, just lazy :-) Please try to implement your ideas, > and I predict that you will find: > 1. it is a lot of work to implement > 2. it requires chan

Re: [Python-Dev] Variant of removing GIL.

2005-09-17 Thread Luis P Caamano
On 9/17/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > Instead, the issue mainly died because nobody provided > working code (along with a strategy on what to do with > the existing extension modules). > When I first started writing python code I had just come out of about 6 years of ker

Re: [Python-Dev] os.path.diff(path1, path2)

2005-09-17 Thread John J Lee
On Fri, 16 Sep 2005, Greg Ewing wrote: > Trent Mick wrote: > > > If this *does* get added (I'm +0) then let's call it "relpath" or > > "relpathto" as in the various implementations out there: > > +1 on that, too. Preferably just "relpath". [...] +1 on adding this function, and on "relpath" as t

Re: [Python-Dev] Variant of removing GIL.

2005-09-17 Thread Luis P Caamano
On 9/17/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 12:32 PM 9/17/2005 -0400, Luis P Caamano wrote: > >My point is that not yielding speedups on multiprocessors > >and hurting performance on uniprocessors is not a good > >or valid reason to drop free-threading. > > It is No, it's not beca

Re: [Python-Dev] Variant of removing GIL.

2005-09-17 Thread Martin v. Löwis
Luis P Caamano wrote: > Mind you though, I'm not trying to oversimplify the issue. > I was not using python yet at that time (I started around > 1.5/1.6) and I didn't see all the info involved in the decision > making process, so I'm sure there were other issues that > contributed to the decision o

Re: [Python-Dev] Variant of removing GIL.

2005-09-17 Thread Phillip J. Eby
At 12:32 PM 9/17/2005 -0400, Luis P Caamano wrote: >My point is that not yielding speedups on multiprocessors >and hurting performance on uniprocessors is not a good >or valid reason to drop free-threading. It is if you have only volunteers to maintain the code base, and the changes significantly

Re: [Python-Dev] Variant of removing GIL.

2005-09-17 Thread Luis P Caamano
On 9/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Message: 9 > Date: Fri, 16 Sep 2005 21:07:23 -0500 > From: [EMAIL PROTECTED] > Subject: Re: [Python-Dev] Variant of removing GIL. > Message-ID: <[EMAIL PROTECTED]> > > > Martin> However, this is really hard to do correctly - if it