Wrap a function

Sean DiZazzo half.italian at gmail.com
Thu Jan 28 15:18:26 EST 2010


On Jan 28, 12:13 pm, Joan Miller <pelok... at gmail.com> wrote:
> On 28 ene, 19:58, John Posner <jjpos... at optimum.net> wrote:
>
>
>
> > On 1/28/2010 2:24 PM, Joan Miller wrote:
>
> > > On 28 ene, 19:16, Josh Holland<j... at joshh.co.uk>  wrote:
> > >> On 2010-01-28, Joan Miller<pelok... at gmail.com>  wrote:
>
> > >>> I've to call to many functions with the format:
>
> > >>>>>> run("cmd")
>
> > >> Check the docs on os.system().
> > > No. I've a function that uses subprocess to run commands on the same
> > > shell and so substitute to bash scrips. But a script full of run
> > > ("shell_command --with --arguments") is too verbose.
>
> > I'm suspicious of your original intent. Essentially, you want to write
> > code in which a literal string, such as ...
>
> >    ls -l
>
> > ... is *not* enclosed in quotes. Why run the risk of creating confusion
> > (in other people who look at your code, in syntax-checking tools, etc.)
> > between variables and literals?
>
> Yes but to that code could be prepend a sign as '$' to be identified
> and so be parsed.
>
>
>
> > But I'm in sympathy with your desire to make the code as clean as
> > possible and to minimize the number of times you have to type a quote
> > character. My suggestions:
>
> > 1. Create a function (say, "Run") that encapsulates as much of the
> > syntax as possible: os.system(), subprocess.call(), string-splitting,
> > whatever. So an invocation would look like this:
>
> >    Run("ls -l *.txt")
>
> > (I think you've already done this step.)
>
> Yes, I made a funtion very cool to call to system commands, that works
> well with pipes and passes the variables (i.e. "LANG=C grep -e 'foo' /
> home")
>
> > 2. Find a text editor that supports keyboard macros, so that a single
> > keystroke turns this text line:
>
> >    ls -l *.txt
>
> > ... into this one:
>
> >    Run("ls -l *.txt")
>
> This is not what I'm looking for. I'm supposing that could be solved
> with a DSL or a macro library, any?

Python is not perl.

Thank God/Guido.



More information about the Python-list mailing list