On Sep 29, 7:58 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> Carl Banks <[EMAIL PROTECTED]> writes:
> > On Sep 28, 6:19 pm, Ben Finney <[EMAIL PROTECTED]>
> > wrote:
> > > Steven Bethard <[EMAIL PROTECTED]> writes:
> > > > A user shouldn't have to go out of their way to specify regular
> > > > numbe
Carl Banks <[EMAIL PROTECTED]> writes:
> On Sep 28, 6:19 pm, Ben Finney <[EMAIL PROTECTED]>
> wrote:
> > Steven Bethard <[EMAIL PROTECTED]> writes:
> > > A user shouldn't have to go out of their way to specify regular
> > > numbers on the command line, regardless of whether they're
> > > positive
On Sep 28, 6:19 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> Steven Bethard <[EMAIL PROTECTED]> writes:
> > A user shouldn't have to go out of their way to specify regular
> > numbers on the command line, regardless of whether they're positive
> > or negative.
>
> A user shouldn't have to go out of
Steven Bethard <[EMAIL PROTECTED]> writes:
> A user shouldn't have to go out of their way to specify regular
> numbers on the command line, regardless of whether they're positive
> or negative.
A user shouldn't have to go out of their way to know whether what they
type on a command line will be t
Casey wrote:
> Ben Finney wrote:
>> I believe they shouldn't because the established interface is that a
>> hyphen always introduced an option unless (for those programs that
>> support it) a '--' option is used, as discussed.
>
> Not "THE" established interface; "AN" established interface. There
On Sep 27, 10:47 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> I believe they shouldn't because the established interface is that a
> hyphen always introduced an option unless (for those programs that
> support it) a '--' option is used, as discussed.
Not "THE" established interface; "AN" established
Ben Finney wrote:
> Casey <[EMAIL PROTECTED]> writes:
>
>> Well, it is a hack and certainly not as clean as having getopt or
>> optparse handle this natively (which I believe they should).
>
> I believe they shouldn't because the established interface is that a
> hyphen always introduced an opti
Casey <[EMAIL PROTECTED]> writes:
> Well, it is a hack and certainly not as clean as having getopt or
> optparse handle this natively (which I believe they should).
I believe they shouldn't because the established interface is that a
hyphen always introduced an option unless (for those programs t
On Sep 27, 7:57 pm, Neal Becker <[EMAIL PROTECTED]> wrote:
> One person's "brilliant" is another's "kludge".
Well, it is a hack and certainly not as clean as having getopt or
optparse handle this natively (which I believe they should). But I
think it is a simple and clever hack and still allows ge
Steven Bethard <[EMAIL PROTECTED]> writes:
> In most cases, argparse (http://argparse.python-hosting.com/)
> supports negative numbers right out of the box, with no need to use
> '--':
>
> >>> import argparse
> >>> parser = argparse.ArgumentParser()
> >>> parser.add_argument('-a', typ
Casey wrote:
> On Sep 27, 2:21 pm, "J. Clifford Dyer" <[EMAIL PROTECTED]> wrote:
>> If you can access the argument list manually, you could scan it for a
>> negative integer, and then insert a '--' argument before that,
>> if needed, before passing it to getopt/optparse. Then you wouldn't have
>>
Casey wrote:
> Is there an easy way to use getopt and still allow negative numbers as
> args?
[snip]
> Alternatively, does optparse handle this?
Peter Otten wrote:
> optparse can handle options with a negative int value; "--" can be used to
> signal that no more options will follow:
>
import
On Sep 27, 2:21 pm, "J. Clifford Dyer" <[EMAIL PROTECTED]> wrote:
> If you can access the argument list manually, you could scan it for a
> negative integer,
> and then insert a '--' argument before that, if needed, before passing it to
> getopt/optparse.
> Then you wouldn't have to worry about i
On Sep 27, 2:21 pm, "J. Clifford Dyer" <[EMAIL PROTECTED]> wrote:
> If you can access the argument list manually, you could scan it for a
> negative integer, and then insert a '--' argument before that,
> if needed, before passing it to getopt/optparse. Then you wouldn't have to
> worry about it
On Sep 27, 1:34 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
...
> >>> args
>
> ['-123']
>
> Without the "--" arg you will get an error:
>
> >>> parser.parse_args(["-123"])
>
> Usage: [options]
>
> : error: no such option: -1
> $
>
> Peter
Passing -a-123 works
>>> options, args = parser.parse_args(
, 2007 at 08:08:05PM +0200, Peter Otten wrote regarding Re:
getopt with negative numbers?:
>
> Casey wrote:
>
> > On Sep 27, 1:34 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
> >> optparse can handle options with a negative int value; "--" can be used
> >
Casey wrote:
> On Sep 27, 1:34 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
>> optparse can handle options with a negative int value; "--" can be used
>> to signal that no more options will follow:
>
> Thanks, Peter. getopt supports the POSIX "--" end of options indicator
> as well, but that seems
On Sep 27, 1:34 pm, Peter Otten <[EMAIL PROTECTED]> wrote:
> optparse can handle options with a negative int value; "--" can be used to
> signal that no more options will follow:
Thanks, Peter. getopt supports the POSIX "--" end of options
indicator as well, but that seems a little less elegant t
Casey wrote:
> Is there an easy way to use getopt and still allow negative numbers as
> args? I can easily write a workaround (pre-process the tail end of
> the arguments, stripping off any non-options including negative
> numbers into a separate sequence and ignore the (now empty) args list
> re
Is there an easy way to use getopt and still allow negative numbers as
args? I can easily write a workaround (pre-process the tail end of
the arguments, stripping off any non-options including negative
numbers into a separate sequence and ignore the (now empty) args list
returned by getopt, but it
20 matches
Mail list logo
