On Sat, Jun 21, 2008 at 11:20 AM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> In general, any solution of the "do GC less often" needs to deal with
> cases where lots of garbage gets produced in a short amount of time
> (e.g. in a tight loop), and which run out of memory when GC is done less
>
On Sat, Jun 21, 2008 at 4:33 AM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > I don't think expecting people to tweak gc parameters when they witness
> > performance problems is reasonable.
>
> What follows from that? To me, the natural conclusion is "people who
> witness performance problems
On Fri, Jun 20, 2008 at 10:25 AM, Antoine Pitrou <[EMAIL PROTECTED]>
wrote:
>
> Kevin Jacobs bioinformed.com> gmail.com>
> writes:
> >
> > +1 on a C API for enabling and disabling GC. I have several instances
> where
> I create a large number of objects non-cyclic objects where I see huge GC
>
+1 on a C API for enabling and disabling GC.
I have several instances where I create a large number of objects non-cyclic
objects where I see huge GC overhead (30+ seconds with gc enabled, 0.15
seconds when disabled).
+1000 to fixing the garbage collector to be smart enough to self-regulate
itsel
On Jan 15, 2008 6:24 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 14, 2008 at 11:41:47PM +, Jon Ribbens wrote:
> > It makes sense, but personally I have never heard before of ~/.local.
> > Whereas ~/bin is something I am quite familiar with.
>
> Me too. python-dev is the only
On Dec 6, 2007 1:35 AM, Neil Toronto <[EMAIL PROTECTED]> wrote:
> So I've applied Armin's patch to 2.6 (it was nearly clean) and am
> playing with it. cls.name lookups are 15-20% faster than mine, and
> inst.name lookups are 5-10% faster. His is also winning on hasattr calls
> (succeeding and fail
On Dec 5, 2007 5:50 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:48 PM 12/5/2007 +0100, Georg Brandl wrote:
> >Neil Toronto schrieb:
> > > So Jim and PJE finally convinced me to do it the right way. :) Thanks
> > > guys - it turned out very nice.
> >
> >How does this relate to Armin Rigo'
Just to chime in from the other side of the coin.
I'm actively trying to hire qualified scientific programmers with strong
Python experience. Unfortunately, I've had little success finding
candidates with actual Python knowledge, resorting mainly to hiring those
who've seen it and can readily lea
On 9/22/07, Bruce Frederiksen <[EMAIL PROTECTED]> wrote:
>
> I've added a new function to itertools called 'concat'. This function is
> much like *chain*, but takes all of the iterables as a single argument.
>
I've needed this once or twice, though my implementation was called
'starchain', in li
On 8/3/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> 2007/8/3, Andrew Bennetts <[EMAIL PROTECTED]>:
>
> > I don't really think there's much reason to make "iter()" work. As you
> say,
>
> What bad thing could happen if we make iter() work? If nothing, we
> should ask ourselves: which is the m
On 7/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Ahem. I hope you have a better use case for getitem() than that
(regardless of the default issue). I find it clearer to write that as
try:
compid = root[ns.company_id].next()
except StopIteration:
compid = None
else:
compid = int(comp
I agree with Phillip with regard to the semantics. They are semantically
desirable. However, there is a patch to add a mro cache to speed up these
sorts of cases on the Python tracker, originally submitted by Armin Rigo.
He saw ~20% speedups, others see less. It is currently just sitting there
I've tested the patch and it works as advertised for me.
On 4/23/07, Florian Festi <[EMAIL PROTECTED]> wrote:
Hi!
I posted patch 1675951 a while ago that fixes a performance problem for
small reads in the gzip stdlib module. It also removes the necessity for
seeking while reading gzip files (a
On 4/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 4/7/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 4/7/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > Here's a patch implementing collections.counts() as suggested above:
>
> The name doesn't make it obvious to me what's going on. May
On 7/21/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Brett> Sure. It can also wait until we begin discussing the transitionBrett> to our next bug tracker.Would be kinda nice if the new bug tracker allowed submitters to enter afollowup email address without formally logging in. (Of cou
That'll teach me to fire off emails while running out the door. Thanks.-KevinOn 7/21/06, John Benediktsson <
[EMAIL PROTECTED]> wrote:> The is _active check, unless it intendeds to check for either empty or
> None, should probably be revised to:>> def __del__(self):> # In case the chi
On 7/21/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Delaney, Timothy (Tim) wrote:> Looks like there's a bug in Popen.__del__ in 2.5. I'm not in a position> to have a look right now.For those not watching python-checkins, a check for "is not None" has been
added before the offending line in Popen.__
Reported to the list about a week ago, with analysis. Didn't get a response. Won't use sourceforge. Sorry about the top post.-KevinOn 7/20/06, Delaney, Timothy (Tim)
<[EMAIL PROTECTED]> wrote:Larry Hastings wrote:
> I run the following script:> --> from subprocess import *> Popen("ls -l")> -->
During my testing of Python 2.5b2, I've found something that may be worthy of discussion. I suspect that recent GC and finalization changes have altered the behavior of the Popen object in subprocess.py. I am now getting many many many finalization warnings in my code like:
Exception exceptions.A
On 7/6/06, Evan Simpson <[EMAIL PROTECTED]> wrote:
Talin wrote:> I propose to create a new type of scoping rule, which I will call> "explicit" lexical scoping, that will co-exist with the current> "implicit" scoping rule that exists in Python today.
I'd like to toss one more variant into the mix.
On 6/23/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:>> > >Unfortunately, that doesn't help, because it is not where the issues> > >are. What I don't know is how much you know about numerical models,
> > >IEEE 754 in particular, and C99. You weren't active on the SC22WG14>
On 6/22/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> > Not a lot. Annex F in itself is only numerically insane. You need to> > know the rest of the standard, including that which is documented only> > in SC22WG14 messages, to realise the full horror.
[...]>Unfortunately, that doesn't help, beca
On 6/11/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Kevin Jacobs <[EMAIL PROTECTED]> wrote:> Try this at home:> import collections> d=collections.defaultdict(int)> d.iterkeys().next() # Seg fault
> d.iteritems().next() # Seg fault> d.itervalues().next() # Fine and da
An aside before I report this bug:_I_HATE_SOURCEFORGE_. If it doesn't bloody accept anonymous bug reports then it bloody well shouldn't let you type in a nice, detailed, well through-out report and then toss it in the toilet when you hit Submit, and also not allow one dive in after it by using the
24 matches
Mail list logo