
The mandate for this post is the following from GvR:
Please bring up the Leo issues in Python-dev.
The major concern I have with '@' syntax as it relates to Leo is the potential for ongoing and never-ending conflicts between Leo's directives and @x constructs in Python. Leo presently supports the following directives: @ (followed by one or more whitespace characters) @all, @asis, @c, @code, @color, @comment, @delims, @doc, @encoding, @end_raw, @file, @first, @header, @ignore, @killcolor, @language, @last, @lineending, @nocolor, @noheader, @noref, @nosent, @nowrap, @others, @pagewidth, @path, @quiet, @raw, @root, @root-code, @root-doc, @silent, @tabwidth, @terse, @thin, @unit, @verbose, @wrap Worse, Leo allows plugins to define their own directives. There is already a plugin that defines @wiki. Furthermore, @run, @test and @suite are also used in special contexts. Leo's users could probably live with a small, fixed set of @x constructs in Python. But if the Python programmer can create new @x identifiers then they have a big, big problem. What happens when another Python @x construct conflicts with one of these directives or some other directive? These directives act as a markup meta-language. Many of these directives are found interspersed in the code: a conflict with a construct in Python would have most unhappy consequences. To make matters worse, one of the _best_ choices I ever made in Leo was to remove all "escape" conventions regarding '@' (and other noweb constructs). This took a bit of courage, but it has turned out to be clearly the right choice. But if Python can now generate arbitrary @x strings Leo will have to do something really drastic. There are a number of markup languages that use '@' to from the underlying language (Python) to the markup language. I was always under the impression that the clear statement in the Reference Manual that at signs are invalid everywhere (except in comments and strings) was a clear signal of an intention to keep those symbols for other valid purposes. I do hope this won't change. Edward P.S. I recently wrote a pretty-printer for Python using the tokenize module. What will be the status of the '@' token? Is it still an "errortoken" ? Sure, this is a minor point, but it _will_ affect other tools. EKR -------------------------------------------------------------------- Edward K. Ream email: edreamleo@charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------