Thoughts on new grammar rules (PEP 284 in particular)

[holger krekel]

Steve Horne wrote:
> On Fri, 10 May 2002 19:32:17 +0200, holger krekel
> <pyth at devel.trillke.net> wrote:
> 
> >Tell us the truth! You were sent from these evil perl-hackers
> >on a quest to bring python to perl's line-noise levels :-)
> 
> Nope - I hate perl.
> 
> The basis is taken from XML (or, alternately, LISP).
> 
> In a manual, it is much easier to look up a name than a combination of
> operators. For instance, on the first reading of Python code, if you
> did not know that the '{', ':', and '}' tokens combined to define
> dictionaries, it would be a bit of a pain to look up in the manual
> while trying to read some source code. You wouldn't know to look up
> 'dictionary' because you wouldn't know it's a dictionary.

mostly true. But David Beazley's Essential Reference does it right:
it lists many symbols at the beginning of the index (except ':').

> My idea is not practical for everyday features, and I'm not suggesting
> it for that. The Python language is already more than rich enough to
> support most everyday programming tasks easily. But it allows new
> features to be added, and it's no less readable than an calculation
> with a few redundant parentheses surely. As such, surely it's better
> than performing ever-more-extreme contortions with the existing
> keywords and operators, as is already noticable in some PEPs.
> 
> Of course, with 20/20 hindsight, a much better approach could have
> been taken. For instance, consider the following...
> 
>   begin function ... :
>     ...
> 
>   begin while ... :
>     ...
> And, relevant to a current PEP...
> 
>   begin switch ... :
>     begin case ... :
>       ...
> 
>     begin default :
>       ...

don't you think that the increased verbosity hurts a lot? 
(Apart from the fact that 'begin' sounds like starting a loop to me.)

> and because only 'begin' would be a keyword ('procedure' etc being
> ordinary identifiers, which only have special meaning after the
> 'begin' keyword) any new structure could be added without needing new
> keywords or obscure operator combinations - old code would be safe
> from at least one aspect of the evolution of the language.

not true, unless the parser doesn't look at your code-block. Consider
the 'yield' keyword. Older python-parsers produce a 'SyntaxError'. 
If you would esacape that with 'begin yield' then the parsing process
starts to loose a lot of meaning (apart from beeing very ugly).

> So using perlish symbols isn't by any means my ideal - I just think
> that in the long run there may already be a risk of serious creaping
> perlishness (due to the resistance to adding new keywords)

um, this sentence somewhat means that python is already perlish :-)

> , and this
> would be a way of saying 'this far, but no further'.

IMO the developer crew and especially GvR is very careful 
with respect to language changes. I don't know if
it would be possible to be even more conservative about
language *syntax* so that older parsers would not choke
on future extensions. 

    holger