Issues with PEP 3101 (string formatting)
Wrt http://www.python.org/dev/peps/pep-3101/ PEP 3101 says Py3K should allow item and attribute access syntax within string templating expressions but "to limit potential security issues", access to underscore prefixed names within attribute/item access expressions will be disallowed. I am a person who has lived with the aftermath of a framework designed to prevent data access by restricting access to underscore- prefixed names (Zope 2, ahem), and I've found it's very hard to explain and justify. As a result, I feel that this is a poor default policy choice for a framework. In some cases, underscore names must become part of an object's external interface. Consider a URL with one or more underscore- prefixed path segment elements (because prefixing a filename with an underscore is a perfectly reasonable thing to do on a filesystem, and path elements are often named after file names) fed to a traversal algorithm that attempts to resolve each path element into an object by calling __getitem__ against the parent found by the last path element's traversal result. Perhaps this is poor design and __getitem__ should not be consulted here, but I doubt that highly because there's nothing particularly special about calling a method named __getitem__ as opposed to some method named "traverse". The only precedent within Python 2 for this sort of behavior is limiting access to variables that begin with __ and which do not end with __ to the scope defined by a class and its instances. I personally don't believe this is a very useful feature, but it's still only an advisory policy and you can worm around it with enough gyrations. Given that security is a concern at all, the only truly reasonable way to "limit security issues" is to disallow item and attribute access completely within the string templating expression syntax. It seems gratuituous to me to encourage string templating expressions with item/attribute access, given that you could do it within the format arguments just as easily in the 99% case, and we've (well... I've) happily been living with that restriction for years now. But if this syntax is preserved, there really should be no *default* restrictions on the traversable names within an expression because this will almost certainly become a hard-to-explain, hard-to-justify bug magnet as it has become in Zope. - C
Those are valid concerns. I'm cross-posting this to the python-3000
list in the hope that the PEP's author and defendents can respond. I'm
sure we can work something out.
Please keep further discussion on the python-3000@python.org list.
--Guido
On 6/19/07, Chris McDonough
Wrt http://www.python.org/dev/peps/pep-3101/
PEP 3101 says Py3K should allow item and attribute access syntax within string templating expressions but "to limit potential security issues", access to underscore prefixed names within attribute/item access expressions will be disallowed.
I am a person who has lived with the aftermath of a framework designed to prevent data access by restricting access to underscore- prefixed names (Zope 2, ahem), and I've found it's very hard to explain and justify. As a result, I feel that this is a poor default policy choice for a framework.
In some cases, underscore names must become part of an object's external interface. Consider a URL with one or more underscore- prefixed path segment elements (because prefixing a filename with an underscore is a perfectly reasonable thing to do on a filesystem, and path elements are often named after file names) fed to a traversal algorithm that attempts to resolve each path element into an object by calling __getitem__ against the parent found by the last path element's traversal result. Perhaps this is poor design and __getitem__ should not be consulted here, but I doubt that highly because there's nothing particularly special about calling a method named __getitem__ as opposed to some method named "traverse".
The only precedent within Python 2 for this sort of behavior is limiting access to variables that begin with __ and which do not end with __ to the scope defined by a class and its instances. I personally don't believe this is a very useful feature, but it's still only an advisory policy and you can worm around it with enough gyrations.
Given that security is a concern at all, the only truly reasonable way to "limit security issues" is to disallow item and attribute access completely within the string templating expression syntax. It seems gratuituous to me to encourage string templating expressions with item/attribute access, given that you could do it within the format arguments just as easily in the 99% case, and we've (well... I've) happily been living with that restriction for years now.
But if this syntax is preserved, there really should be no *default* restrictions on the traversable names within an expression because this will almost certainly become a hard-to-explain, hard-to-justify bug magnet as it has become in Zope.
- C
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum schrieb:
Those are valid concerns. I'm cross-posting this to the python-3000 list in the hope that the PEP's author and defendents can respond. I'm sure we can work something out.
Another question w.r.t. new string formatting: Assuming the %-operator for strings goes away as you said in the recent blog post, how are we going to convert string formatting (which I daresay is a very common operation in Python modules) in the 2to3 tool? Of course, "abc" % anything can be converted easily. name % tuple_or_dict can only be converted to name.format(tuple_or_dict), without correcting the format string. name % name can not be converted at all without type inference. Though probably the first type of application is the most frequent one, pre-building (or just loading from elsewhere) of format strings is not so uncommon when it comes to localization, where the format string likely has a _() wrapped around it. Of course, converting format strings manually is a PITA, mainly because it's so common. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
participants (3)
-
Chris McDonough
-
Georg Brandl
-
Guido van Rossum