[Python-Dev] [Python-3000] Issues with PEP 3101 (string formatting)

[Talin]

I haven't responded to this thread because I was hoping some of the 
original proponents of the feature would come out to defend it. 
(Remember, 3101 is a synthesis of a lot of people's ideas gleaned from 
many forum postings - In some cases I am willing to defend particular 
aspects of the PEP, and in others I just write down what I think the 
general consensus is.)

That being said - from what I've read so far, the evidence on both sides 
of the argument seems anecdotal to me. I'd rather wait and see what more 
people have to say on the topic.

-- Talin

Aurélien Campéas wrote:
> On Tue, Jun 19, 2007 at 08:20:25AM -0700, Guido van Rossum wrote:
>> 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.
> 
> Thanks to raise this. It is horrible enough that I feel obliged to
> de-lurk.
> 
> -10 on this part of PEP3101.
> 
> 
>> Please keep further discussion on the python-3000 at python.org list.
>>
>> --Guido
>>
>> On 6/19/07, Chris McDonough <chrism at plope.com> 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.
> 
> People talking about potential security issues should have an
> obligation to show how their proposals *really* improve security (in
> general); this is of course, a hard thing to do; mere hand-waving is
> not sufficient.
> 
>>> 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.
> 
> And it's even poorer in the context of a language (for it's probably
> harder to escape language-level restrictions than framework
> obscurities ...).
> 
>>> 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".
> 
> This is trying to make a technical argument, but the 'consenting
> adults' policy might be enough. In my experience, zope forbiding
> access to _ prefixed attributes just led to work around the
> limitation, thus adding more useless indirection to an already crufty
> code base. The result is more obfuscation and probably even less
> security (as in auditability of the code).
> 
>>> 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.
> 
> FWIW I've come to never use __attrs. The obfuscation feature seems to
> bring nothing but pain (the few times I've fell into that trap as a
> beginner python programmer).
> 
>>> 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.
> 
> I'd add that Zope in general looks to me like a giant collection of
> python anti-patterns and as such can be used as a clue source about
> what not to do, especially what not to include in Py3k.
> 
> I don't want to offense people, well no more than necessary (imho zope
> *is* an offense to common sense in many ways), but that's the opinion
> from someone who earns its living mostly from zope/plone products
> dev. and maintenance (these days, anyway).
> 
> Regards,
> Aurélien.
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/talin%40acm.org
>