Mailman 3 October 2004 - Python-Dev

Re: [Python-Dev] bsddb todo for someone - auto-upgrade db format
by Gregory P. Smith Oct. 29, 2004

Oct. 29, 2004

On Thu, Oct 21, 2004 at 12:49:19PM +0400, Oleg Broytmann wrote: > > BTW, just installing is not enough, even when it is come with Python > distribution. Installing a newer version of BerkeleyDB breaks older > databases due to incompatible file formats. fwiw its possible to fix this in the bsddb code. someone willing to do the exception catching database backing-up + auto db_upgrade() work should submit a patch. (i added backing-up as its rude to auto-convert someones database … [View More]

4 5

Re: weakref callback vs gc vs threads
by Neil Schemenauer Oct. 29, 2004

Oct. 29, 2004

[Taking this to email. Carrying out discussions via the SF bug tracker sucks.] Comment By: Tim Peters (tim_one) > [Neil] > > I had to change _PyWeakref_ClearRef() since it was also > > clearing the weakref list of the trash object. > > That was really its *purpose*. If a trash weakref with a > callback isn't removed from the referent's list of weakrefs, > then the callback will trigger when PyObject_ClearWeakRefs() > is invoked on the referent. The purpose … [View More]

3 6

RE: [Python-Dev] TRUNK UNFROZEN (release is done)
by Michael Chermside Oct. 29, 2004

Oct. 29, 2004

Johannes writes: > I finally decided to stop postponing doing this. I'll be running a bug day on > November 7. I'll be in our office with some coworkers: any Dutch Pythoneers are > welcome to join us for some 'real life' Python hacking! Just a thought: should we consider doing a "patch review day" someday instead of a bug day? At a time like this we might be dividing patches into categories like "apply for 2.4", "apply for 2.5", "reject", "needs work", and "contraversial". -- Michael Chermside

2 1

TRUNK UNFROZEN (release is done)
by Anthony Baxter Oct. 29, 2004

Oct. 29, 2004

The first beta is out, so the trunk is unfrozen, and available for checkins. Now that we're in beta, we shouldn't see any new features or behaviour changing fixes going into the trunk, unless it's been seen and agreed to on python-dev. I currently plan for a second beta in either 2 or 3 weeks, and then, assuming all goes well, a release candidate a couple of weeks after that. Anthony (apologies in the pause in getting the release email out - an unexpectedly hectic weekend popped up without notice)

10 21

RE: logging needs better documentation
by Vinay Sajip＠RedDove Oct. 29, 2004

Oct. 29, 2004

Hi Neal, I quite agree that the documentation for the logging package can be improved. As others have said in response to your post, you can definitely help by indicating more specifically where you find the documentation lacking, with a patch if possible. For example, your initial post about the length prefix for pickles is documented in the docstring for SocketHandler.makePickle(): "Pickles the record in binary format with a length prefix, and returns it ready for transmission across the … [View More]

2 1

Re: Pre-existing bug of the millennium (so far)
by Jim Fulton Oct. 29, 2004

Oct. 29, 2004

Tim Peters wrote: ... > Anyone have a bright idea? It's remarkable how long we've managed to go > without noticing that everything is disastrously broken here <0.9 wink>. Sure. Clearing cyclic trash can call Python code. If there are weakrefs to any of the cyclic trash, then those wekrefs can be used to resurrect the objects. Therefore, *before* clearing cyclic trash, we need to remove any weakrefs. If any of the weakrefs being removed have callbacks, then we need to save the … [View More]

3 3

RE: [Python-Dev] logging needs better documentation
by Chermside, Michael Oct. 28, 2004

Oct. 28, 2004

Neal Becker writes: > There is only a single example in the logging module documentation. Please > add more examples! You are completely right... I am sure that those docs need to be improved. Would you be willing to write up some improved docs? If so, submit them to the patch manager on SourceForge, and we'll incorporate them into the next release possible (probably Python 2.5). If not, then it may have to wait until someone else has time to address it. -- Michael Chermside This … [View More]

5 6

IPv6 bug in 2.3.4??
by David G Mills Oct. 28, 2004

Oct. 28, 2004

Hey there, I've noticed a potential bug and wanted to see if anyone else can replicate it, or has also seen it. When creating a socket with getaddrinfo, with the address family set to AF_UNSPEC and the host set to localhost, the socket binds to IPv4 instead of IPv6. When using the FQD of the machine it binds to IPv6. I've tested the same code on two different machines, and the one running python 2.3.3 works as it should, but the python 2.3.4 doesn't. Anyone seen this? Can you replicate … [View More]

3 5

logging needs better documentation
by Neal D. Becker Oct. 28, 2004

Oct. 28, 2004

There is only a single example in the logging module documentation. Please add more examples! I'm trying to use DatagramHandler. The documentation on this is not adequate. There is a confusing mention of makeLogRecord. No example. I finally stumbled across this: data, address = sock.recvfrom (8192) rec = logging.makeLogRecord (pickle.loads(data[4:])) I can't find _anywhere_ a mention that you need to leave off the first 4 bytes in order for unpickle to work.

2 1

SQLite module for Python 2.5
by Gerhard Haering Oct. 28, 2004

Oct. 28, 2004

Hi python-dev-elopers, Last December, we had a short thread discussing the integration of PySQLite into Python 2.4. At the time, I was against inclusion, because I thought PySQLite was not ripe for it, mostly because I thought the API was not stable. Now, I have started writing a new PySQLite module, which has the following key features: - Uses iterator-style SQLite 3.x API: sqlite3_compile, sqlite3_step() etc. This way, it is possible to use prepared statements, and for large resultsets,… [View More] it requires less memory, because the whole resultset isn't fetched into memory at once any longer. - Completely incompatible with the SQLite 0.x/1.x API: I'm free to create a much better API now. - "In the face of ambiguity, refuse the temptation to guess." - PySQLite 1.x tries to "guess" which Python type to convert to. It's pretty good at it, because it queries the column type information. This works for, I'd say 90 % of all cases at least. But as soon as you use anything fancy like functions, aggregates or expressions in SQL, the _typeless_ nature of SQLite breaks through and it will tell us nothing about the declared column type (of course, because the data is not coming from a database column). So I decided to change the default behaviour and make PySQLite typeless by default, too. Everything will be returned as a Unicode string (the default might be user-configurable per connection). Unless, unless of course the user explicitly activates the "guess-mode" ;-) But to do so, she must read the docs then she will be aware of the fact that it only works in 90 % of all cases. So why am I bothering you about this? I think that a simple embedded relational database would be a good thing to have in Python by default. And as Python 2.5 won't happen anytime soon, there's plenty of time for developing it, getting it stable, and integrating it. Especially those of you that have used PySQLite in the past, do you have any suggestions that would make the rewrite a better candidate for inclusion into Python? One problem I see is that even the new PySQLite will grow and try to wrap much of the SQLite API that are not directly related to the DB-API. If such a thing is too complicated/big for the standard library, then maybe it would be better to produce a much simpler PySQLite, especially for the Python standard library that leaves all the fancy stuff out. My codename would be "embsql". So, what would you like to see? "import sqlite", "import embsql", or "pypi.install('pysqlite')" ? -- Gerhard [View Less]

21 47