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