> > [tim, agonizing over a scheme to strip a well-defined amount of
> > leading whitespace from the lines in multi-line string literals]
> [don]
> 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.
Yes! I could only "live with" the suggestions I posted, but genuinely
like this one. It's _much_ more readable, and doesn't require changing
the meaning of backslash in general.
> A '\' followed by any character not otherwise interpreted should yield
> that character.
Well, regardless of merit, I think it's too late for that now. The
current behavior is frequently used to simplify producing input for other
tools that do follow the rule you like, and that "interpret" more
characters than Python does (e.g., not many existing Python regexps would
work if '\(' collapsed to '(' tomorrow).
> ... how about having module methods called with the module as the
> 'self' argument?
Not sure what this one's about. Example?
> > [uplocals, upglobals]
> 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.
Well, there is no obvious way to do it C <wink>.
In Python, Steve posted a way to do it that works for globals (at least
under today's implementation ... see earlier post for the full rant on
that).
For Python locals, it can't be done (in Python) today because locals
aren't generally stored in dicts anymore, and the key info you'd need to
_build_ a dict isn't accessible from Python (i.e., the "f_fastlocals"
member of a frame object isn't visible from Python; & I wouldn't want to
muck with frame objects even if it were ...).
> [motivation for example deleted]
> 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)'
Yes it would! Except in real life I bet the print statement would almost
always look like this instead:
print message % {'month':month, 'day':day, 'year':year}
where month, day and year are local variables. Really! If you're going
to give the January/February/... field the name "month" in the body of
the message, it's usually perverse (== unnecessarily convoluted) to name
the variable from which its value is taken anything other than "month";
and substituting a literal will be mighty rare (i.e., the dict _values_
will usually be variable names of _some_ kind).
And if you do usually give fields and the variables holding their values
the same name,
print message % this_funcs_local_dictionary
will be the most common case. So I'd be happy to code a substitution
function myself, via
def sub(msg, *dicts):
# a body that can't be written today
where dicts is an optional tuple of dictionaries defining the name->value
substitutions to be made, searched left to right with first hit winning,
and to which the caller's local (& maybe global too) namespace(s) is(are)
appended.
In the end, then, I'd normally write just
print sub(message)
But to do that, some way to get at the caller's local namespace is
needed. I could construct it by hand _in_ the caller and then pass it in
explicitly ("dir()" in a function returns a list of the func's locals'
names, from which a dict can be built; ironically enough, the
_implementation_ of dir() actually builds the whole dictionary, but
throws away everything except the keys ...) -- but that's really painful.
BTW, let me declare up front that I don't care how slow "sub" runs, so
writing it in Python (if it were _possible_ to write it in Python...) is
fine by me. Let's get the other side of that out of the way right now,
cuz those arguments make no progress beyond the initial declarations of
position:
To the contrary, the speed of "sub" or of my related better idea is of
crucial importance to me, my company/university, & my country, and to
everyone I know, correspond with, or am likely to meet in the future,
including but not necessarily limited to the remainder of my current
incarnation.
understatedly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp