4 ms·

Of all Armin's articles to date, this one I agree the most with. > Python is a language that suffers from not having a language specification ... There are so

by ak217 12y ago

Of all Armin's articles to date, this one I agree the most with. > Python is a language that suffers from not having a language specification ... There are so many quirks and odd little behaviors that the only thing a language specification would ever produce, is a textual description of the CPython interpreter... Keeping a language lean and well defined seems to be very much worth the troubles. Future language designers definitely should not make the mistake that PHP, Python and Ruby did, where the language's behavior ends up being "whatever the interpreter does". This is an incredibly important point. The rise of PyPy is just one compelling illustration of how Python is at a point where a language specification is needed, and these crazy CPython-specific bugs need to be purged. > I think for Python this is very unlikely to ever change at this point, because the time and work required to clean up language and interpreter outweighs the benefits. I would disagree - I think it's possible for Python to change this. Any such bizarre behaviors need to be treated as a bug, and eliminated in the next release.

rdtsc 12y ago
> Any such bizarre behaviors need to be treated as a bug, and eliminated in the next release. Going back in time (sorry for the long story). From what I observed, there seems to have been a split in the community. The split is between the importance for PyPy and its future vs the "core" CPython. When PyPy was making very fast progress there was a feeling that maybe in the next big release PyPy will merge into CPython. So maybe if you downloaded python 3.0 you'd just get PyPy with it. There was a lot of hype and hope. And I think at some level the old guard (Guido and some other core developers) saw that as bit of threat and they made public remarks that I understood to mean: "CPython is not PyPy", "it won't be merged in any time soon", "CPython is fast enough". So why all this background? Well that might explain why there would be resistance to modifying CPython to "help out" PyPy.
TD-Linux 12y ago
I think Python had one chance to do what you suggest - remove bizarre behaviors. This chance was Python 3. This is also one of the things that bothers me a bit about Rust. The complexity of the compiler means that writing an actual language spec is hard, and the spec is very much tied to "what rustc's borrow checker is capable of".
- dbaupp 12y ago
  There is a relative formal document describing the borrow checker's behaviour: http://doc.rust-lang.org/master/rustc/middle/borrowck/doc/ http://doc.rust-lang.org/master/rustc/middle/borrowck/doc/
sitkack 12y ago
Python 3 should have been a from the ground rewrite of a new core runtime written to a language specification. Maybe we can get that in Python 4.
- Demiurge 12y ago
  Who's going to work on that, and most importantly bless it as official and unite people? I haven't seen anything from Guido on the criticisms of Python 3 and CPython, like this post and other unicode complexity complaints in Python 3. It seems that a lot of people who like Python because it lets them move fast hit a wall when they encounter main Python developers as moving so slow as to consider it okey to have two major versions of a language competing until 2020.
  - sitkack 12y ago
    There should be a spec and M versions of the runtime. The batteries should be portable between those versions. I used to split by time evenly between Jython, CPython and PyPy. Now I use PyPy about 80% of the time. But having the spec defined as how CPython and the included libraries operate is detrimental to the language. Python3 could have been a chance to clean up the syntax, define and excellent FFI protocol and split the standard library. Python3 could have been a reference implementation that spread Python to all corners of computation.
e12e 12y ago
A language spec (other than "cpython is the spec") would probably be good. But I know of jython, iron python, stackless python and micro python, in addition to pypy -- that are all more or less complete and/or alive as alternative implementations. I'm not sure of the .net variant (iron python) -- I've heard rumours that it's dead. So it's not like the lack of a spec is an insurmountable obstacle, nor like it's not something that no-one is working on...
- bunderbunder 12y ago
  It's probably not an insurmountable obstacle, but getting over it is by no means trivial. Exhibit A: None of the alternative Python implementations are 100% compatible with CPython. I get the impression that, in practice, the "Python spec" is something that can only be approached asymptotically.
rcthompson 12y ago
What are good examples of languages with specifications and at least two implementations that fully implement the spec?
- CountSessine 12y ago
  Given how complicated any specification for a non-trivial language is, I wonder if there are any. But I think this is beside the point. Not having a specification for a language pushes every language feature discussion down onto application and library developers 'in situ'. When a developer or library maintainer stumbles onto unexpected interpreter or compiler behavior in a language without a specification, it means that in the short term there's no guidance about how they should deal with it. Do I hack this for Visual C++ in a way that can be removed eventually or do I really have to assume going forward that variadic templates aren't going to be available?
- Joeri 12y ago
  C99 and C++11 have several compliant implementations, as does ECMAScript 5 (javascript). The benefit of a spec is not so much that all implementations are necessarily completely compliant, it's that you know what the behavior is supposed to be so you can implement to the spec and work around any differences in implementation. Plus, you can report bugs without them being closed as "by design".
