python2+3

[lkcl]

[changing subject, seems a good idea...]

On May 19, 2:13 am, Terry Reedy <tjre... at udel.edu> wrote:
> On 5/18/2011 9:42 AM, lkcl wrote:
>
> >   he's got a good point, terry.  breaking backwards-compatibility was a
> > completely mad and incomprehensible decision.
>
> I see that I should take everything you (or Harris) say with a big grain
> of salt;-).

 *lol* - i realise it's a hell of a lot of work to get a python
interpreter to support two different grammars and syntaxes: you can
appreciate that i'm in a better position than most to understand that
[i've also done a port of python to gnu-win32 so am familiar with the
codebase]

 now that the code for both has been written, tested and proven, the
task of adding one t't'othr is a leetle less of a challenging task.

 there is one teeny tiny annoying challenge: namespace clashes in c,
of functions and data structures between the two codebases.  however,
this isn't as bad as it first seems.  it's only the "public" face
(Python.h) which has to remain the same, and that can be taken care of
by having data structures that are identical internally and externally
(macros to the rescue) where the internal name is Python2_xxxx and the
external name Python_xxx.

 where it becomes less of a maintenance burden is when you say "ok,
that's it: definitely end-of-the-road for all 2.N development,
period".

 has anyone considered the idea of literally creating a Python2/
subdirectory in the python3 codebase, literally just dropping the
entire python2.N code directly into it, renaming all functions and
data structures, adding a "--2-compatible" switch to the python3 argc/
v and seeing what happens?

 no interoperability, no maintenance, no "compatibility" - just
"support for python 2 directly in the python3 binary".

l.