User: Password:
|
|
Subscribe / Log in / New account

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

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

Posted Feb 10, 2011 3:47 UTC (Thu) by maney (subscriber, #12630)
In reply to: Big problem: Confusing implementation with spec. One implementation should support BOTH by dwheeler
Parent article: Moving to Python 3

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.


(Log in to post comments)

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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds