Gregory P. Smith wrote:

Of particular interest to bsddb is the pep3118 buffer API. I updated the existing bsddb module found in the py3k branch to use it last fall; you may want to use the changes made to it as an example.

I agree, a single C code base is the only sane way forward for bsddb. The interesting part is that you also want to support older python versions (2.3-2.5?) as well so _bsddb.c & bsddb.h become a nice example of how to write code that spans multiple python versions.

I expect it is less difficult than it sounds.

I would say so. Most things can be done with preprocessor conditionals and some redefinitions, e.g. "#define PyLong_Type PyInt_Type", etc. The method "generate_module_preamble()" in Cython's ModuleNode.py source file (from line 360 onwards) has a code block of things we found so far. http://hg.cython.org/cython-devel/file/tip/Cython/Compiler/ModuleNode.py

I believe the buffer api is supposed to be backported to 2.6? I haven't followed the status of that. If so, bsddb should use it in 2.6 as well.

The API is there (in addition to the old buffer API), but it doesn't seem to get used. Stefan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote: | On Sun, May 25, 2008 at 6:25 AM, Jesus Cea <jcea@jcea.es> wrote: |> Since I need to port bsddb3 to py3k, what I need to know?. Is any |> *updated* document out there?. | | No, but there is a not yet complete, but quite updated set of examples. | | http://code.google.com/p/python-incompatibility/ | | This is a collection of code snippets that will show code that does | work under 2.x but not under 3.x, and the 3.x way of doing it (as well | as a way that works under both 2.6 and 3.0, in applicable cases). | | There is no tests for changes in the C-API, if you (or somebody else) | would like to add that (or any other tests) that would be very | appreciated! I can't checkout the code. What username/password must I use?. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSIFQnZlgi5GaxT1NAQL3LQP/ZxblxpJwZAQ9qIUXHAZpFlmK86y7UPfT DX707wR1YMOujiNazE2NuJSVCVkbbOlc1G2dxTAqDm7FAThkjuIeO74ijueUeFdN p6LP2dS5pHH8h8G9bUfDynGCjRQ4t1TUblksQgPDtrYiXlzIBqYL1qkHRf72w2c3 fyuZWBpaH0w= =nnN4 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Scott wrote: | See http://code.google.com/p/python-incompatibility/source/checkout Thanks. I'm *VERY* interested in 2.6->3.0 migration guide for C module extensions. 3.0 is around the corner and the API is changing almost daily :-p. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSIRRpZlgi5GaxT1NAQLUlwP9GDwp2zKFfHQWmRnhOyGfTwa0GqWGW1rZ IrHrPXgFweh1mnbhGIjVkvlMJxHnhP2yGKStkN4641zYJ5KgdRJBaIdfrqoOkPTb xzzHJ7DqaAGmRSKRoCZ8jzjCuC4BKeuLalii3V7ofYBimDgsHL42lb0MWxZBVNK5 SnafyX+rqGU= =re/E -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Georg Brandl wrote: | So it's good that nobody has written a migration guide yet; he'd have | to rewrite it daily. Yes. I was delaying battling the 3.0 bsddb migration until RC to avoid redoing the same work 15 times XDDDDDDDDDD I'm not lazy, but it is so sunny outside... - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSIRYHplgi5GaxT1NAQL4hwP+LUSeAZxP/6q2K8GBs9ptqMnZUPh6ct0j mhJqnAGDrI3XgcyHa3DeWwAltIfbLj9KC+UcgBNSvVQvqqMaPxKhc+tsbXqmsude +o2e9IhZCgWg91FyJv64LPJr/tgMG4g7QBxHR1G9GF76YYrjCQCzi1f06lNkplQh o/KIbRBmwRc= =Q6o6 -----END PGP SIGNATURE-----

On Mon, Jul 21, 2008 at 1:16 PM, Brett Cannon <brett@python.org> wrote:

On Mon, Jul 21, 2008 at 2:34 AM, Jesus Cea <jcea@jcea.es> wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Georg Brandl wrote: | So it's good that nobody has written a migration guide yet; he'd have | to rewrite it daily.

Yes. I was delaying battling the 3.0 bsddb migration until RC to avoid redoing the same work 15 times XDDDDDDDDDD

But waiting until all the betas have gone out totally defeats the purpose of the betas! It has already been stated that new code changes that are even remotely shaky or anything not small needs a code review at this point since we only have one beta left. Barry can correct me if I am wrong, but dropping a major rewrite of bsddb into 3.0 between b3 and rc1 is not acceptable. I wouldn't be surprised if all code after b3 requires a code review since at that point we should just be squashing bugs, not rewriting code. And if you are migrating all of bsddb3 at once then that is going to be a massive code review that should be happening in prep for rc1.

