fab-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fab-user] String interpolations


From: Jeff Forcier
Subject: Re: [Fab-user] String interpolations
Date: Wed, 13 May 2009 13:16:28 -0400

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]