Big problem: Confusing implementation with spec. One implementation should support BOTH [LWN.net]

Big problem: Confusing implementation with spec. One implementation should support BOTH

Posted Feb 10, 2011 2:46 UTC (Thu) by dwheeler (guest, #1216)
Parent article: Moving to Python 3

The real problem here is that the *spec* is being confused with its *implementation*. If there was a single implementation that accepted both Python2 and Python3, and let Python3 programs call Python2 programs, this would be a non-event. In fact, it'd be easy to do the transition, and we'd be mostly done.

Instead, there's one program that implements Python3, and a completely separate and incompatible engine that runs Python2.

Of course, this suggests a way out: Expand the Python2 system so it can run arbitrary Python3, and make it possible for Python3 programs to seamlessly call Python2. Then the problem would disappear.

(Log in to post comments)

Big problem: Confusing implementation with spec. One implementation should support BOTH

Posted Feb 10, 2011 3:47 UTC (Thu) by maney (subscriber, #12630) [Link]

I agree almost entirely, but I think there's one quibble that has to be made: the real problem is that the spec *is* the (CPython) implementation. Perhaps that's beginning to change, finally?

Oh, and you gloss over the issue of how the omnivorous compiler knows which language version to treat a given module as. Sure, tagging could be added, but then you're not really doing seamless interoperability after all. It would be close enough to make me smile!

BTW, I just saw a brief mention of what sounds like it might be real, workable versioning for compiled (.pyc and .so) modules in a new or forthcoming release of 3.x. That might not be a killer feature, but it's the first thing in 3 that's more than "that's nice, wish Guido really did have a time machine so the original mistake hadn't been made" to me.

Big problem: Confusing implementation with spec. One implementation should support BOTH

Posted Feb 10, 2011 17:44 UTC (Thu) by zlynx (subscriber, #2285) [Link]

I see a simple solution that could be implemented as a shell script, even.

Make a "python" interpreter that reads the script file and either looks for a Python2 marker of some kind or analyzes the file for Python3 syntax. It then calls the correct real interpreter.

Considering the speed (slow) of Python applications, this step would not add too much time.

Big problem: Confusing implementation with spec. One implementation should support BOTH

Posted Feb 10, 2011 18:53 UTC (Thu) by foom (subscriber, #14868) [Link]

That won't help you at all when you want to use libraries. Having "import foo" work when you're writing in the Py3 dialect, and foo is written in the Py2 dialect would have been a major win.

Big problem: Confusing implementation with spec. One implementation should support BOTH

Posted Feb 10, 2011 19:56 UTC (Thu) by zlynx (subscriber, #2285) [Link]

Writing a giant combo cPython interpreter doesn't sound like a winner to me.

The solution might be to convert cPython into IronPython everywhere and compile Python to .NET / Mono IL. Then Python3 could call Python2 code in the same way that C#, F#, C++ and Visual Basic can all call each other.

Or to be more acceptable to anti-Microsoft people, use the Parrot virtual machine, if that ever becomes usable. Another option might be LLVM. A problem with LLVM is that it doesn't specify a reflection, object, function and data sharing scheme in the same way that .NET does. Java might be another virtual machine that could be made to work.