formatting (was Re: Perl is worse!)

[Alex Martelli]

"Steve Lamb" <grey at despair.rpglink.com> wrote in message
news:slrn8o9jn9.i9b.grey at teleute.rpglink.com...
> On Sun, 30 Jul 2000 16:29:42 +0200, Alex Martelli <alex at magenta.com>
wrote:
> >When the format string is expressed as an inline constant you can see it
in
> >place, but you don't have the other advantages (such as
>
>     Non-issue.  You were expressing your format string as a variable and
the
> same can happen with variables in line.

Issue.  Either the format-string and the variables are inline (you can see
them inplace) or they're fetched otherwise and kept (far from clear how,
if you have more than one thing, such as some pieces of formats, some
of variables, some more of formats, etc; lucidly obvious, with format-string
and [sequence|mapping] of values!), which gives you other advantages.

Things being immediately-obvious-inline tends to help with smaller
projects, beginning programmers, etc.  The other advantages accrue
increasingly to larger/functionally richer programs.  There may be
therefore a switch-over point, where one form or the other becomes
preferable.  A language may want to cover the whole spectrum.

Smaller/poorer programs, ones being worked on by beginners, etc,
tend not to require very accurate, nitpicky formatting.  For those
purposes, Python's print statement can be quite adequate -- and,
not unsurprisingly, it works exactly by the sequence-of-variables-
and-pieces-of-strings that beginners may find simpler, may be
more obvious in-the-small, etc.  When formatting needs get more
sophisticated, both sequence-oriented and namingtag-oriented
forms can come in handy -- and Python provides both.


> >When you end with % vars(), there is no substantial difference.
> >When you use the more substantial flexibility allowed by using
> >other mapping-objects, if that flexibility is needed, then the
> >advantages are many -- see above for a *beginning* to them.
>
>     No, there is no difference.  What you have is a format string with
named
> placeholders in-line.  You have to define the variables ahead of time.

There is absolutely no need to "define the variables ahead of time"
with either form of Python format-string.  The key issue is that _any
mapping object_ is just as acceptable as vars(), so no variables
need be defined unless you WANT to define them, either 'ahead of
time' or not.  All you need is to set up the associations tag->value
in the mapping-object, and you can do that any which way -- ahead
of time, just-in-time, a mixture of both.  FAR *more substantial
flexibility* than any language (fake, as in your examples, or true)
that ties you hand and foot to the one-and-only-mapping provided
by variablename->variablevalue.

>     I have the same.

No you don't, not even in the blue-sky, invented-and-modified-on-
demand fake-language you've been dreaming up as we go.  You
lack flexibility, because you're tied to a single mapping-object.


>     Difference is you still have to tack on the variables to the end,
> regardless of what form they take.

I have to specify what mapping-object I'm using each time (and
I have many ways to do that) in order to be able to use different
mapping objects in different cases.  When I'm using "the
variables", which appears to you to be the only mapping that
exists or can ever exist, I'm basically writing:

    formatstring %vars()

while you're writing

    formatstring someotheroperator

or you can make the otheroperator prefix instead of postfix,
etc, but you'd better have SOME way to say that formatstring
is to be subject to formatting -- having different kinds of strings
for formatting-operation and every-other-operation would be
very unwieldy, as well as flying right in the face of your "data
is data" stance, right?

Oops wait I forgot, that's exactly what your beloved Perl does,
isn't it?  'Ba$a at u%e' is a plain string without formatting, while
"Ba$a at u%e" (still 'data is data is data', innit?-) is a string to
which formatting ('interpolation', if I recall the terminology that
Perl uses) is implicitly applied.  So _in addition_ to this break
in your 'data is data, the operator commands anyway' stance,
you get the extra joy of figuring out different ways and means
to have formatting applied anyway after a normal string is
built up/fetched from somewhere/etc.  Can you spell "ad hoc"?-)


Python isn't beyond criticism here, by the way.  As an
alternative to the % _operator_, a named-function (to
be provided as a built-in) could perfectly well have been
chosen by our BDFL:

    format(formatstring, a, b, c)

or

    format(formatstring, vars())

isn't (IMHO) any less readable than the current

    formatstring % (a,b,c)

or

    formatstring % vars()

just _slightly_ more verbose, but, again IMHO, that slight
extra verbosity would be in a good cause.

I do not know why the % operator happened to be chosen
in preference to an explicitly-named 'format' built-in function
(and I confess to some curiosity in this regard; understanding
the design-rationale behind a language/framework/library is
often extremely helpful in using it to best effect, and of course
"I'm still an egg" in Python terms -- anybody _knows_...?).


> >That's what I would have liked to do, but often couldn't because
> >Perl might not be installed on some target-machines, sigh.  At
> >least, Bourne-shell could be counted on at the time.
>
>     Aside from Solaris pre-8, what is left that doesn't?

Just a zillion machines installed at about zillion/10 client sites,
I guess.  Remember we do commercial off-the-shelf software,
that is supposed to install and run, without needing our direct
involvement, on a huge variety of customer machines.  I can't
make Perl a pre-req (nor Python either, sigh) before scripts
that determine configuration, and set up other scripts that do
the actual installation, can run.

OK, these days installations are done with dedicated packages
(typically with proprietary scripting-languages so utterly weak as
to make one blank -- but I'm not the one having to write those
scripts nowadays, so, selfishly, I look the other way!-).  _After_
the installation, of course, whatever I know my app has installed,
I can use.  Whether installing a scripting-engine is worthwhile
depends on the amount of scripts in the application that could
take advantage of it, of course.


Alex