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
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
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
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
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
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
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
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
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
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
10 matches
Mail list logo
