I am considering producing a Python 2.3.6 release, which would of
course only be a bug fix maintenance release. The primary reason is
that not all OS distributions have upgraded to Python 2.4 and I think
it's worthwhile for us to bless a release that fixes known critical
bugs. I'm willing to be the release manager for 2.3.6, but I'm
hoping you all will be able to help identify the most important bugs
that need fixing.
First, is there interest in getting a 2.3.6 release out? I'd propose
keeping things simple, by picking a date and releasing what we've got
at that date (assuming of course all the unit tests pass). It's
probably a good idea to add a wiki page tracking the fixes we want to
get in there.
2.5 final is slated for 12-Sep-2006 and I know that Anthony is
planning for a 2.4.4 soon after that. I'm thinking that we'd try to
do a 2.3.6 a couple of weeks after 2.4.4 so that people who care
about it aren't stacked up with fixing too many branches at once. My
first thought was to shoot for Monday October 9th.
What are the potential 2.3.6 fixes? Nothing on this page:
seems critical to me. I know that I've added some important email
package fixes that are already in Subversion. There are tons of bugs
and patches reported against 2.3 in SF (lament: why won't SF just /
tell/ me how many there are?), but I have no idea atm which, if any,
are important enough to go into a 2.3.6. I haven't yet done an svn
diff to see what changes are already in there.
I don't have the cycles to fix things myself, so it would be up to
everyone to help commit fixes. I'll ride herd a bit if necessary.
Thoughts? I don't want to waste my time if nobody thinks a 2.3.6
would be useful, but I'm happy to do it if there's community
support. I'll also need the usual help with Windows installers and
After various people suggesting object-capabilities, takling with Mark S.
Miller of the E programming language, and the people Mark works with at HP
Labs (who have been giving talks every week during this month here at Google
on object-capabilities), I have decided to go with object-capabilities for
securing interpreters. I have rewritten my design doc from scratch and
deleted the old one. The new doc is named securing_python.txt and can be
found through the svn web interface at
I have pretty much ignored any concrete API and such and gone more
conceptual doc to make sure the API does not get in the way of the core
Using object-capabilities should make the implementation much cleaner.
There is much less work directly on the interpreter and more of it gets
pushed up to extension modules. I also have the okay of my supervisor to
use this approach in my dissertation so this will get done.
Two things do fall out of all of this which will make development much more
modular and easier. First, the memory cap work just becomes a special build
on its own; no need to tie into the security work. So I will be cleaning up
the bcannon-sandboxing branch code as it stands, and then either create a
separate branch for the object-capabilities work, or create another branch
for the memory cap stuff and shift the changes over there. I will most
likely do the former so as to not lose the history on the checkins.
I also plan to rewrite the import machinery in pure Python. This will make
the code much more maintainable and make creating proxies for the import
machinery much easier. I will be doing that in a directory in the sandbox
initially since it needs to work from what Python has now (and possibly some
new extension module code) before it can be integrated into the interpreter
directly. Anyone who wants to help with that can. I already have some
perliminary notes on the whole thing and I think it will be reasonably
Anyway, there you go. Here is to hoping I have thought this all through
I discovered that gcc 4.2 exposes a flaw with
signed integer overflows in python. This bug and the
necessary fix has been discussed in detail on the gcc
mailing list. I have filed a detailed bug report and
the recommended patch proposed by the gcc developers.
This problem should be addressed BEFORE python 2.5 is
released. The bug report is...
[ 1545668 ] gcc trunk (4.2) exposes a signed integer overflows
in the python sourceforge bug tracker. Thanks in advance
for attempting to fix this before Python 2.5 is released.
I tried building python 2.5c1 using VC8.
Getting the following errors while building pythoncore_pgo:
Creating library pythoncore_pgo/python25.lib and object
config.obj : error LNK2001: unresolved external symbol _init_types
.\pythoncore_pgo/python25.dll : fatal error LNK1120: 1 unresolved externals
I checked pythoncore_pgo.vcproj file, it alreadu contains:
Can anyone give me some clue to solve this issue.
Thanks & Regards,
I would like to see the changes to the decimal module reverted for the
Currently, the code in the decimal module implements the context manager
as a separate class instead of incorporating it directly in
decimal.Context. This makes the API unnecessarily complex and is not
pretty compared to the code it was intended to replace.
Worse still, the implementation saves a reference to the context instead
of making a copy of it. Remember decimal.Context objects are mutable --
the current implementation does not fulfill its contract to restore the
context to its original state at the conclusion of the with-statement.
The right way to do it was presented in PEP343. The implementation was
correct and the API was simple.
* The examples in WhatsNew don't work because the implementation uses a
different method name to fetch to context (this is a shallow error
except that the name in WhatsNew is better and we don't really want to
have a new method for this). It doesn't bode well that none of the
release candidate end users noticed this discrepancy -- it means they
are not trying out the examples.
* The implementation's doc string examples were not tested and don't
work (this is a deep error). One reads:
with decimal.getcontext() as ctx:
ctx.prec += 2
s = ...
To get this to work with the current implementation, it should read
with decimal.getcontext().copy().get_manager() as ctx:
ctx.prec += 2
s = ...
This is horrid. Please either revert the patch or fix it to match PEP-343.
There was a buildbot set up recently to test various external packages
(like twisted) against Python's source code. I don't recall where it is,
but it would be nice if relevant links to it existed on this page:
In addition, if a 2.3.6 release is going to happen it seems like it would be
a good idea to set up the relevant bits on both buildbots.
The Windows build slave ("x86 XP trunk") will be down for most of
today while I move to a new apartment. As long as the phone company
manages to provide me with an internet connection by the end of today,
it should be available again some time this evening.
I see. There is a file, called pythoncore_pgo_link.txt where you have to add the object too.
But pythoncore_pgo is a bit broken in other ways at the moment. I am working on making it better in the trunk.
(I also think that MS should improve their tools to make PGO building a one step process. the current
recommended solution involves two project configurations...)
From: python-dev-bounces+kristjan=ccpgames.com(a)python.org [mailto:firstname.lastname@example.org] On Behalf Of Muguntharaj Subramanian
Sent: 31. ágúst 2006 11:46
To: Fredrik Lundh
Subject: Re: [Python-Dev] Error while building 2.5rc1 pythoncore_pgo on VC8
> I checked pythoncore_pgo.vcproj file, it alreadu contains:
> Can anyone give me some clue to solve this issue.
googling for error messages is always a good idea:
(see the last post in that thread for what I believe is a workaround)
Yes, I have already done a bit of searching before posting that message.
I have seen that previous post.
That error mentioned in that post was in "pythoncore" module.
My error is while compiling "pythoncore_pgo" module.
And the workaround solution mentioned there is already there in the pythoncore_pgo.vcproj file. Thats why i mentioned RelativePath="..\Modules\
_typesmodule.c" is already there.
I am still getting the same error. I am not able to find the cause yet. Any clue regarding this.
Thanks & Regards,
I am working on updating the PCBuild8 directory in the trunk. This should fix this issue, unify platform builds for win32, x64 and I64, and provide better support for PGO builds.
Hopefully when this is checked in, I can backport it to 2.5, since PCBuild8 is not an "official" platform for 2.5
> -----Original Message-----
> From: python-dev-bounces+kristjan=ccpgames.com(a)python.org
> On Behalf Of Fredrik Lundh
> Sent: 31. ágúst 2006 10:55
> To: python-dev(a)python.org
> Subject: Re: [Python-Dev] Error while building 2.5rc1
> pythoncore_pgo on VC8
> Muguntharaj Subramanian wrote:
> > Hi All,
> > I tried building python 2.5c1 using VC8.
> > Getting the following errors while building pythoncore_pgo:
> > Creating library pythoncore_pgo/python25.lib and object
> > pythoncore_pgo/python25.exp config.obj : error LNK2001: unresolved
> > external symbol _init_types .\pythoncore_pgo/python25.dll : fatal
> > error LNK1120: 1 unresolved externals
> > I checked pythoncore_pgo.vcproj file, it alreadu contains:
> > RelativePath="..\Modules\_typesmodule.c"
> > Can anyone give me some clue to solve this issue.
> googling for error messages is always a good idea:
> (see the last post in that thread for what I believe is a workaround)
> Python-Dev mailing list