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
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