I have a sickening feeling that this isn't the only major change that may hit the betas. PEP 3118 is only about 2/3's implemented (with hardly any tests, I might add), and Travis has said the earliest he can get to it is August... -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."

As a data point, I just presented a tutorial here at OSCON on Python 3 Porting, and had a number of people asking about C API changes. I punted for my talk (*) because things are still in flux. Plus I only had 3 hours. I did suggest that if your extension is just glue to a C library, you should consider using ctypes. So yes, collecting this information, even if it's just in a wiki page, would be a good and popular thing. Anthony (*) slides: http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf On Mon, Jul 21, 2008 at 2:37 PM, Lennart Regebro <regebro@gmail.com> wrote:

On Mon, Jul 21, 2008 at 20:16, Brett Cannon <brett@python.org> wrote:

...

But waiting until all the betas have gone out totally defeats the purpose of the betas!

I agree. Writing an actual *guide* can wait, but documenting the differences with code examples is a work that can start now, and I agree that it would be great if this would start now.

But writing a guide might not be a good idea until we know what the changes are, and if the API is changing quickly now we don't. :-)

-- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anthony%40interlink.com.au

I'm planning on re-presenting it at the local google office in the next couple of weeks. I might try and arrange for it to be recorded and put online. At the moment we seem to have a real lack of concrete information for people about the transition. If I had time (ha! HA!) I'd try to turn the slides into a series of articles. Right now, there's the What's New In Python 3.0, and the PEPs. The former isn't complete yet (obviously) and isn't all that detailed. The latter is a whole pile of text, some relevant and some not so much. Anthony On Wed, Aug 13, 2008 at 10:09 PM, Trent Nelson <tnelson@onresolve.com> wrote:

...

(*) slides: http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf

