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 [EMAIL PROTECTED] list. --Guido On 6/19/07, Chris McDonough <[EMAIL PROTECTED]> wrote: > 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/) _______________________________________________ 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/archive%40mail-archive.com
