Re: [Fab-user] String interpolations

[Christian Vest Hansen]

I took the liberty of modifying Niklas fmt function a bit:
 - added recursion
 - no more capturing locals; use the kwargs if need be
 - updated the doc-string to match the new behavior
 - removed unused *args argument

from string import Template
from fabric.api import env

def fmt(s, **kwargs):
    """
    Recursively interpolate values into the given format string, using
    ``string.Template``.

    The values are drawn from the keyword arguments and ``env``, in that order.
    The recursion means that if a value to be interpolated is itself a format
    string, then it will be processed as well.

    If a name cannot be found in the keyword arguments or ``env``, then that
    format-part will be left untouched.

    Examples::

        >>> fmt("$shell 'echo $PWD'")
        "/bin/bash -l -c 'echo $PWD'"

        >>> fmt("echo $$shell")
        'echo $shell'

        >>> fmt("a is ($a)", a="b is ($b/$c)", b=1, c=2)
        'a is (b is (1/2))'
    """
    data = {}
    data.update(env)
    data.update(kwargs)
    for k, v in data.items():
        if isinstance(v, basestring) and '$' in v:
            del data[k] # recursion base-case is empty map
            data[k] = fmt(v, **data)
    return Template(s).safe_substitute(data)



On Wed, May 13, 2009 at 7:16 PM, Jeff Forcier <address@hidden> wrote:
> On Wed, May 13, 2009 at 12:01 PM, Norman Harman <address@hidden> wrote:
>> That was absolutely a neat feature.  And I believe I read awhile back that
>> the lazy evaluation has been ditched as well.  That feature was so
>> fundamental to how I wrote modular flexible fabfiles that I can't consider
>> upgrading to a version that lacks it or equivalent functionality.
>
> It was removed because the lazy aspect (the 'only interpolated when
> the command actually runs' aspect) no longer makes sense for the new
> way Fabric operates; see an explanation here, if you haven't seen it
> yet:
>
>    http://docs.fabfile.org/compatibility.html#lazy-string-interpolation
>
> The side effect that Christian mentions (the ability to 'nest' the
> format strings so that they aren't necessarily all interpolated at
> time of string creation) was a casualty of that decision. Niklas'
> suggested use of the template string mechanism, with use of
> safe_substitute() specifically, could be one way to restore this.
>
>
> On Wed, May 13, 2009 at 12:17 PM, Curt Micol <address@hidden> wrote:
>>
>> Jeff,
>>
>> Was there a reason other than it wasn't 'pythonic' that the old
>> formatting was removed? I preferred the former interpolation also. It
>> was very convenient.
>
> That was the primary reason, along with the (perhaps not telegraphed
> well, apologies if so) idea that I wanted to strip out any
> non-essential features, even ones with marginal usefulness after the
> fact, and *then* -- if I misjudged their usefulness and people wanted
> them back in, as seems to be the case here -- *add them back in* in
> such a way as to work well with the newer codebase.
>
>
> With regards to the interpolation feature under discussion, I
> personally hadn't used it for the side effect, and saw it as being
> required for the 'broad' execution mode (as, at runtime from the
> user's perspective, the "current host" was not well-defined; see again
> the compatibility doc linked above) only.
>
> So, again, I'm OK with reinstating it in some form (especially as more
> folks have come out as finding it useful), but would still prefer a
> method/function opt-in approach as I mentioned in my replies to Niklas
> earlier. Having magical behavior on a large number of string-input
> parts of the code still strikes me as being messy and, well, magical.
>
> If many of you still feel that a function is insufficient / too much
> of a pain because you'd have to drop that function all over the place
> in your fabfile, I'd appreciate some concrete use cases just so I can
> wrap my head around how you all used to use, or would like to use,
> such a feature.
>
> Thanks,
> Jeff
>
> P.S., to cut the 2.6 offshoot discussion short: I'm definitely not
> interested in us jumping to 2.6 when making 2.5 the cutoff is hard
> enough, and I don't see any reason right now why the in-since-2.4
> string.Template mechanism would not suffice for any reimplementation
> of the string interpolation :)
>
>
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>



-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.

fmt.py
Description: Binary data