Re: [Fab-user] String interpolations

[Norman Harman]

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.

Sorry for adding nothing more than "me too" to the conversation.   
Fabric current rate of change is too much for me to keep up with.  Maybe 
when it stabilizes I'll have a deeper look and see if I might be able to 
add some code/convince people for it's need.

Christian Vest Hansen wrote:
> The syntax doesn't bother me that much. The thing I miss the most is
> the recursive resolution behaviour that the old lazy_format function
> exhibited. I had grown a habit of composing paths and filenames and
> other strings from many parts that themselves may have been composed
> of other parts. I still think that was a neat feature.
>
> 2009/5/13 Niklas Lindström <address@hidden>:
>   
> > Hi Jeff,
> >
> > amazingly quick response as usual! :) I also agree with your reasoning.
> >
> > I just wrote a very simple but "somewhat magic" fusion of my
> > suggestions. I just inline here for quick evaluation::
> >
> > -------------------- 8< --------------------
> > import sys
> > from string import Template
> > from fabric.api import env
> >
> > def fmt(s, *args, **kwargs):
> >    """
> >    This variable expansion utility attempts (using ``string.Template``) to
> >    substitute variable references in the supplied string. The order
> > of lookup is:
> >
> >    1. Keyword arguments (if any).
> >    2. Variables in the *calling* scope.
> >    3. A variable defined in fabric's ``env`` namespace.
> >
> >    Examples::
> >
> >        >>> fmt("$shell $notexpanded")
> >        '/bin/bash -l -c $notexpanded'
> >
> >        >>> shell = "local"
> >        >>> fmt("$shell $notexpanded")
> >        'local $notexpanded'
> >
> >        >>> fmt("$shell $notexpanded", shell="other")
> >        'other $notexpanded'
> >
> >        >>> fmt("$$shell $notexpanded", shell="other")
> >        '$shell $notexpanded'
> >
> >    """
> >    data = {}
> >    data.update(env)
> >    data.update(sys._getframe(1).f_locals)
> >    data.update(kwargs)
> >    return Template(s).safe_substitute(data)
> > -------------------- >8 --------------------
> >
> > One thing (good or bad depending on perspective) is that this makes it
> > possible to implicitly mix expansion and variables that should be left
> > for the target machine shell to expand. (You can always escape
> > variables with double-dollar to prevent *any* expansion on the fabric
> > side. Or if this behaviour should be enforced, replace
> > `safe_substitute` with `substitute`.)
> >
> > Perhaps something like it could end up in fabric.contrib?
> >
> > Best regards,
> > Niklas
> >
> >
> >
> > 2009/5/13 Jeff Forcier <address@hidden>:
> >     
> > > 2009/5/13 Niklas Lindström <address@hidden>:
> > >
> > >       
> > > > But I *really* dislike the arcane syntax, especially the trailing "s".
> > > > And at least my fabric scripts uses interpolation quite often, which
> > > > makes it very noisy IMHO.
> > > >         
> > > I totally agree about how current Python string interpolation is a
> > > little on the verbose side and could be easier to use (and that the
> > > newer format string stuff in 2.6+ looks pretty nice); but I don't
> > > think it's *bad enough* to merit adding a decent amount of extra
> > > complexity to Fabric. That was basically my thinking when I decided
> > > not to reimplement it in the 0.9 rewrite, and I still maintain it's
> > > the way to go.
> > >
> > >       
> > > > Another option might be e.g. adding a `fmt` method on env (placing it
> > > > in env to avoid the _getframe "hack"), and use `string.Template` in
> > > > that (available since Python 2.4). It could be used like:
> > > >
> > > >    run(env.fmt("cd $some_dir && cmd $a_dir"))
> > > >         
> > > I might be OK with this approach, however: adding a convenience
> > > function to do this special interpolation, which users may opt into
> > > using, and which is not sitting around cluttering up the rest of the
> > > code, would be more palatable than something with its fingers in the
> > > majority of all string-handling functions.
> > >
> > > Still think there needs to be a stronger argument for this existing --
> > > i.e. for a new user reading the docs, and coming across this, what
> > > will the docs say to justify the existence of such a function outside
> > > of "someone didn't really like the default string interpolation
> > > syntax"?
> > >
> > > But, if this were to be implemented in some fashion I would definitely
> > > at least consider putting it in, especially if other users would find
> > > it useful.
> > >
> > > Best,
> > > Jeff
> > >
> > >       
> > _______________________________________________
> > Fab-user mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/fab-user
> >
> >     
>
>
>
>   

___________________________________________________________________________
Only the Statesman has the scoop on stories and information
that matter to your life now more than ever. To add
the Statesman to your life and share your headline, go to
statesman.com/yourlife. Your Life. Your Statesman.