> Note that _only_ recursions will have more than 1 frame attached.
That's not true; in the presence of threads, the same method
may also be invoked more than one time simultaneously.
> But removing freelist altogether will not work well with any type of
> recursion.
How do you know that? Did yo
The freelist currently serves as a good optimization of a special case
of a recurring recursion. If the same code object (or one of the same
size) is used for recursive calls repeatedly, the freelist will
realloc-to-same-size (which probably has no serious cost) and thus the
cost of allocating/dea
> Should I make a patch?
-1. This could consume quite a lot of memory, and I doubt
that the speed improvement would be significant. Instead,
I would check whether performance could be improved by
just dropping the freelist. Looking at the code, I see
that it performs a realloc (!) of the frame obj
> Today I've stumbled upon a bug in my program that wasn't very
> straightforward to understand.
Unfortunately, it isn't straight-forward to understand your
description of it, either.
> The problem is that I was passing
> unicode filenames to zipfile.ZipFile.write and I had
> sys.setdefaultencod
On 6/10/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:23 AM 6/10/2007 +0300, Eyal Lotem wrote:
> >A. It will break code that uses instance.__dict__['var'] directly,
> >when 'var' exists as a property with a __set__ in the class. I believe
> >this is not significant.
> >B. It will simplify g
I must be missing something, as I really see no reason to keep the
existing semantics other than backwards compatibility (which can be
achieved by introducing a __fastattr__ or such).
Can you explain under which situations or find any example situation
where the existing semantics are desirable?
I was just looking through the code that handles frames (as part of my
current effort to determine how to improve on CPython's performance),
when I noticed the freelist/zombie mechanism for frame allocation
handling.
While the zombie mechanism seems like a nice optimization, I believe
there can be
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
ACTIVITY SUMMARY (06/03/07 - 06/10/07)
Tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1645 open ( +0) / 8584 closed ( +0) / 10229 total ( +0)
Average duration of open issues: 822 days.
Medi
At 12:23 AM 6/10/2007 +0300, Eyal Lotem wrote:
>A. It will break code that uses instance.__dict__['var'] directly,
>when 'var' exists as a property with a __set__ in the class. I believe
>this is not significant.
>B. It will simplify getattr's semantics. Python should _always_ give
>precedence to i
> On 6/10/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 6/9/07, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> > > I believe that this should be changed, so that Python first looks for
> > > the attribute in the instance's dict and only then through the dict's
> > > mro.
> >
> > Are you suggesting
On 6/9/07, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> I believe that this should be changed, so that Python first looks for
> the attribute in the instance's dict and only then through the dict's
> mro.
[snip]
> What do you think?
Are you suggesting that the following code should print "43" instead o
Hi.
I was surprised to find in my profiling that instance variable access
was pretty slow.
I looked through the CPython code involved, and discovered something
that really surprises me.
Python, probably through the valid assumption that most attribute
lookups go to the class, tries to look for t
Hi everyone,
Today I've stumbled upon a bug in my program that wasn't very
straightforward to understand. The problem is that I was passing
unicode filenames to zipfile.ZipFile.write and I had
sys.setdefaultencoding() in effect, which resulted in a situation
where most of the bytes generated in zi
> I am having a couple of issues compiling Python 2.5.1 under Sun Solaris
> Studio 11 on Solaris 8.
>
> Everything compiles correctly except the _ctypes module because it
> cannot use the libffi that comes with Python and it does not exist on
> the system.
>
> Has anyone gotten it to compile corr
Eyal Lotem schrieb:
> Hi. It seems that cProfile does not support throwing exceptions into
> generators properly, when an external timer routine is used.
>
> The problem is that _lsprof.c: ptrace_enter_call assumes that there
> are no exceptions set when it is called, which is not true when the
>
16 matches
Mail list logo
