[Python-Dev] PyString -> PyBytes C API renaming (Stabilizing the C API of 2.6 and 3.0)

[M.-A. Lemburg]

On 2008-05-28 14:02, Christian Heimes wrote:
> M.-A. Lemburg schrieb:
>> I have a feeling that we should be looking for better merge
>> tools, rather than implement code changes that cause more trouble
>> than do good, just because our existing tools aren't smart
>> enough.
> 
> We don't have better tools at our hands. I don't think we'll get any
> tools in time or chance the VCS right before a major release.
> 
>> Wouldn't it be possible to have a 2to3.py converter
>> take the 2.x code (including the C code), convert it and then
>> apply any changes to the 3.x branch ?
> 
> Such a converter would be nice for 3rd party code but it's not an option
> for the core. In the past few months I've merged a lot of code from
> trunk to py3k. A 2to3 C converter doesn't help with merge conflicts.
> Naming differences make any merge more painful

I was suggesting to not use SVN to merge changes directly, but to
instead use an intermediate step in the process:

Init:

  1. grab the latest trunk

  2. apply a 2to3 converter to the Python code and the C code,
     applying any renaming that may be necessary

  3. save this converted version in a separate branch merge-branch

Update:

  1. checkout the merge-branch,
   . grab the latest trunk and 3.x branch

  2. apply a 2to3 converter to the Python code and the C code,
     applying any renaming that may be necessary

  3. copy the files over your working copy of the merge-branch

  4. create a diff on the merge-branch

  5. apply the diffs to 3.x branch, resolving any conflicts
     as necessary

This doesn't require new tools (except for some C renaming
support in the 2to3 tool). It only changes the procedure.

We'd basically follow our own suggestions w/r to porting to 3.x,
which is to make changes in the 2.x code, apply 2to3 and then
apply remaining fixes there.

I'm suggesting this, since 3.x is likely to introduce more
Python stdlib and C API changes. The process would likely also
makes a lot of other changes more easily manageable and reduce
the overall merge conflicts.

>>> I find the approach less confusing than your suggestion and my initial
>>> idea.
>> I disagree on that.
>>
>> Renaming old APIs to use the new names by adding a header file with
>> #define <oldname> <newname> is standard practice.
>>
>> Renaming the old APIs in the source code and undoing the renaming
>> with a header file is not.
> 
> I wasn't talking about standard practice here. I talked about less
> confusion for core developers. My approach doesn't split our internal
> API in two.

No, but it does apply a well hidden renaming which will cause
confusion when using a debugger to trace calls in C code.

If you use PyBytes APIs, you expect to find PyBytes functions in
the libs and also set breakpoints on these.

With the renaming we don't have two sets of APIs (old and new) exposed
in the lib, like what we normally do when applying changes to API names.

> And by the way it *is* a standard approach fore Python. Guido told me
> that the same approach was used during the 1.x to 2.0 migration.

There was no API change between 1.6 and 2.0.

You are probably talking about the great renaming between 1.4 and 1.5.
That was different, since it changes almost all C APIs in Python.
And it used the standard practice... from rename2.h in Python 1.5:

/* This file contains a bunch of #defines that make it possible to use
    "old style" names (e.g. object) with the new style Python source
    distribution. */

#define True Py_True
#define False Py_False
#define None Py_None

ie. #define <oldname> <newname>

>> And all this, just because Subversion can't handle merging of
>> symbol renaming.
> 
> As I said earlier we don't have better tools at our disposal. We have to
> make some compromises. Sometimes practicality beat purity.

See above.

>> Please discuss any changes of the 2.x code base on python-dev.
>>
>> Such major changes do need more discussion and possibly a PEP as well.
> 
> In the last few months I started at least three topics about the C API
> renaming. It's in the thread "2.6 and 3.0 tasks"
> http://permalink.gmane.org/gmane.comp.python.devel/93016

Thanks. I stopped reading that thread after Guido's reply in

http://comments.gmane.org/gmane.comp.python.devel/92541

It would really help if subject lines were more specific.

This thread also uses a much to general subject line (which is
why I changed it).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 28 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            39 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 46611