On Feb 17, 2010, at 12:53 AM, Peter Murray-Rust wrote:
> Note that specifications here are similar to language specifications (e.g.
> Perl, Python). There is no support for mutating these and the community
> relies on consistency for their compilers.
As a member of the organization which holds the copyright to Python, I
disagree. There are several ways to mutate Python:
- develop as a parallel branch of the code base. Stackless Python does this
to add light-weight coroutines. They include a full distribution of the Python
documentation along with the documentation for the new libraries they added.
Guido has said these features will never be part of the main Python
implementation. There are companies which base their technology stack on
Stackless.
- develop new language systems which convert to another byte code layer and
another run-time system; Jython and Iron Python do this. Jython does not have
support for multiple inheritance if the base classes are from Java, which is a
mutation of the Python language. IronPython also has a number of documented
"mutations".
(Historically, JPython was what turned Python from an implementation
specification to a real specification, because the documentation was written to
note which aspects were defined by the language vs. defined by the
implementation. One such was how garbage collection is done.)
- write an alternate parser which builds to the byte codes for the C-based
virtual machine; my ply4python does this.
- replace the byte code engine with something else, but keep the main C-level
API. Unladen Swallow and psyco do this.
- build an entire JIT for Python and other dynamic languages; PyPy does this,
and has options to change object semantics at run-time.
- write a Python-like language; Cython compiles what is a superset of a
subset of Python into a Python/C extension. Shedskin uses another approach.
- even staying inside of the main Python implementation, there is a standard
track way to propose mutations to the language, called PEPs. Python will, btw,
be in a language freeze for the next few years, with goal of letting the other
implementations catch up and of improving the standard library. Not all changes
go through this process.
Some of these are consistent or consistent within reason to the C
implementation of Python, because of the power of Metcalfe's law. Some of them
are different in order to try out crazy ideas, like my modification of Python
to handle Perl-style pattern matching:
for line in open("python_yacc.py"):
if line =~ m/def (?P<name>\w+) *(?P<args>\(.*\)) *:/:
print repr($1), repr($args)
Some of them, like the backwards-incompatible mutation from the 2.x to 3.x
series, are the result of a long and deliberate development process.
I do want to stress that the PSF - Python Software Foundation - holds the
copyright to Python. Guido is in charge of the development, and he is the BFDL,
but he does not have the legal ownership of the source code. The PSF is a
501(c)3 organization with the goal of developing and promoting the use of
Python.
> I believe that chemical specifications are effectively chemical compilers and
> should have the same consistency.
While my view of the consistency of Python (at least) is enough different from
yours that I agree with this statement even though I disagree with its basis or
meaning.
Andrew
[email protected]
------------------------------------------------------------------------------
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
_______________________________________________
Blueobelisk-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/blueobelisk-discuss
