[Python-3000] It's a statement! It's a function! It's BOTH!

[Guido van Rossum]

On 4/1/06, Talin <talin at acm.org> wrote:
> This is about the print / writeln debate.

No, it isn't. :-)

Let me focus on the part that you skirt, to explain that that's what
makes anything like this pretty much impossible.

> We would start by defining a simple metalanguage for giving instructions to
> the parser. I won't even try to suggest a syntax, but in essence this would
> be something that has the same role as a macro language or preprocessor, in
> that it is not part of the programming language itself, but instead describes
> how the subsequent text is to be interpreted. (There's already some precedent
> for this with the __future__ syntax.)

So here's the rub. Assume we have nice simple meta-syntax for making
"print" a special form. For the sake of having a concrete (if silly)
example, let's say you do this by writing

  (-:print:-)

The problem is, where do you put this so that the parser knows that
'print' is a special form? You'd like to be able to define a whole
library of these, and import it; you don't want to have to write
(-:print:-) at the top of each file where you want to use this (this
would pretty much destroy the newbie-friendliness of the feature).

But the Python parser doesn't read the modules it imports! When it
sees "import foo" it just generates a few bytecodes that cause foo to
be imported at run time, and notes that foo is now a local variable
(yes, local!). If there are any (-:print:-) declarations in foo.py,
the parser won't know about them. This is different from import in
Java and #include in C/C++, where the contents of what is
imported/included can inform the parser.

Based on my experience with past wild proposals, you're probably going
to counter by proposing that the Python interpreter somehow follows
imports at compile time; I could then object that it's totally
reasonable that the module to be imported is unavailable to the parser
(either due to import hooks to be installed later, or simple separate
compilation as done by compileall.py). You could then counter by
proposing an alternative syntax for compile-time imports (-:import
foo:-) that must be followed and interpreted by the parser. And I
could call that ugly, hard to implement, etc.

But please save your breath. Programmable syntax is not in Python's
future -- or at least it's not for Python 3000. The problem IMO is
that everybody will abuse it to define their own language. And the
problem with that is that it will fracture the Python community
because nobody can read each other's code any more.

It's one thing to read code that calls an external function whose
meaning you have to guess from its name. It's quite another thing to
realize that you can't even know for sure where the function calls
are. Let's not go there.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)