Mailman 3 October 2004 - Python-Dev

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

29 Oct '04

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 for them to a version their old software can no longer read) -g

4 5

Re: weakref callback vs gc vs threads
by Neil Schemenauer 29 Oct '04

29 Oct '04

[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 of > _PyWeakref_ClearRef() was to ensure that the callback never > triggers. But it's okay of the callback triggers, as long as the callback doesn't reference trash. > > Now it just sets wr_object to Py_None. > > That won't stop the callback from triggering. It also means > (see earlier comment) that PyObject_ClearWeakRefs() will > never removed the weakref from the list either, although I'm > not sure that does real harm. I'm trying to figure out PyObject_ClearWeakRefs() right now. > > I also made some serious simplifications to gcmodule by > > just treating trash weakref objects with callbacks the same > > as objects with __del__ methods (i.e. move them to the > > finalizers list and then do the transitive closure of that set). > > Does that mean they can end up in gc.garbage too? If so, I > don't think that's sellable. I think so. That can be easily changed though. What we can't do is invoke those callbacks. Neil

3 6

RE: [Python-Dev] TRUNK UNFROZEN (release is done)
by Michael Chermside 29 Oct '04

29 Oct '04

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 29 Oct '04

29 Oct '04

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 29 Oct '04

29 Oct '04

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 socket." I agree that the documentation does not mention specifically that the length is encoded as four bytes, or that it is packed using struct.pack(), or exactly how you unpack it. I also agree that more examples would be helpful. I will endeavour to improve the situation insofar as time allows. Patches and specific suggestions from users, especially new users like you, will be a definite help to me. Best Regards, Vinay Sajip

2 1

Re: Pre-existing bug of the millennium (so far)
by Jim Fulton 29 Oct '04

29 Oct '04

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 callbacks and call them *after* all of the weakrefs have been cleared. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

3 3

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

28 Oct '04

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 email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.

5 6

IPv6 bug in 2.3.4??
by David G Mills 28 Oct '04

28 Oct '04

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 the error? Any help would be appreciated. Oh yeah, I'm running on FC2 on the 2.3.4 machine and redhat 8 on the 2.3.3 machine. Cheers, David.

3 5

logging needs better documentation
by Neal D. Becker 28 Oct '04

28 Oct '04

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 28 Oct '04

28 Oct '04

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, 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

21 47