On May 30, 2014 8:26 AM, "Ganesh Pal" wrote:
>
>
> Hello Python world ,
>
>
> I wanted suggestion on how to modify the below code to help me accomodate
the below two cases
Your question was answered already, but I'd like to point out that optparse
is deprecated. If possible, you should use argpar
Am Sa Mai 31 2014, 13:08:12 schrieb Ganesh Pal:
>> I think you have to do it manually:
>>
>> options, args = parser.parse_args()
>>
>> if options.object == "super_block" and options.path is not None:
>> parser.error("Paths not allowed for 'super_block' object")
>>
>> elif options.object ==
Ganesh Pal wrote:
> Hello Python world ,
>
>
> I wanted suggestion on how to modify the below code to help me accomodate
> the below two cases
>
> # Here is the Sample code.
>
> def main():
> """ ---MAIN--- """
> parser = optparse.OptionParser(usage='%prog [options] .]',
> version='1.0
On Fri, May 30, 2014 at 7:48 PM, Ganesh Pal wrote:
>
> Hello Python world ,
>
>
> I wanted suggestion on how to modify the below code to help me accomodate
> the below two cases
>
> # Here is the Sample code.
>
> def main():
> """ ---MAIN--- """
> parser = optparse.OptionParser(usage='%pr
Andy Kannberg wrote:
> I tried with the example Peter gave me, and it works. But only when the
> options are boolean. At least, that is my conclusion with experimenting.
> I'll elaborate:
>
> The code to create 'mutually exclusive options':
>
> option_names = [ "l", "o" , "s" ]
> toggled_optio
Hi all,
I tried with the example Peter gave me, and it works. But only when the
options are boolean. At least, that is my conclusion with experimenting.
I'll elaborate:
The code to create 'mutually exclusive options':
option_names = [ "l", "o" , "s" ]
toggled_options = [name for name in option
Andy Kannberg wrote:
> Hi python-guru's,
>
> I am new to Python, coming from a long history of Unix/linux shell
> programming.
> I am creating a Python script (In Python 2.6) which should be able to
> read command line options and arguments.
> So far, I figured out how to do that with optparse.
On Thursday, September 1, 2011 7:16:13 PM UTC-7, Roy Smith wrote:
> In article ,
> Terry Reedy wrote:
>
> > Do note "The optparse module is deprecated and will not be developed
> > further; development will continue with the argparse module."
>
> One of the unfortunate things about optparse an
Fulvio writes:
> Terry Reedy wrote:
>
> > Do note "The optparse module is deprecated and will not be developed
> > further; development will continue with the argparse module."
>
> Then,do you propose me to opt to argparse?
Without argument, yes; though for now it is opt-in.
--
\ “We are
Terry Reedy wrote:
> Do note "The optparse module is deprecated and will not be developed
> further; development will continue with the argparse module."
Then,do you propose me to opt to argparse?
--
Archlinux on $(uname -a) :P
F
--
http://mail.python.org/mailman/listinfo/python-list
In article ,
Terry Reedy wrote:
> Do note "The optparse module is deprecated and will not be developed
> further; development will continue with the argparse module."
One of the unfortunate things about optparse and argparse is the names.
I can never remember which is the new one and which i
On 9/1/2011 5:12 PM, Fulvio wrote:
I'm on python3.2, trying some experiment with OptionParser but no success
Do note "The optparse module is deprecated and will not be developed
further; development will continue with the argparse module."
--
Terry Jan Reedy
--
http://mail.python.org/mailm
On Thu, Sep 1, 2011 at 5:12 PM, Fulvio wrote:
> Hello,
>
> I'm on python3.2, trying some experiment with OptionParser but no success
>
> >>> from optparse import OptionParser as parser
> >>> parser.add_option('-n','--new', dest='new')
>
Here you've imported parser as an alias to the OptionParser
On Thu, Sep 1, 2011 at 3:12 PM, Fulvio wrote:
> Hello,
>
> I'm on python3.2, trying some experiment with OptionParser but no success
>
from optparse import OptionParser as parser
parser.add_option('-n','--new', dest='new')
> Traceback (most recent call last):
> File "", line 1, in
> F
Try this on your *nix command line: echo ">$100"
On a *nix command line, the '$1' part of ">$100" will be seen as 'give me the
value of the shell variable "1"', and since it has no value, will result in an
empty string. So it's not optparse, or Python, because the literal string you
intend to
tazz_ben wrote:
> So, I'm using optparse as follows:
>
> Command line:
> python expense.py ">$100" -f ~/desktop/test.txt
> ['>00']
>
>
> In Main:
>
> desc = ''
> p = optparse.OptionParser(description=desc)
>
> utilities = optparse.OptionGroup(p, 'Utility Options')
> utilities.add_option('--fi
In
tazz_ben writes:
> So, any ideas? Why is including a $ eating both the dollar signa and the 1?
Unix command lines tend to assume any $ inside double-quotes is a shell
variable name. Try enclosing in single-quotes instead.
--
John Gordon A is for Amy, who fell down the
To aid your googling, the problem is also commonly called 'Dispatching'
instead of 'Routing'.
Joost
On 14 December 2010 12:19, Joost Molenaar wrote:
> Many people have. :-)
>
> In the context of WSGI you're basically talking about routing
> middleware, which solves the problem: "given a request
Many people have. :-)
In the context of WSGI you're basically talking about routing
middleware, which solves the problem: "given a request, which
application should be called to construct a response?"
In my case, it turned out as simple as a list of (regex, resource)
tuples, where regex is a regu
On Thu, Aug 12, 2010 at 12:41, Robert Kern wrote:
> On 8/12/10 11:19 AM, J wrote:
>>
>> How do you use OptParse with constants?
> http://docs.python.org/library/optparse#standard-option-actions
>
> 'store_const' means that the option is a flag without arguments and stores
> the value provided by
On 8/12/10 11:19 AM, J wrote:
How do you use OptParse with constants?
Example:
usage = 'Usage: %prog [OPTIONS]'
parser = OptionParser(usage)
parser.add_option('-l','--level',
action='store_const',
default=LOG_INFO,
he
On Jun 28, 11:47 pm, rantingrick wrote:
> Give your *script* an
> enema, and do *yourself* a favor by harnessing the simplistic elegance
> of the "optphart" module instead!
>
> #-- Start Script --#
> def optphart(args):
> d = {'args':[]}
> for arg in args:
> if arg.startswith('-'):
On Jun 28, 9:56 pm, Ben Finney wrote:
> Michele Simionato writes:
> > optparse is so old-fashioned. Use plac!
>
> The OP should be made aware that:
>
> * plac is a third-party library with (TTBOMK) no prospect of inclusion
> in the standard library
>
> * optparse is in the standard library and
On Jun 28, 10:44 am, Michele Simionato
wrote:
> optparse is so old-fashioned. Use plac!
Hog wash! Both are archaic and asinine. Both clog your scripts with
wasted lines and your memory with complex interfaces far worse than
colon clogging junk food can hold a candle to. Give your *script* an
ene
Michele Simionato writes:
> optparse is so old-fashioned. Use plac!
The OP should be made aware that:
* plac is a third-party library with (TTBOMK) no prospect of inclusion
in the standard library
* optparse is in the standard library and has been for many versions
* argparse is a third-par
On Jun 28, 3:30 pm, dirknbr wrote:
> I get an int object is not callable TypeError when I execute this. But
> I don't understand why.
>
> parser = optparse.OptionParser("usage: %lines [options] arg1")
> parser.add_option("-l", "--lines", dest="lines",
> default=10, ty
On 28 June 2010 14:30, dirknbr wrote:
> I get an int object is not callable TypeError when I execute this. But
> I don't understand why.
> (snip)
> lines=options.lines
Here you are assigning the -l option to the name 'lines'.
> lines(args[0],topbottom=tb,maxi=lines)
Here you are attemptin
hiral wrote:
On Jun 8, 3:03 pm, Jean-Michel Pichavant
wrote:
hiralwrote:
Hi,
I am using optparser to do following...
Command syntax:
myscript -o[exension] other_arguments
where; extension can be 'exe', 'txt', 'pdf', 'ppt' etc.
Now to parse this, I am doing fol
On Jun 8, 4:30 pm, Hrvoje Niksic wrote:
> Thomas Jollans writes:
> > UNIX and GNU recommendations. I've never actually heard of optparser,
> > but I'd expect it to have the usual limitations:
>
> Hiralprobably meant to write "optparse", which supports GNU-style
> options in a fairly standard and
On Jun 8, 3:03 pm, Jean-Michel Pichavant
wrote:
> hiralwrote:
> > Hi,
>
> > I am using optparser to do following...
>
> > Command syntax:
> > myscript -o[exension] other_arguments
> > where; extension can be 'exe', 'txt', 'pdf', 'ppt' etc.
>
> > Now to parse this, I am doing following...
>
> >
Thomas Jollans writes:
> UNIX and GNU recommendations. I've never actually heard of optparser,
> but I'd expect it to have the usual limitations:
Hiral probably meant to write "optparse", which supports GNU-style
options in a fairly standard and straightforward way. Which includes
that defining
hiral wrote:
> Hi,
>
> I am using optparser to do following...
>
> Command syntax:
> myscript -o[exension] other_arguments
> where; extension can be 'exe', 'txt', 'pdf', 'ppt' etc.
>
>
> Now to parse this, I am doing following...
>
> parser.add_option("-oexe', dest=exe_file...)
> parser.a
On Jun 8, 10:38 am, hiral wrote:
> Hi,
>
> I am using optparser to do following...
>
> Command syntax:
> myscript -o[exension] other_arguments
> where; extension can be 'exe', 'txt', 'pdf', 'ppt' etc.
>
> Now to parse this, I am doing following...
>
> parser.add_option("-oexe', dest=exe_file..
hiral writes:
> Command syntax:
> myscript -o[exension] other_arguments
> where; extension can be 'exe', 'txt', 'pdf', 'ppt' etc.
It's more generally applicable to refer to that as a “suffix” for the
filename, and specify the full suffix including the full-stop (‘.’)
character.
What your ex
hiral wrote:
Hi,
I am using optparser to do following...
Command syntax:
myscript -o[exension] other_arguments
where; extension can be 'exe', 'txt', 'pdf', 'ppt' etc.
Now to parse this, I am doing following...
parser.add_option("-oexe', dest=exe_file...)
parser.add_option("-otxt', dest=t
On 2010-06-08 10:38, hiral wrote:
> Hi,
>
> I am using optparser to do following...
>
> Command syntax:
> myscript -o[exension] other_arguments
> where; extension can be 'exe', 'txt', 'pdf', 'ppt' etc.
>
>
> Now to parse this, I am doing following...
>
> parser.add_option("-oexe', dest=exe_file
Jean-Michel Pichavant wrote:
Carl Banks wrote:
On Oct 15, 10:29 pm, Mark Harrison wrote:
What's the magic to allow this? If the value is not specified I
would like to use the default value of 1.
import optparse
p=optparse.OptionParser()
p.add_option("--debug")
(opts, args) = p.parse_args(
Carl Banks wrote:
On Oct 15, 10:29 pm, Mark Harrison wrote:
What's the magic to allow this? If the value is not specified I
would like to use the default value of 1.
import optparse
p=optparse.OptionParser()
p.add_option("--debug")
(opts, args) = p.parse_args(['--debug=22']); print opts
(
On Oct 15, 10:29 pm, Mark Harrison wrote:
> What's the magic to allow this? If the value is not specified I
> would like to use the default value of 1.
>
> import optparse
> p=optparse.OptionParser()
> p.add_option("--debug")
>
> (opts, args) = p.parse_args(['--debug=22']); print opts
> (opts, ar
On 2009-05-20 16:50, Joseph Garvin wrote:
I'm working on a python script that takes several command line flags,
currently parsed by hand. I'd like to change the script to parse them
with OptionParser from the optparse module. However, currently the
script invokes a subprocess, and any flags the s
Ben Finney wrote:
> icarus writes:
>
>> parser = optparse.OptionParser(usage="%prog [-p dir] [--part=dir] ",
>> version="%prog 1.0")
>>
>> parser.add_option( "-p", "--part", dest="directory",
>>help="process target directory", metavar="dir")
>> (options, arg
icarus writes:
> parser = optparse.OptionParser(usage="%prog [-p dir] [--part=dir] ",
> version="%prog 1.0")
>
> parser.add_option( "-p", "--part", dest="directory",
> help="process target directory", metavar="dir")
> (options, args) = parser.parse_args(
On 2009-05-19 16:07, icarus wrote:
Why do I need to put two options for this script to print the path?
if I just specify the option and argument...
$ python
Robert Kern writes:
>> is there some way i can force the import based on the the absolute
>> path to the module?
>
> Better would be for you to copy the optparse.py module onto your
> Jython's import path. I'm not particularly familiar with the details
> of Jython, so you will need to consult
On 2009-02-10 17:32, Matthew Sacks wrote:
its a debian package. 2.5
importing optparse works with interactive python, but not through the
jython interpreter i an using.
Ah, yes. The current version of Jython is still based off of Python 2.2 whereas
optparse was introduced in Python 2.3.
is
its a debian package. 2.5
importing optparse works with interactive python, but not through the
jython interpreter i an using.
is there some way i can force the import based on the the absolute
path to the module?
On Tue, Feb 10, 2009 at 1:48 PM, Robert Kern wrote:
> On 2009-02-10 15:42, Matthe
On 2009-02-10 15:42, Matthew Sacks wrote:
it seems as if optparse isn't in my standard library.
How did you install your Python? It has been part of the standard library for a
very long time.
is there a way to add a lib like ruby gems?
http://docs.python.org/install/index.html
But optpar
it seems as if optparse isn't in my standard library.
is there a way to add a lib like ruby gems?
On Tue, Feb 10, 2009 at 1:38 PM, Tim Chase
wrote:
> Matthew Sacks wrote:
>>
>> does anyone have any arguments against optparse vs getopt
>
> I've found that the optparse module beats getopt on *every
Matthew Sacks wrote:
does anyone have any arguments against optparse vs getopt
I've found that the optparse module beats getopt on *every*
aspect except in the event that you have experience with the C
getopt libraries *and* just want something that behaves like
those libraries. Optparse is
On 2009-02-10 15:06, Matthew Sacks wrote:
does anyone have any arguments against optparse vs getopt
As the getopt docs say: "A more convenient, flexible, and powerful alternative
is the optparse module."
I have found all three statements to be true.
But I've found argparse to be even better
* Pat (Tue, 27 Jan 2009 14:04:28 -0500)
> >> I had no idea people were going to get so upset that I used a
> >> Windows example and go off on a tear.
> >
> > Nobody is upset, and nobody has "gone off on a tear". The point
> > about the "Windows example" is that the docs say in a
> > close-to-screa
On 2009-01-27 03:09, Johan Ekh wrote:
Thanks,
James I will try your suggestion!
Robert, what mean with "interactively" is that i would like to create an
array in the ipython shell, e.g. with m_i = array([1.0, 2.0, 3.0]) or
by reading a file with values etc., and then execute my program with
"mypr
Peter Otten wrote:
> Pat wrote:
>
>> The question was it possible to add a simple flag like 'd-' to optparse
>> with no other parameters?
>
> Do you mean "d-" or "-d"? If the latter, what's wrong with Robert Kern's
> answer?
>
I guess it got crowded out by the prima donnas anxious to help Pat
ph
Peter Otten wrote:
Pat wrote:
The question was it possible to add a simple flag like 'd-' to optparse
with no other parameters?
Do you mean "d-" or "-d"? If the latter, what's wrong with Robert Kern's
answer?
Peter
I mean "-d" since that's what Unix commands expect for flags.
My sole int
Pat wrote:
> The question was it possible to add a simple flag like 'd-' to optparse
> with no other parameters?
Do you mean "d-" or "-d"? If the latter, what's wrong with Robert Kern's
answer?
Peter
--
http://mail.python.org/mailman/listinfo/python-list
I had no idea people were going to get so upset that I used a Windows
example and go off on a tear.
Nobody is upset, and nobody has "gone off on a tear". The point about
the "Windows example" is that the docs say in a close-to-screamingly-
obvious manner that /options are not supported, no ma
Johan Ekh wrote:
> Thanks,
> James I will try your suggestion!
> Robert, what mean with "interactively" is that i would like to create an
> array in the ipython shell, e.g. with m_i = array([1.0, 2.0, 3.0]) or
> by reading a file with values etc., and then execute my program with
> "myprog -m m_i"
* John Machin (Tue, 27 Jan 2009 05:31:42 -0800 (PST))
> Nobody is upset, and nobody has "gone off on a tear". The point about
> the "Windows example" is that the docs say in a close-to-screamingly-
> obvious manner that /options are not supported, no matter what
> religion uses them. It was not, an
On Jan 28, 12:06 am, Pat wrote:
> Thorsten Kampe wrote:
> > * Pat (Mon, 26 Jan 2009 20:02:59 -0500)
> >> Up until today, I never needed to pass any arguments to a Python
> >> program.
> >> [...]
> >> getopt resolved my immediate need, but I would like to know how one
> >> could use optparse to ext
Thorsten Kampe wrote:
* Pat (Mon, 26 Jan 2009 20:02:59 -0500)
Up until today, I never needed to pass any arguments to a Python
program.
[...]
getopt resolved my immediate need, but I would like to know how one
could use optparse to extract out the options from something like "dir
/s /b".
If
If you mean with "/" as the option designator instead of "-": there
doesn't appear to be a documented way of doing it. You would have to
do some social engineering on the users to get them used to doing "dir
-s -b". In any case I thought the number of Windows users who know how
to fire up a Com
* Pat (Mon, 26 Jan 2009 20:02:59 -0500)
> Up until today, I never needed to pass any arguments to a Python
> program.
> [...]
> getopt resolved my immediate need, but I would like to know how one
> could use optparse to extract out the options from something like "dir
> /s /b".
If you actually r
Thanks,
James I will try your suggestion!
Robert, what mean with "interactively" is that i would like to create an
array in the ipython shell, e.g. with m_i = array([1.0, 2.0, 3.0]) or
by reading a file with values etc., and then execute my program with "myprog
-m m_i" and thus pass the array "m_i"
On 2009-01-27 00:01, Johan Ekh wrote:
Thank you James,
but I just can't optparse to accept an array, only integers, floats ans
strings.
My code looks like this
from optparse import OptionParser
parser = OptionParser()
parser.add_option('-t', '--dt', action='store', type='float',
dest='dt_i', de
On Tue, Jan 27, 2009 at 4:01 PM, Johan Ekh wrote:
> Thank you James,
> but I just can't optparse to accept an array, only integers, floats ans
> strings.
>
> My code looks like this
>
> from optparse import OptionParser
> parser = OptionParser()
> parser.add_option('-t', '--dt', action='store', ty
Thank you James,
but I just can't optparse to accept an array, only integers, floats ans
strings.
My code looks like this
from optparse import OptionParser
parser = OptionParser()
parser.add_option('-t', '--dt', action='store', type='float', dest='dt_i',
default=0.1, help='time increment where ls
On Tue, Jan 27, 2009 at 3:45 PM, Johan Ekh wrote:
> Thank you Robert,
> but what if I just want to create an array interactively, e.g. like m =
> array([1.0, 2.0, 3.0]), and pass it
> to my program? I tried extending optparse with a new type as explained in
> the link you gave me
> but I was not
Thank you Robert,
but what if I just want to create an array interactively, e.g. like m =
array([1.0, 2.0, 3.0]), and pass it
to my program? I tried extending optparse with a new type as explained in
the link you gave me
but I was not able to get it to work. Is it really neccessary follow that
rou
On Jan 27, 12:02 pm, Pat wrote:
> Up until today, I never needed to pass any arguments to a Python program.
>
> I did all the requisite reading and found that I should use optparse
> instead of getopt. I read the documentation and since the words
> "simple" and "easy" often appeared in the examp
> I did all the requisite reading and found that I should use optparse
> instead of getopt. I read the documentation and since the words
> "simple" and "easy" often appeared in the examples and documentation, I
> just knew that it would be a snap to implement.
I don't know where you got that. 'g
On 2009-01-26 19:02, Pat wrote:
Up until today, I never needed to pass any arguments to a Python program.
I did all the requisite reading and found that I should use optparse
instead of getopt. I read the documentation and since the words "simple"
and "easy" often appeared in the examples and do
On Tue, Jan 27, 2009 at 11:02 AM, Pat wrote:
(...)
> What does it take to pass single parameter to a program?
> http://docs.python.org/library/optparse.html stated that programs always
> have options. Is that so? What about "dir /s"?
Sample code:
#!/us
On 2009-01-26 17:44, Johan Ekh wrote:
Hi all,
I'm trying to use optparse to process command line parameters given to
my program.
It works as I expect for the types supported by optparse, i.e. int,
float, string etc. but how can I
pass a numpy.array or a list to my program?
http://docs.python.or
On Fri, 31 Oct 2008, Peter Otten wrote:
> John O'Hagan wrote:
> > Here's a strange one for you:
> >
> > I have a generator function which produces lists of numbers and takes
> > options which influence the output. The generator contains a loop, and to
> > enable the options to have a different valu
John O'Hagan wrote:
> Here's a strange one for you:
>
> I have a generator function which produces lists of numbers and takes
> options which influence the output. The generator contains a loop, and to
> enable the options to have a different value on each iteration, the
> options may themselves
I'm assuming you read at least some of the docs. This page makes it
pretty clear:
http://docs.python.org/lib/optparse-default-values.html
Matt
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, 16 Sep 2008 21:35:05 +0200, Torsten Mohr wrote:
> parser.add_option("-v", "--verbose",
> dest = 'verb',
> help = 'be loud',
> action = 'store_true',
> default = 'store_false')
>
> (opts, args) = parser.parse_args()
>
Hi,
> If i call it without any parameters i get:
>
> opts {'verb': 'store_false'}
> args []
If i call it with parameter -v i get:
./script.py -v
opts {'verb': True}
args []
I wonder what's wrong here.
Best regards,
Torsten.
--
http://mail.python.org/mailman/listinfo/python-list
Dan Halligan <[EMAIL PROTECTED]> writes:
> How would I pass a control character to python on the command line?
It depends on which command line you are using. Most Unix-like shells
will allow you to input a control character by preceding it with ^V.
Since \t is the TAB character, you should be a
Thanks for all the responses!
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, 19 Aug 2008 05:35:27 -0700, wannymahoots wrote:
> optparse seems to be escaping control characters that I pass as
> arguments on the command line. Is this a bug? Am I missing something?
> Can this be prevented, or worked around?
You are misinterpreting the evidence. Here's the short ex
On Aug 19, 10:35 pm, [EMAIL PROTECTED] wrote:
> optparse seems to be escaping control characters that I pass as
> arguments on the command line. Is this a bug? Am I missing
> something? Can this be prevented, or worked around?
>
> This behaviour doesn't occur with non-control characters.
>
> For
On Aug 19, 1:45 pm, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
> > optparse seems to be escaping control characters that I pass as
> > arguments on the command line. Is this a bug? Am I missing
> > something? Can this be prevented, or worked around?
>
> It has nothing t
[EMAIL PROTECTED] wrote:
optparse seems to be escaping control characters that I pass as
arguments on the command line. Is this a bug? Am I missing
something?
you're missing the distinction between the content of a string object,
and how the corresponding string literal looks.
>>> x = {'d
[EMAIL PROTECTED] writes:
> optparse seems to be escaping control characters that I pass as
> arguments on the command line. Is this a bug? Am I missing
> something? Can this be prevented, or worked around?
It has nothing to do with optparse, it's how Python prints strings:
$ python -c 'impor
Jeff Keasler <[EMAIL PROTECTED]> wrote:
> In a scripting environment, I often want to strip some of the command
> line options off the argument list, and then pass the remaining
> options to another module that is deeper in the tool chain.
The difficulty is that you can't do an accurate parse wit
Jeff Keasler wrote:
Hi,
optparse doesn't seem to have a pass-through capability for command line
parameters/options that were not registered with add_option.
I'm not the first person to complain about this. On Wed Mar 17 08:20:10
CET 2004, there's a thread titled "Perceived optparse shortc
Dan wrote:
> On Oct 24, 12:06 pm, Tim Chase <[EMAIL PROTECTED]> wrote:
>>> I've been using optparse for a while, and I have an option with a
>>> number of sub-actions I want to describe in the help section:
>>> parser.add_option("-a", "--action",
>>> help=\
>> [snipped for
On Oct 24, 12:06 pm, Tim Chase <[EMAIL PROTECTED]> wrote:
> > I've been using optparse for a while, and I have an option with a
> > number of sub-actions I want to describe in the help section:
>
> > parser.add_option("-a", "--action",
> > help=\
>
> [snipped formatted hel
> I've been using optparse for a while, and I have an option with a
> number of sub-actions I want to describe in the help section:
>
> parser.add_option("-a", "--action",
> help=\
[snipped formatted help]
> """)
>
> Unfortunately, when I run the script with --help, this
>> def format_option(self, option):
>> # The help for each option consists of two parts:
>> # * the opt strings and metavars
> [snip]
>
> Tim, I notice you're using lots of # lines as comments to describe the
> function. Perhaps you should consider using docstrings instead.
>
> Pard
On Sun, 30 Sep 2007 07:37:10 -0500, Tim Chase wrote:
> def format_option(self, option):
> # The help for each option consists of two parts:
> # * the opt strings and metavars
[snip]
Tim, I notice you're using lots of # lines as comments to describe the
function. Perhaps you should c
>> I've been learning the ropes of the optparse module and have been
>> having some trouble getting the help to format the way I want.
>
> A quick perusal of the 'optparse.py' code shows me this:
>
>
> [...]
> class OptionParser([...]):
> def __init__([...],
> format
Tim Chase wrote:
> I've been learning the ropes of the optparse module and have been
> having some trouble getting the help to format the way I want.
>
> I want to specify parts of an option's help as multiline.
> However, the optparse formatter seems to eat newlines despite my
> inability to find
Tim Chase <[EMAIL PROTECTED]> writes:
> I've been learning the ropes of the optparse module and have been
> having some trouble getting the help to format the way I want.
A quick perusal of the 'optparse.py' code shows me this:
[...]
class OptionParser([...]):
def __init__([...],
Thank you VERY much for mentioning argparse- this is EXACTLY what I needed!
Thank you!
On 8/23/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
>
> Omari Norman wrote:
> > On Mon, Aug 20, 2007 at 05:31:00PM -0400, Jay Loden wrote:
> >> Robert Dailey wrote:
> >>> Well, I don't know what is wrong with
Steven Bethard wrote:
> Omari Norman wrote:
>> On Mon, Aug 20, 2007 at 05:31:00PM -0400, Jay Loden wrote:
>>> Robert Dailey wrote:
Well, I don't know what is wrong with people then. I don't see how
required arguments are of bad design.
>>> I tend to agree...while "required option" may be
Omari Norman wrote:
> On Mon, Aug 20, 2007 at 05:31:00PM -0400, Jay Loden wrote:
>> Robert Dailey wrote:
>>> Well, I don't know what is wrong with people then. I don't see how
>>> required arguments are of bad design.
>
>> I tend to agree...while "required option" may be an oxymoron in
>> English,
On Mon, Aug 20, 2007 at 05:31:00PM -0400, Jay Loden wrote:
> Robert Dailey wrote:
> > Well, I don't know what is wrong with people then. I don't see how
> > required arguments are of bad design. Some command-line applications are
> > built around performing tasks based on information received. Comp
Robert Dailey wrote:
> Well, I don't know what is wrong with people then. I don't see how
> required arguments are of bad design. Some command-line applications are
> built around performing tasks based on information received. Compilers,
> for example. A compiler can't do much of anything unless y
1 - 100 of 153 matches
Mail list logo
