Brett C. wrote:
> I have been mulling over this proposal and I think I am finally
> settling on +0 as long as it can be shown that it does not hurt
> performance at all (yes, it shouldn't but this is the eval loop we are
> talking about and that thing is a touchy beast).
Is there a standard benchmark I could use to demonstrate the
impact of the two new additions on the runtime?
This one is a puzzler. See
for details. The short course is that the PyThreadState_SetAsyncExc()
implementation fell into a common trap, and can cause segfaults under
rare conditions (like every other Python thread segfault bug we've
This is easily repaired (although I've got no interest in doing the
coding, or even in contriving a test case -- this was an obvious "by
The puzzle is how to treat this wrt 2.4. Since it's a critical bug, I
suppose it "should" force another release candidate. OTOH, this is a
C-only API (there's no exposure from Python) that's never used in the
core. We could add code to make it segfault every time <wink>, and
nothing in the distribution would notice.
OTOH, if we broke its intended behavior while fixing the bug, we'd
never know that either. "Never used in the core" means never -- the
function isn't tested.
On the third hand, it's a simple function with an obvious segfault
mode that has an obvious fix.
I'll leave it to the release manager <wink>.
At 02:24 PM 11/17/04 +0200, Stelios Xanthakis wrote:
> #!/usr/bin/python -P
> def save_world():
> F = open ('MYSYSTEM.py')
> F.write ('#!/usr/bin/python -P\n')
> for i in globals():
> if hasattr (eval(a), '__pycode__'):
> F.write (eval(a).__pycode__)
There are bugs in this code. First, the wrong variable is used for eval(),
and second, it shouldn't use eval. If there's a global named 'F', for
example, the code above will not save it, because it will see the local 'F'
instead. Loop over globals().values(), and do not use eval.
>The __pycode__ attribute is not marshaled.
>The logic behind this is that if we edit a function/class
>and save it in a .pyc file, the next time the .py module
>is executed it will overwrite the .pyc file and our changes
>So for 'import'ed code, __pycode__=None
What good is that? Likewise, I don't see the point of having this only
enabled when a command-line option is given.
If the idea is just to allow saving code from interactive mode, why not
just modify the interactive mode to do this?
At 06:49 AM 11/18/04 +0200, Stelios Xanthakis wrote:
>On Wed, 17 Nov 2004, Phillip J. Eby wrote:
>>What good is that? Likewise, I don't see the point of having this only
>>enabled when a command-line option is given.
>We can marshal it if we want.
>But I'm not convinced we should.
Apparently, we have different use cases for the source code. In my use
cases, I have little use for the interactive mode or exec. For example, in
the exec case, I would already have the source code, so why would I need it
I think it's important to clarify what this is *for*, and then address
whatever that use case is directly. So far, lots of people are projecting
their own use cases onto it, and therefore we all disagree on what the best
way to implement it is.
> Having used this system,
>'import' is a good barrier to say "I'm not interested for
>the __pycode__ of these".
Having used it for whatever purposes *you're* using it for. Evidently you
want to use it for something very different from what I would want it for
(source code transforms, such as AOP "advice" injection).
A while back, Tim added a comment that PyRange_New() should be
deprecated in-part because it is filled with problems and is not used
anywhere in the core.
Doesn't anyone mind if I mark it in the C-API docs as deprecated so it
can be phased out later?
"Martin v. Löwis" wrote:
> Sent: Wednesday, November 17, 2004 12:31 PM
> To: Robert Brewer
> Cc: python-dev(a)python.org
> Subject: Re: [Python-Dev] os.access versus os.exist
> Robert Brewer wrote:
> > Completely understood about LocalSystem. But IMO, os.stat should
> > raise a more specific and correct error. As you pointed out, calling
> > open() raises "IOError: [Errno 13] Permission denied"; it would be
> > nice if stat did the same (in my example). The platform-specific API
> > call (for example, Windows _stati64) doesn't provide this--it would
> > require another test inside posix_do_stat to return a more
> > appropriate error. But it would be a nice touch for us end-users.
> No. Python faking up errors that the platform doesn't provide is evil.
> You are entitled to precisely the error that the platform reported.
> Now, MSVC stat() is severely constraint, in several ways (e.g. it
> doesn't support sub-second time-stamps, either), so rewriting stat
> with plain Win32 API might be reasonable, at which point giving
> more precise error would be an option.
> > In my opinion, "no such file" is the wrong error message and is
> > therefore a bug. But I can accept others disagreeing, since
> > simply wraps Windows' _stat* calls (at least, in my example).
> It sure looks like a bug - but one of msvcrt.dll.
OK. I'll file a small doc patch for os.path.exists, then, I think. Thanks!
something in the regression suite is generating a temporary
file with content:
exec /path/to/python -c 'import sys; sys.exit(47)'
and not cleaning up after itself.
This started around Oct. 13. Looking at the regression suite
test_subprocess.py seems to be the cause.
BTW, wouldn't sys.exit(42) be more appropriate :-?
Professional Python Services directly from the Source (#1, Nov 17 2004)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
Martin v. Löwis wrote:
> Robert Brewer wrote:
> > Inside the app (running under LocalSystem on the same Win2k
> > os.stat() raises OSError: [Errno 2] No such file or directory,
> > os.path.exists() returns False, and
> > os.access() returns False.
> LocalSystem cannot access network shares. However, this is OT for
Completely understood about LocalSystem. But IMO, os.stat should raise a more specific and correct error. As you pointed out, calling open() raises "IOError: [Errno 13] Permission denied"; it would be nice if stat did the same (in my example). The platform-specific API call (for example, Windows _stati64) doesn't provide this--it would require another test inside posix_do_stat to return a more appropriate error. But it would be a nice touch for us end-users.
In my opinion, "no such file" is the wrong error message and is therefore a bug. But I can accept others disagreeing, since os.stat() simply wraps Windows' _stat* calls (at least, in my example).
Nick Coghlan wrote:
> Ralf W. Grosse-Kunstleve wrote:
> > >Knowing "I'm spending x% of the time executing Python code" just isn't
> > >really all that interesting,
> > Right. Sorry if I gave the wrong impression that this could be
> > interesting. It is indeed not. What is interesting is the estimated
> > benefit of reimplementing a piece of Python in C/C++. This is in
> > fact highly correlated with the time/tick.
> Ah, OK, I think I better understand what you're trying to achieve now.
> Does knowing that the 2.4 profiler splits out C invocations from the
> calling Python methods make a difference here?
Yes, this is a very helpful improvement. Thanks for pointing this
out! It gives us a more direct way of pin-pointing the time sinks.
However, I see time.time()/sys.gettickeraccumulation() as a
complementary source of information:
factor 8 runtime penalty
very detailed information
no runtime penalty
As we work on new algorithms we can easily monitor the time/tick
without a runtime penalty. As long as the ratio stays reasonably high
(e.g. because we use numarray-like array operations already coded in
C++) we don't have to do anything. If the ratio goes down significantly
we can run the profiler to do detailed analysis of the new code.