The problem with "as" [was "Re: PEP 318"]

[Joe Mason]

In article <m8o160tec35glo6ruqhkd3tk15tk75una3 at 4ax.com>, David MacQuigg wrote:
> A less generic keyword will lead to odd phrases like "has int" or
> "with staticmethod", or different keywords for each phrase.

Sure.  "has int" is perfectly legible for "this function has the 'int'
property".  Naming a property "int" would be stupid and confusing, but
that's not the syntaxes fault.  (Of course, even if we use decorators to
name things that can be seen as "properties" of functions - like
staticmethod - that's not how they're implemented, so "has" isn't great.
"def ... with" as short for "define this with the following decorators"
is perfectly legible, though.

Different keywords for each phrase wouldn't work at all - there's no set
list of phrases!  You're supposed to be able to define your own.

> Re-use of the same symbol to mean "modified syntax" in any context,
> will avoid the Perl problem (too many symbols with idiosyncratic
> meanings).  Beginners will learn very quickly that the special symbol
> means "similar to the standard syntax, but RTFM if you don't yet know
> this variation".  Locating the right documentation will be easy,
> because it will always be at the end of the discussion on the normal
> form of the statement.

I'm not clear on what you mean by "modified syntax".  If it's accepted
into the language, it's a standard syntax, so marking it with a symbol
makes no sense.  If you mean to mark things for preprocessors, sure, a
standard symbol would be a great idea, but we're not talking about
preprocessors here.

> I would give an example, but I worry it will degenerate this
> discussion into a debate over whether it looks like something bad in
> language X.  Let's see if we can discuss this on a higher level first.
> Does it make sense to have a general symbol for modifications of the
> simple standard syntax?

If you mean marking some bits of the language as being second-class,
absolutely not.

It may make sense to have comment character meaning "ignore the
keyword after this - it's for an external, mechanical tool".  Doxygen
and others already have conventions for this (not to mention the #!
syntax), but it would be helpful to have a common agreed-on format.  I
think that would arise better as something the various tool vendors
evolve among themselves, though.

Joe