On 2008-09-09 02:49, brett.cannon wrote:
> Author: brett.cannon
> Date: Tue Sep 9 02:49:16 2008
> New Revision: 66321
> warnings.catch_warnings() now returns a list or None instead of the custom
> WarningsRecorder object. This makes the API simpler to use as no special object
> must be learned.
> Closes issue 3781.
> Review by Benjamin Peterson.
This sounds a lot like a feature.
Why was it added just before RC1 ?
Professional Python Services directly from the Source (#1, Sep 09 2008)
>>> 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,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
I've always found it strange that Python Windows installers never
managed to add the python executable to the PATH environment variable.
Are there plans for adding such a thing?
Thanks in advance
I think this should be deferred to Py3.1.
This decision was not widely discussed and
I think it likely that some users will
be surprised and dismayed. The release
candidate seems to be the wrong time to
yank this out (in part because of the surprise
factor) and in part because I think the change
silently affects shelve performance so that the
impact may be significantly negative but not
We don't have to take this out. So why do
it hastily at the last minute and without some
discussion on comp.lang.python at least.
If it were any other release, we would have
disciplined ourselves to deprecate first and
remove a generation or two later.
Also, the reason for removal may yet disappear
if jcrea steps in an continues to make updates.
Also, the referenced note ( http://mail.python.org/pipermail/python-dev/2008-July/081379.html )
say to "start end-of-lifing it" which I took to mean deprecate rather than remove during a release candidate.
----- Original Message -----
From: "Benjamin Peterson" <report(a)bugs.python.org>
Sent: Wednesday, September 03, 2008 4:32 PM
Subject: [issue3769] Deprecate bsddb for removal in 3.0
> Benjamin Peterson <musiccomposition(a)gmail.com> added the comment:
> Also see this:
> Python tracker <report(a)bugs.python.org>
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/python%40rcn.com
libpython2.5.a contains quite a lot of .data that doesn't look like it
needs to be writable (my minimal interpreter binary has 105KB of
writable allocated data). A lot of these symbols look like they could
just be tagged const with no other changes to the interpreter; some of
them would require a proliferation of constness. I'm a bit new at this,
though, and it's possible that I'm wrong about some/most/all of these,
so I'm wondering what people think.
Attached is a patch which adds const to the easy ones:
* Docstrings for extension functions (PyDoc_VAR in Python.h)
* ascii->digit lookup table (_PyLong_DigitValue in longobject.c)
* The copyright notice (cprt in getcopyright.c)
There are no errors or new warnings introduced in my build by this
patch, but I'm only compiling the interpreter itself. If anyone can
suggest a reason why any of those shouldn't be const, please do :)
Things that take up space that might be const-able with more effort, or
might not, I can't tell:
* Token names (_PyParser_TokenNames in tokenizer.c)
* Module function tables (and ensuing propagation of constness into
* All the type and exception objects
Things that take up space but probably aren't const-able unless someone
who knows more than me has an idea:
* Standard slot definitions (slotdefs in typeobject.c, but the
interned string pointers get added at runtime)
* The generated tables for the grammar (but the accelerator seems to
want to change these at init time)
There's probably other things, but I didn't go through the entire symbol
table, just started with the big ones :)
So, er, is this a remotely sane thing to be doing, and does anyone have
With 2.6rc1 at the doors people are asking if xmlrpclib will be able
to communicate through a proxy? It causes bzr and bugzilla tools to
fail if used behind firewall, and there is no easy workaround for
In a checkout, site.py is currently responsible for adding the
distutils extension module builddir to sys.path. Usually, this is
unproblematic. However, when the initialization code needed by site
(in this case the standard io streams and the builtin open) relies on
C modules added from the builddir in site.py, it causes silent errors.
The calls to initstdio and initsite were moved to having the site
initialization first in r62778, so that _bytesio and _stringio could
be used when io was loaded. Unfortunately, site.py uses open, but this
error went undetected because stderr was not set up yet. (See issue
That options as I see it are:
1. Switch the initialization order back to the original (io streams
first) and compile _bytesio and _stringio directly into the Python
binary. This is probably the easiest option.
2. Switch the initialization order back to the original and have
getpath.c put the builddir on sys.path. This might be difficult
because finding the distutils buildir seems to involve
disutils.utils.get_platform(). (I'm not a disutils expert; can the
location of the builddir be simplified?)
Anyway, note that this doesn't affect Python which has been installed
on a system because the dynlibs are already on sys.path.
"There's no place like 127.0.0.1."
Here's an interesting blog post comparing Python performance of various versions
from 2.2.3 upto the latest 3.0 beta.
The fact that only Mandelbrot calculation (a hardly representative benchmark for
a high-level dynamic language such as Python) has become significantly slower is
rather a good sign IMO.