Hilarious! Seems like that would have been a riot of a session to attend. (I'm kicking myself for attending some other uninteresting talk when yours was on.)

Trent.

On Mon, Jul 21, 2008 at 2:37 PM, Lennart Regebro <regebro@gmail.com> wrote:

On Mon, Jul 21, 2008 at 20:16, Brett Cannon <brett@python.org> wrote:

...

But waiting until all the betas have gone out totally defeats the purpose of the betas!

I agree. Writing an actual *guide* can wait, but documenting the differences with code examples is a work that can start now, and I agree that it would be great if this would start now.

But writing a guide might not be a good idea until we know what the changes are, and if the API is changing quickly now we don't. :-)

I am the nominal maintainer of the D programming language's bindings to the Python/C API.[1] Keeping on top of the changes in the C API is therefore of some interest to me. At the heart of these bindings is 3000 or so lines of D code containing the translated C headers. Adding the changes made in 3.0 (and 2.6, for that matter) will probably have to be done by hand. Any document detailing every change, from the broadest refactorings to the tiniest name-changes, will therefore be of invaluable assistance to me. Obviously, I don't plan on even starting this upgrade until the C API is nailed down and such a document exists. But any drafts, or even a bulleted list of changes, would at least give me an idea of the scope of what I'm in for. [1] http://pyd.dsource.org -Kirk McDonald

Last time I looked at it, the C API wasn't nailed down yet. That's why I passed over it entirely for my tutorial. The only advice I was able to give was that if your extension is just a wrapper around existing C code, you might be better off rewriting it using ctypes. That way it should work on both 2.6 and 3.0. This doesn't work for PyCXX, of course :-( On Fri, Jul 25, 2008 at 8:33 AM, Barry Scott <barry@barrys-emacs.org> wrote:

On Jul 21, 2008, at 22:37, Lennart Regebro wrote:

...

On Mon, Jul 21, 2008 at 20:16, Brett Cannon <brett@python.org> wrote:

...

But waiting until all the betas have gone out totally defeats the purpose of the betas!

I agree. Writing an actual *guide* can wait, but documenting the differences with code examples is a work that can start now, and I agree that it would be great if this would start now.

But writing a guide might not be a good idea until we know what the changes are, and if the API is changing quickly now we don't. :-)

I'm working on getting a version of PyCXX working with Python 3.0. The lack of any docs outside of the header files is making this a slow process.

I think its a mistake to expect a serious beta test of extensions when you have no guide to the changes in the C API.

If you had a guide then diff it between releases would be a guide to what need fixing up going from beta to beta to rc.

Oh and I'm not going to try and make a version of PyCXX that works on 2.x and 3.x as the changes are too fundamental.

Barry

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anthony%40interlink.com.au

Le Wednesday 13 August 2008 15:27:42 Hrvoje Nikšić, vous avez écrit :

Given that ctypes doesn't work on a number of popular architectures, including x86_64 (the last time I looked), I'd hardly call that "better off". :-(

I wrote a debugger based on ptrace using ctypes: http://fusil.hachoir.org/trac/wiki/python-ptrace The debugger works well on: - Ubuntu Gutsy, i386 - Debian Etch, x86_64 <= yes, it works well - Debian Etch, ppc32 - FreeBSD 6.2 and 7.0, i386 <= yes, ctypes runs fine on FreeBSD too (so Python 2.4 with ctypes the external ctypes module and Python 2.5 with included ctypes) I have no other computer to test other CPUs :) ctypes allows to write code working on CPython 2.4, 2.5, 2.6 and 3.0 (with 2to3), but also on PyPy! Jython plans also to support ctypes. So, please, retry ctypes ;-) -- Victor Stinner aka haypo http://www.haypocalc.com/blog/

Barry Warsaw <barry <at> python.org> writes:

I agree. Our last beta is scheduled for this wednesday

Are you sure? According to http://mail.python.org/pipermail/python-3000/2008-July/014269.html, it's scheduled for August 23rd.

Barry Warsaw <barry <at> python.org> writes:

Ah darn, that's a typo in the PEP. I definitely meant August 13, as the Google calendar shows.

Ah, am I the only one *not* to use Google calendar? :)

Do we think we can be ready for beta3 this Wednesday? If not, I'd rather stick to a weekday release and do it on Wednesday August 20th. Let me know what you think.

There are quite a few showstoppers, a number of them non-trivial, in the bug tracker. I'm not very optimistic for a release this Wednesday. By the way, I need your pronouncement on http://bugs.python.org/issue2834 cheers Antoine.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 11, 2008, at 8:27 AM, Barry Warsaw wrote:

Ah darn, that's a typo in the PEP. I definitely meant August 13, as the Google calendar shows.

Do we think we can be ready for beta3 this Wednesday? If not, I'd rather stick to a weekday release and do it on Wednesday August 20th. Let me know what you think.

It sounds like Wednesday August 13th will not be feasible, so we'll do beta 3 on Wednesday August 20th. I've updated both the PEP and the Google Calendar. Thanks, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKDE+XEjvBPtnXfVAQIATwQApbwwrof862rrH8YU0QP3gVENMU4TRpZx 9jdnJk+OZJpFo74XitnrWDsprY1r/lJdGaLnebfg9DztbjHVgCWvkRNXI7qIbRpf QfSeMusrhVwDNITBhJ/0j+A1phWUQG6CU0dez+iKvCJUcohgDlFmlIsw8tCkgDYG On7b7ZKlHd8= =kLcU -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote: | On Mon, Jul 21, 2008 at 11:06, Jesus Cea <jcea@jcea.es> wrote: |> I'm *VERY* interested in 2.6->3.0 migration guide for C module |> extensions. 3.0 is around the corner and the API is changing almost |> daily :-p. | | It would be great if python-incompatibility would have examples of the | C-api changes as well. That would really help in migrating and writing | a migration guide. It would be great if you could help with this! I can comment about some issues I had this weekend. Remember that my intention is to keep a single C codebase for 2.6 and 3.0. * Int/Long integration. In Python 3.0 "PyInt_*" has vanished. But using "PyLong_*" in Python 2.x surfaces so many issues that I have decided to define "NUMBER_*" macros to be conditionally expanded to "PyInt"/"PyLong" when compiling to 2.x/3.0. Not nice, but I can't see a better way. * The module initialization has changed completely. In fact I am fighting this, still. Some help needed. * "Py_FindMember" was eliminated ?last week?. I workaround this, but I don't know really how to write a "smart" getattr function now. Any pointer? At least my current code compiles under 3.0, but it still bombs when importing it. Life sucks. PS: I'm learning the hard way, doing "diff" between 2.6 and 3.0 module sourcecode. It must be a better way!. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSIRbTplgi5GaxT1NAQJTBAP/cHndbYfnpNF+UoJP0vswoJrMtrNRu6F4 TAAMGbv4sfE5a308sfjoXxFuvUA8kXAyqdJCMXlNWDfX6CEsozQwoS06d6HNkkZn k9iGEbjwiWVdcw0y6gXvt9rL+klK004Rg4pUHMYtO3yUbaFSqvCI1kox6Rf1Q4dB 3CywJ2/fAu4= =V42Q -----END PGP SIGNATURE-----

I've added a setup.py to the python-incompatibilities projects code, so adding c-extention modules should now be much easier. I don't do much c-development myself, so I'm not the right person to do this, but anybody that feels like adding C-extensions to this project is more than welcome to do so. Just mail me for write access. http://code.google.com/p/python-incompatibility/