t> I think this is, mutatis mutandis, exactly the same disagreement we had
t> over the desirability of accessing matched substrings (after a regexp
t> search) via symbolic names instead of via snaky little integers --
I agree with Tim on this point. Symbolic access is much better than
those silly little integers. Consider trying internationalize a
Python program. I'll use dates as an example, but I'm sure you can
see how this generalizes. Dates in the U.S. are usually written as
mm/dd/yy while in europe they are written as dd/mm/yy. So wouldn't it
be nice to be able to write:
print message % {'month':10, 'day':13, 'year':89}
where message is somthing that was read out of a local or language
specific database and contains somthing that looks like:
'the date is %(month)/%(day)/%(year)'
or
'the date is %(day)/%(month)/%(year)'
(On an unrelated point, why wasn't the % operator added as an
overloadable operator for all sequences. I can think of some real
neat uses... especially in user defined classes... and my cons cells object)
> My problem with Perl-style 'here' documents remains that it is a very
> un-Python-like piece of syntax (how's that for an emotional argument:)
> and that I can't think of an "intuitive" operator, since << is already
> taken for left shift.
t> It's the _functionality_ that's important; fully agree that Python wants
t> a different syntax for it than Perl's.
I think my suggestion above is a nice compromise.
t> Staring at the "matched" example above (& some others) really does seem
t> to make an appealing case for stripping leading whitespace in one of the
t> versions. How about if the tripled double-quote version stripped leading
t> whitespace from each line, but translated '\t' to a non-stripped tab and
t> '\ ' to a non-stripped blank? E.g., the "matched" example could be the
t> less visually jarring
t> if not matched:
t> print """\
t> \ \ \ for '%s', please eyeball the original defn following, to
t> \ \ \ \ \ \ make sure it's compatible with its deduced size %d:
t> \ \ \ %s
t> """ % (name, size, origdef)
How about if the scan for initial white space stopped at the first
non-white character, regardless of whether it was the escape character.
if not matched:
print """\
\ for '%s', please eyeball the original defn following, to
\ make sure it's compatible with its deduced size %d:
\ %s
""" % (name, size, origdef)
This looks even more readable to me.
t> One thing I don't like about this is that Python doesn't do any
t> translation of '\ ' today, and it's Not Good for '\ ' to mean different
t> things in different kinds of strings.
A '\' followed by any character not otherwise interpreted should yield
that character.
t> The problem I hit is that I want to write a "substitute" function that
t> takes the string and does the substitution, but once I cross the caller/
t> callee boundary I can't get at the caller's namespaces. So substituting
t> for names of ordinary variables becomes a real puzzler, short of
t> explicitly building and passing a shadow dict of "interesting" names in
t> the caller. Got a better idea in mind?
Does my suggestion above help?
t> I hate to mention this, but I have sometimes wished for functions along
t> the lines of
t> uplocals(i)
t> upglobals(i)
I have never wanted them from within Python code, but have wanted them
inside C functions. Maybe I just didn't look enough but I have not
found an obvious way to do this. On a related note, how about having
module methods called with the module as the 'self' argument?
So much code... so little time...
--Don
______ ______
\_\_\_\ /#/#/#/
\_\_\_\ ______
\_\_\_V#/#/#/ Donald Beaudry don@vicorp.com
\_\_/#/#/#/ V. I. Corporation uunet!vicorp!don
\_/#/#/#/ 47 Pleasant Street PHONE: (413) 586-4144
V#/#/#/ Northampton, MA 01060 FAX: (413) 586-3805