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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4