[Python-Dev] PEP 215 does not introduce security issues

[Steven Majewski]

On Mon, 14 Jan 2002, Ka-Ping Yee wrote:

> The '$' prefix only applies to literals, and cannot be used as
> an operator in front of other expressions or variables.  This
> issue is pointed out specifically in the PEP:

I think the term "the '$' prefix" was one of the sources of my
confusion, as '$' is both a string prefix and a symbol prefix within
the string. I think I read "the '$' prefix"  as referreing to the
second kind where you meant the first. The same goes for discussion
of '$' as an operator. (This misreading was the source of the
inconsistency I thought I saw between the examples and other
statements.)

> Therefore, this transformation executes *only* code that was
> literally present in the original program.  (An example of this
> transformation is given at the end of PEP 215 in the
> "Implementation" section.)

O.K. Jason's explaination finally got thru to me: it's more clear
if I think of it as a preprocessor that really doesn't add any
capabilities to the language. I should think of it more like
the 'r' string prefix, which is just a syntactic convenience,
rather than like the 'u' string prefix, which creates a special
kind of (unicode) string. ( Well, it *does* create a special kind
of string in the runtime, but you can't access that string to
to do anything strange in Python, because as soon as it's assigned,
it gets transformed into a 'normal string' . Thinking of it as
a preprocessor makes that more obvious.)

> (By the way, i myself am not yet fully convinced that a string
> interpolation feature is something that Python desperately needs.
> I do see some considerable potential for good, and so the purpose
> of PEP 215 was to put a concrete and plausible proposal on the
> table for discussion.  Given that proposal, which i believe to be
> about as good as one could reasonably expect, we can hope to save
> ourselves the expense of re-arguing the same issues repeatedly,
> and make an informed decision about whether to add the feature.
>
> Among the possible drawbacks/complaints i see are: more work for
> automated source code tools, tougher editor syntax highlighting,
> too many messy string prefix characters, and the addition of yet
> one more Python feature to teach and document.  Security, however,
> is not among them.)

 I'm not wild about more string prefixes, but we've already started
down that road, so I can't complain too much. But, as you've already
noted: it doesn't add any new capability, just new syntax. ( But it
probably as justifiable as the raw string syntax. )
 Although I've knocked the idea in the past, I'ld almost rather see
some sort of 'macro' facility for python, than to see a bunch of
special case syntax added to the language for every feature.


-- Steve