Zachary Pincus wrote:
> I'm not sure about introducing a special syntax for accessing
> dictionary entries, array elements and/or object attributes *within a
> string formatter*... much less an overloaded one that differs from how
> these elements are accessed in "regular python".
>
>> Compound names are a sequence of simple names seperated by
>> periods:
>>
>> "My name is {0.name} :-\{\}".format(dict(name='Fred'))
>>
>> Compound names can be used to access specific dictionary entries,
>> array elements, or object attributes. In the above example, the
>> '{0.name}' field refers to the dictionary entry 'name' within
>> positional argument 0.
>
>
> Barring ambiguity about whether .name would mean the "name" attribute
> or the "name" dictionary entry if both were defined, I'm not sure I
> really see the point. How is:
> d = {last:'foo', first:'bar'}
> "My last name is {0.last}, my first name is {0.first}.".format(d)
>
> really that big a win over:
> d = {last:'foo', first:'bar'}
> "My last name is {0}, my first name is {1}.".format(d['last'], d
> ['first'])
At one point I had intended to abandon the compound-name syntax, until I
realized that it had one beneficial side-effect, which is that it offers
a way around the 'dict-copying' problem.
There are a lot of cases where you want to pass an entire dict as the
format args using the **kwargs syntax. One common use pattern is for
debugging code, where you want to print out a bunch of variables that
are in the local scope:
print "Source file: {file}, line: {line}, column: {col}"\
.format( **locals() )
The problem with this is one of efficiency - the interpreter handles **
by copying the entire dictionary and merging it with any keyword arguments.
Under most sitations this is fine; However if the dictionary is
particularly large, it might be a problem. So the intent of the
compound name syntax is to allow something very similar:
print "Source file: {0.file}, line: {0.line}, column: {0.col}"\
.format( locals() )
Now, its true that you could also do this by passing in the 3 parameters
as individual arguments; However, there have been some strong proponents
of being able to pass in a single dict, and rather than restating their
points I'll let them argue their own positions (so as not to
accidentally mis-state them.)
> Plus, the in-string syntax is limited -- e.g. what if I want to call a
> function on an attribute? Unless you want to re-implement all python
> syntax within the formatters, someone will always be able to level
> these sort of complaints. Better, IMO, to provide none of that than a
> restricted subset of the language -- especially if the syntax looks and
> works differently from real python.
The in-string syntax is limited deliberately for security reasons.
Allowing arbitrary executable code within a string is supported by a
number of other scripting languages, and we've seen a good number of
exploits as a result.
I chose to support only __getitem__ and __getattr__ because I felt that
they would be relatively safe; usually (but not always) those functions
are written in a way that has no side effects.
-- Talin
_______________________________________________
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
