Anthony Baxter wrote:
> My only concern about this is that it wouldn't be possible for other
> authors to provide 3rd party packages as (for instance) db.mysqldb
> because of the way package importing works. And I'd prefer
> 'database.sqlite' rather than 'db.sqlite'.
On behalf of the Python development team and the Python community,
I'm happy to announce the release of Python 2.4.3 (final).
Python 2.4.3 is a bug-fix release. See the release notes at the
website (also available as Misc/NEWS in the source distribution)
for details of the more than 50 bugs squished in this release,
including a number found by the Coverity Scan project.
Assuming no major bugs pop up, the next release of Python will
be Python 2.5 (alpha 1), with a final 2.4.4 release of Python
shortly after the final version of Python 2.5. The release plan
for Python 2.5 is documented in PEP-0356.
For more information on Python 2.4.3, including download links for
various platforms, release notes, and known issues, please see:
Highlights of this new release include:
- Bug fixes. According to the release notes, at least 50
have been fixed.
- A small number of bugs, regressions and reference leaks
have been fixed since Python 2.4.3 release candidate 1.
See NEWS.txt for more.
Highlights of the previous major Python release (2.4) are
available from the Python 2.4 page, at
Enjoy this new release,
Python Release Manager
(on behalf of the entire python-dev team)
Martin v. Löwis wrote:
> Guido van Rossum wrote:
> > Unless you've recanted on that already, let me point out that I've
> > never seen sqlite, and I've ignored this thread, so I don't
> know what
> > the disagreement is all about. Perhaps one person in favor and one
> > person against could summarize the argument for me? Otherwise I'll
> > have to go with "no" just to err on the side of safety. I
> have strong
> > feelings about the language. Sometimes I have strong feelings about
> > the library. This doesn't seem to be one of those cases though...
> Let me try to take both sides simultaneously:
> For: would add an SQL library to the standard distribution, and one
> that doesn't depend on additional infrastructure on the target machine
> (such as an existing database server); the author of that library is
> fine with including it in Python
> Against: Adds work-load on the release process, adding more libraries
> to the already-large list of new libraries for 2.5. Choice of naming
> things is ad-hoc, but gets cast in stone by the release; likewise,
> choice of specific SQL library might inhibit addition of different
> libraries later.
Explaining "database is locked" errors (due to SQLite's exposed multiple-readers/one-writer design) on a daily basis (FAQ entries notwithstanding).
since I found myself writing "if __name__ == '__main__'"
often these days, I wondered whether PEP 299 could be pronounced
upon. I'm not proposing putting it into 2.5, but it should be
relatively small a change.
Nick Coghlan wrote:
> There are three big use cases:
> Currently these all return lists, which may be expensive in
> terms of copying. They all have iter* variants which while
> memory efficient, are far less convenient to work with.
I'm still wondering what "far less convenient" means. Is it simply the 4
extra key presses? I find the iter* variants to be a great solution.
Gerhard Häring writes:
> db.sql.sqlite is another possibility, if adding something like Durus or
> ZODB in the same top-level namespace could be considered for 2.6.
Flat is better than nested. I see no reason why we couldn't have all of
there's no need to group the SQL databases.
-- Michael Chermside
>> Thank would be nice. It gives me the ability to keep a clean, sane API while
>> the same time making sure that my most important customer (Barry) gets his
> I'm having a hard time deciphering whether you're being condescending or
> trying to be funny. I'm going to go with the latter. Good one! :)
Neither. I was serious. You are a principal customer for setobjects.
It seems that you make extensive use of them in your code.
While I don't favor the proposed API, I think is essential that
you not be left hanging without good options.
On 3/27/06, Raymond Hettinger <raymond.hettinger(a)verizon.net> wrote:
> > Modified:
> > python/trunk/Modules/itertoolsmodule.c
> > Log:
> > Make itertools.tee and its internal teedataobject participate in GC.
> > alone does not solve the leak in test_generators, unfortunately, but it
> > part of test_generators' problem and it does solve other cycles.
> Thanks for getting this in.
> To get the leak in test_generators, I think you make need to add GC to the
> teeobject as well as the teedataobject.
The teeobject has GC (hence the word 'and' in 'itertools.tee and its
internal teedataobject' ;-) The problem with test_generators is that this
g = gen()
It doesn't leak in 2.4. I'm using a little shell script to work backwards
through the 2.5 changes to find out which one introduced this, although I
somehow suspect it's the coroutine stuff... ;P
Thomas Wouters <thomas(a)python.org>
Hi! I'm a .signature virus! copy me into your .signature file to help me
Wupsie, this was meant for all of python-dev ;P
---------- Forwarded message ----------
From: Thomas Wouters <thomas(a)python.org>
Date: Mar 29, 2006 1:34 AM
Subject: Re: [Python-Dev] [Python-checkins] r43358 -
To: Tim Peters <tim.peters(a)gmail.com>
On 3/29/06, Tim Peters <tim.peters(a)gmail.com> wrote:
> ... that throws cycle-gc in a hissy fit;
If by "hissy fit" you mean "gcmodule properly moves generators to the
list of objects with finalizers, thereby preventing catastrophes",
right, that's an intended hissy fit ;-)
Well, I meant 'the durned thing refuses to do what I want it to do', which
is clear cycles. I guess the hissy fit was mine ;)
Did the best I could above, short of explaining exactly how failing to
> identify an object with a finalizer can lead to disaster.
Short course: gc obviously needs to know which objects are and are not
> trash. If a finalizer is associated with an object in cyclic trash,
> then trash objects are potentially visible _from_ the finalizer, and
> therefore can be resurrected by running the finalizer. gc must
> therefore identify all trash objects reachable from trash objects with
> finalizers, because running finalizers _may_ make all such objects
> "not trash" again. Getting any part of that wrong can lead to calling
> tp_clear on an object that a finalizer actually resurrects, leading to
> symptoms from "hey, all the attributes on my object suddenly vanished
> by magic, for no reason at all" to segfaults.
So does that make all cycles involving only objects with finalizers
impervious to cycle-gc? I guess it'd have to be that way. That also means I
can stop searching for leaks in the C code, as we'll never be able to fix
them all, anyway (although 'good code' could manually break many of the
cycles.) At least not while keeping the tp_del of generator objects, not to
mention avoiding finalizers on other builtin objects. (None seem to have
them at the moment, they all do their stuff in tp_dealloc, which I guess
doesn't allow objects to reincarnate themselves.)
I'll see about fixing the Python code to avoid or explicitly break the
cycles. Maybe we can patch regrtest.py to take into account uncollectable
cycles, so that it could report them separately from refleaks. I'm going to
think about all this first, though.
Thomas Wouters <thomas(a)python.org>
Hi! I'm a finalizer virus! copy me into your tp_del slot to help me spread!