Source syntax escapes, new raw string representation. Was: Re: PEP 263 comments
Martin von Loewis
loewis at informatik.hu-berlin.de
Thu Feb 28 10:23:14 CET 2002
bokr at oz.net (Bengt Richter) writes:
> Is this to be a *special purpose* (coding declaration)
> comment-context-limited escape mechanism, or an *open ended* one?
I'm not sure what an "open ended" escape mechanism is. Emacs allows
the definition of arbitrary variables in -*- lines; coding: is just
one of them.
> If special, I think Emacs can just as well adapt to Python as vice
> versa. ISTM ad hoc special escapes in comments are often the
> beginning of a convention for alternative out-of-band info, and
> should be considered in that light. Cf. HTML ;-/
I'm not sure I understand this reference, either. Do you consider the
encoding declaration in the META http-equiv tag as out-of-band, or the
one in the HTTP request? Or are you referring to something completely
> Perhaps it is time to (re?)consider a standard Python mechanism for
> embedding OOB info at arbitrary places in Python source, analogous
> to XML's <![CDATA[ ... ]]> and <? ... ?> (BTW, xml CDATA has a
> HUGE**N wart (IMO) in that it is not nestable.
Processing instructions and CDATA sections are completely different
things. While I could see that processing instructions are some kind
of out-of-band information, CDATA sections are just a certain
well-defined way to present contents; you can easily transform them to
use the standard markup without losing "out-of-band" information -
they are in-band.
> I prefer orthogonal general purpose mechanisms to ad hoc syntactic
> escape warts, so I would prefer <? ... ?> as a vehicle for defining
> encoding. <?py blah blah?> could mean eval('blah blah') in some
> defined python environment
I had initially proposed the directive statement (PEP 244) as a
mechanism to also support encoding declarations; that was
rejected. Tim Peters objected to the introduction of a 'pragma'
statement at many occasions.
> In conjunction with a pythonic CDATA , it would permit wrapping a
> whole source file (or starting at the second line):
That sounds like a different technology. If you really want to propose
this, write a PEP.
More information about the Python-list