- NateDad 12y ago
  Go has gc and gccgo. They made two implementations to keep the spec honest and not just "whatever the compiler does".
- chaoky 12y ago
  Common Lisp, for sure
  - rcthompson 12y ago
    Yes, the various Lisps were the first possible examples I came up with (I think Scheme probably qualifies as well).
- 12y ago

by ak217 12y ago

rdtsc 12y ago

> Any such bizarre behaviors need to be treated as a bug, and eliminated in the next release. Going back in time (sorry for the long story). From what I observed, there seems to have been a split in the community. The split is between the importance for PyPy and its future vs the "core" CPython. When PyPy was making very fast progress there was a feeling that maybe in the next big release PyPy will merge into CPython. So maybe if you downloaded python 3.0 you'd just get PyPy with it. There was a lot of hype and hope. And I think at some level the old guard (Guido and some other core developers) saw that as bit of threat and they made public remarks that I understood to mean: "CPython is not PyPy", "it won't be merged in any time soon", "CPython is fast enough". So why all this background? Well that might explain why there would be resistance to modifying CPython to "help out" PyPy.

TD-Linux 12y ago

I think Python had one chance to do what you suggest - remove bizarre behaviors. This chance was Python 3. This is also one of the things that bothers me a bit about Rust. The complexity of the compiler means that writing an actual language spec is hard, and the spec is very much tied to "what rustc's borrow checker is capable of".

dbaupp 12y ago
There is a relative formal document describing the borrow checker's behaviour: http://doc.rust-lang.org/master/rustc/middle/borrowck/doc/ http://doc.rust-lang.org/master/rustc/middle/borrowck/doc/

sitkack 12y ago

Python 3 should have been a from the ground rewrite of a new core runtime written to a language specification. Maybe we can get that in Python 4.

Demiurge 12y ago
Who's going to work on that, and most importantly bless it as official and unite people? I haven't seen anything from Guido on the criticisms of Python 3 and CPython, like this post and other unicode complexity complaints in Python 3. It seems that a lot of people who like Python because it lets them move fast hit a wall when they encounter main Python developers as moving so slow as to consider it okey to have two major versions of a language competing until 2020.
- sitkack 12y ago
  There should be a spec and M versions of the runtime. The batteries should be portable between those versions. I used to split by time evenly between Jython, CPython and PyPy. Now I use PyPy about 80% of the time. But having the spec defined as how CPython and the included libraries operate is detrimental to the language. Python3 could have been a chance to clean up the syntax, define and excellent FFI protocol and split the standard library. Python3 could have been a reference implementation that spread Python to all corners of computation.

e12e 12y ago

A language spec (other than "cpython is the spec") would probably be good. But I know of jython, iron python, stackless python and micro python, in addition to pypy -- that are all more or less complete and/or alive as alternative implementations. I'm not sure of the .net variant (iron python) -- I've heard rumours that it's dead. So it's not like the lack of a spec is an insurmountable obstacle, nor like it's not something that no-one is working on...

bunderbunder 12y ago
It's probably not an insurmountable obstacle, but getting over it is by no means trivial. Exhibit A: None of the alternative Python implementations are 100% compatible with CPython. I get the impression that, in practice, the "Python spec" is something that can only be approached asymptotically.

rcthompson 12y ago

What are good examples of languages with specifications and at least two implementations that fully implement the spec?

CountSessine 12y ago
Given how complicated any specification for a non-trivial language is, I wonder if there are any. But I think this is beside the point. Not having a specification for a language pushes every language feature discussion down onto application and library developers 'in situ'. When a developer or library maintainer stumbles onto unexpected interpreter or compiler behavior in a language without a specification, it means that in the short term there's no guidance about how they should deal with it. Do I hack this for Visual C++ in a way that can be removed eventually or do I really have to assume going forward that variadic templates aren't going to be available?
Joeri 12y ago
C99 and C++11 have several compliant implementations, as does ECMAScript 5 (javascript). The benefit of a spec is not so much that all implementations are necessarily completely compliant, it's that you know what the behavior is supposed to be so you can implement to the spec and work around any differences in implementation. Plus, you can report bugs without them being closed as "by design".
NateDad 12y ago
Go has gc and gccgo. They made two implementations to keep the spec honest and not just "whatever the compiler does".
chaoky 12y ago
Common Lisp, for sure
- rcthompson 12y ago
  Yes, the various Lisps were the first possible examples I came up with (I think Scheme probably qualifies as well).
12y ago