While this is going to require a PEP (which I am willing to write),
the discussion of adding pysqlite has brought forth some discussion on
naming and packaging in the stdlub. Perhaps it's time to start
discussing the Great Library Reorganization that has been discussed
Here is a place I think we can take a queue from Java. I think we
should have a root package, 'py', and then have subpackages within
that. Those subpackages would group the existing modules that are not
already in a nice package hierarchy. In other words, try to make it
so that importing an actual module takes no more than three dots in
the general case: ``from py.dev import pdb``, etc.
I do think it is okay to put things without proper classification just
under 'py' without being in a subpackage. The three dots idea is not
hard. We could, for instance, have a py.dist subpackage and have
pkgutil and distutils under it. That will make the modules in
distutils take four dots, but that's just life and I think within
reason for something that is not used directly by a large number of
I also have no issue taking certain names from existing modules and
making them both a module directly (as in putting what exists in a
module into __init__.py for the subpackage with the same name) on top
of putting more modules in the subpackage. The issue I see with this,
though, is people doing something like ``from py import pickle;
pickle.pickletools.dis()``, not realizing they need to import
pickletools directly instead of getting to it through py.pickle .
I don't want to spark a subpackage grouping discussion yet since we
should decide on a general strategy of how we want the basic stdlib
organized. I also don't want to argue over module renaming directly
since that can be based on what subpackages there might be.
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