The text of the PEP has too much on motivation and rationale: maybe that would be suitable for an informative PEP. The proposal itself is under-specified. But the real weakness cannot be fixed by improving the text: it is in the key characteristic of the proposal, which wants to have its cake and eat it, too. This is initially likable: to recipients who don't know about e-strings they behave just like regular strings; but recipients who *do* know about them can extract the template and the values to be interpolated and use these to build an alternative string, e.g. to be used as a translation. However, in order to fulfill the former requirement, the type must inherit from str (it's one of those built-in types for which duck typing doesn't always work). And at the same time this is a real problem, because it's too easy to lose the e-string. For example, any function that operates on strings will operate on e-strings, but the result will in general be a plain str instead of an e-string, which can be confusing for functions that want the e-string. But *not* inheriting from str causes the reverse problem. IOW, e-strings don't make a good alternative for f-strings -- they would have to be added as a second string type. And the proliferation of similar but different template string types cannot make anyone happy. -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150904/e529a59c/attachment.html>
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