On Tue, Aug 11, 2015 at 10:52 AM, Alexander Walters <tritium-l...@sdamon.com
> wrote:
> On 8/11/2015 11:28, Wes Turner wrote:
>
>
> On Aug 11, 2015 10:19 AM, "Wes Turner" <wes.tur...@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).
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
