On Tue, Aug 11, 2015 at 10:52 AM, Alexander Walters <tritium-list@sdamon.com> wrote:

On 8/11/2015 11:28, Wes Turner wrote:

On Aug 11, 2015 10:19 AM, "Wes Turner" <wes.turner@gmail.com> wrote:

- [ ] review all string interpolation (for "injection")
* [ ] review every '%'
* [ ] review every ".format()"
* [ ] review every f-string (AND LOCALS AND GLOBALS)
* every os.system, os.exec*, subprocess.Popen
* every unclosed tag
* every unescaped control character

This would create work we don't need.

Solution: __str_shell_ escapes, adds slashes, and quotes. __str__SQL__ refs a global list of reserved words.

I don't understand why % and .format got interjected into this.

If you are mentioning them as 'get the unprocessed version of any string formatting', that is a bad idea, and not needed, since you already have an unprocessed string object. Assuming the method were named "hypothetical":

>>> 'foo bar'.hypothetical()      # returns 'foo bar'
>>> '{0} bar'.format('foo').hypothetical()    # returns 'foo bar'
>>> ('%s bar' % ('foo',)).hypothetical()     # returns 'foo bar'
>>> f'{foo} bar'.hypothetical()     # returns '{foo} bar', prime for translation.

could gettext not be modified to create the same AST as f'{foo} bar' when it is translated to '{foo} le bar.' and inject it back into the runtime?

well, we're talking about a functional [series of] transformations on __str__ (or __unicode__); with globals and locals,

and more-or-less a macro for eliding this (**frequently wrong** because when is a string not part of an output format with control characters that need to be escaped before they're interpolated in).

% and str.format, (and gettext), are the current ways to do this,

and they are also **frequently wrong** because HTML, SQL.

The risk with this additional syntax is that unescaped globals and locals are transcluded (and/or translated);

with an explicit (combination of) string prefixes to indicate forwards-compatible functional composition

(of usually mutable types).