. Python 2.1 function attributes

Toby Dickenson 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
>between, e.g.,
>
>flob.write("An a %(one)s an a %(two)s an a %(three)s!\n" % data)
>
>and
>
>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[1],"an a",things[2],"an a",things[3]+"!"

print >> flob, "An a",things.pop(),"an a",things.pop(),"an
a",things.pop()+"!"


>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))



Toby Dickenson
tdickenson at geminidataloggers.com



More information about the Python-list mailing list