"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__. > ... 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. 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??? > 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. Paul Prescod
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