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.
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 46611
On 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.
> Python-Dev mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/mal%40egenix.com