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

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

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 ;-)

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

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/