Paul Prescod wrote:
"M.-A. Lemburg" wrote:
...
Embrace the __future__!
-1.
Too dangerous.
It isn't dangerous. That's precisely what __future__ is for! It is no more dangerous than any other feature that uses __future__.
It is. Currently Python strings are just that: immutable strings. Now, you suddenly add dynamics to then. This will cause nightmares in terms of security. Note that Python hasn't really had a need for Perl's "taint" because of this. I wouldn't want to see that change in any way. If you really need this, either use a string prefix or call a specific function which implements string interpolation. At least then things are obvious and explicit.
... If string interpolation makes it into the core, then please use a *new* construct. '\$' is currently interpreted as '\$' and this should not be changed (heck, just think what would happen to all the shell script snippets encoded in Python strings).
No, this should be changed.
Huh ? I bet RedHat and thousands of sysadmins who have switched from shell or Perl to Python would have strong objections.
Completely ignoring string interpolation, I am strongly in favour of changing the behaviour of the literal string parser so that unknown \-combinations raise a SyntaxError. If you don't want a backslash to be interpreted as an escape sequence start, you should use a raw string.
The Python documentation and grammar already says:
escapeseq ::= "\" <any ASCII character>
The documentation says:
"Unlike Standard , all unrecognized escape sequences are left in the string unchanged, i.e., the backslash is left in the string. (This behavior is useful when debugging: if an escape sequence is mistyped, the resulting output is more easily recognized as broken.)"
That's a weird thing to say. What could be more helpful for debugging than a good old SyntaxError???
If there's nothing wrong with the escape why raise a SyntaxError ?
BTW, why don't you wrap all this interpolation stuff into a module and then call a function to have it apply all the magic you want.
We've been through that in this discussion already. In fact, that's how the discussion started.
I've jumped in at a rather late point. Perhaps you ought to rewind the discussion then and start discussing in a different direction :-) E.g. about the syntax to be used in the interpolation and where, when and in which context to evaluate the strings. There are so many options that I can't really see any benefit from chosing only one and hard-coding it into the language. Other users will have other requirement which are likely not to combine well with the one implementation you have in mind. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/