. Python 2.1 function attributes
mbel44 at dial.pipex.net
Tue Feb 6 15:37:13 CET 2001
"Alex Martelli" <aleaxit at yahoo.com> wrote:
>> The real problem (IMO) with file.write("formatting"%(data)) is that
>> the expressions that build up the data are out of line with the static
>> content. Its harder for the programmer to visualize the bigger picture
>> of his output, because he has to mentally interleave the dynamic and
>> static parts. The problem is greater in functions whose only job is
>> output formatting.
>If the ONLY job is output formatting, then there are going to be
>no 'expressions' to speak of -- 'data' will be a dictionary that
>associates names with values, and the computation will have been
>done elsewhere -- a very sensible way to split computation from
>presentation tasks, of course. But then, where is the difference
>flob.write("An a %(one)s an a %(two)s an a %(three)s!\n" % data)
>print >> flob, "An a",one,"an a",two,"an a",str(three)+"!"
If your elements comes neatly packed in a dict, then yes thats true.
The % operator is adept at picking named elements out of your dict.
More commonly you need to pick the elements out of some other, equally
simple data structure:
print >> flob, "An a",things,"an a",things,"an a",things+"!"
print >> flob, "An a",things.pop(),"an a",things.pop(),"an
>It's true that a few more parentheses are needed for a write
>call, since Python syntax requires them (both around the
>whole %-expression, and inside the format-string when the
>RHS is a dictionary). But print>> requires a similar amount
>of commas, so it balances out; the _order_ in which the
>names are used is the same, and there are no "function names"
>vs "operators" involved, so the analogy is strained.
No, the analogy is about visual locality, not names. If your data
comes packaged in something other than a dict:
flob.write("An a %s an a %s an a %s!\n"%(one,two,three))
tdickenson at geminidataloggers.com
More information about the Python-list