[Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0 (original) (raw)
M.-A. Lemburg mal at egenix.com
Thu May 29 20:08:57 CEST 2008
- Previous message: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
- Next message: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Christian,
so far you have not responded to any of the suggestions made on this thread, only defended your checkin. That's not very helpful in getting to some conclusion.
What's so hard about going with a proper, standard solution that doesn't involve using your preprocessor hack ?
Why can't we have both PyString and PyBytes exposed in 2.x, with one redirecting to the other ?
Why should the 2.x code base turn to hacks, just because 3.x wants to restructure itself ?
Why aren't you even considering my proposed solution for this whole renaming and reorg problem ?
BTW: Is there some PEP or wiki page explaining how you actually implement the merging from 2.x to 3.x ? I'm still under the assumption that you're only using svnmerge.py for this and doing straight merging from the trunk to the branch.
Not sure how others feel about it, but if the only option you would feel comfortable with is not having the 3.x renaming backported, then I'd rather go with that, really. It's easy enough to add a header file to map PyString APIs to PyBytes if you want to port an extension to 3.x.
Thanks,
Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, May 29 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2008-07-07: EuroPython 2008, Vilnius, Lithuania 38 days to go
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611On 2008-05-29 17:45, Christian Heimes wrote:
M.-A. Lemburg schrieb:
Well, first of all, it is a change in the C API: APIs have different names now, they live in different files, the Python documentation doesn't apply anymore, books have to be updated, programmers trained, etc. etc. That's fine for 3.x, it's not for 2.x. No, that's not correct. The 2.x API is still the same. I've only changed the internal code.
Second, if you leave out the "ease merging" argument, all of this is not really necessary in 2.x. If you absolutely want to have PyBytes APIs in 2.x, then you can add them, without removing the PyString APIs. We have done that on a smaller scale a couple of times in the past (turned functions into macros or vice-versa). The PyString methods are still available and the official API for dealing with str objects in 2.x. And finally, the "merge" argument itself is not really all that strong. It's just a matter of getting the procedure corrected. Then you can rename and restructure as much as you want in 3.x - without affecting the stability and matureness of the 2.x branch. I'm volunteering to revert my chances if you are volunteering to keep the Python 2.x series in sync with the 3.x series. Christian
Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/mal%40egenix.com
- Previous message: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
- Next message: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]