dploch added a comment.

  In https://phab.mercurial-scm.org/D2090#38775, @indygreg wrote:
  
  > Out of curiosity, do you think it would be possible to implement an option 
that behaved like a boolean when given in isolation but also optionally 
accepted a value? My use case is I want `hg serve --open` to automatically open 
a web browser pointing at the started server and `hg serve --open chrome` to 
open Chrome instead of my default web browser. I'm not sure if that's a good 
idea to implement in the parser though. It could possibly lead to ambiguous 
argument parsing.
  
  
  It feels like a bad idea.  If we want the parsing to be unambiguous, then 
'--open' must always come at the end of the command line if the default option 
is desired.  If there were a separate flag with the same semantics, you 
couldn't specify both:  'hg serve --open --foo' would pass "--foo" as the 
argument to --open.
  
  If we stipulate that the optional argument only counts as an argument if it 
doesn't look like a flag (^-(-)?[^\d-].*$), it sort of works, but that feels 
pretty messy.

INLINE COMMENTS

> indygreg wrote in fancyopts.py:258-261
> `isinstance()` is preferred here. Although the integer check could be a bit 
> wonky if Python 2's `long` ever comes into play.

It's actually wonkier than expected... :)

> indygreg wrote in fancyopts.py:313-317
> Oh, your code was copied from here. I suppose it is mostly OK then. Although 
> bringing this into modernity as part of the refactor wouldn't hurt...

Sure, modernized.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D2090

To: dploch, #hg-reviewers, durin42, indygreg
Cc: durin42, indygreg, mercurial-devel
_______________________________________________
Mercurial-devel mailing list
[email protected]
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to