On 1 Sep 2015 07:35, "Eric V. Smith" email@example.com wrote:
But back to PEP 498: I can't imagine accepting either PEP 501 or 502 without also accepting PEP 498. And once you've accepted 498, are i- or e-strings sufficiently powerful and useful enough, and are they likely to be used in the correct way? I think that's the question.
Exactly, 498 should now be considered independently, with 501 & 502 as potential answers to questions like:
* how can we mitigate the increased risk of code injection vulnerabilities that comes with native interpolation support? * how can we handle cases where delaying interpolation would be helpful, like event logging or i18n? * how can we support adaptation of the interpolation syntax to cases like SQL Alchemy's "text" API, which consumes an SQL expression in text form and converts it to SQL Alchemy objects?
Writing 501 has satisfied me that those questions *can* be addressed, *if* we decide they should be, and that it can be done in such a way that it can be presented to folks learning Python in the future as an implementation detail of the native string formatting support (that is, folks would be taught formatted strings early, and only later be taught that you can use an interpolation template to split up the template interpolation and template rendering steps.
That all adds up to thinking it's fine to defer answering those questions to later, rather than expecting 498 to address them immediately. We have plenty of time until 3.6 rolls around :)