From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id BB7016DE1105 for ; Sat, 30 Sep 2017 02:40:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[AWL=0.035, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyD8qb4P1z74 for ; Sat, 30 Sep 2017 02:40:29 -0700 (PDT) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) by arlo.cworth.org (Postfix) with ESMTPS id 6C30B6DE1101 for ; Sat, 30 Sep 2017 02:40:29 -0700 (PDT) Received: by mail-lf0-f47.google.com with SMTP id 23so1700186lfs.10 for ; Sat, 30 Sep 2017 02:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nikula-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=PpDjF5+Cs65xY0jJ8U5Exm7ufaBncHZzRUmakJNI0ow=; b=zGr7MdsvZnjXl1uPp4NGhBB2h0F9/Ecn45mcOvL05xDt6KJlrf2bAmhjfd0Iz+7ZjD qN+2i2+LNgREuo/tEE76tLdWOuQEGMKGdwPrTLkoMlJtZa/5bhHfJbrF6QeBetN/ocp6 CT8yhyJqA2TXT+mgb3guGJl1t39Fkyb2oNwlvBkoK9rbHh8S95fTWjyoR7RiTQXH2lq+ qBedYJ0heDUQ9gVLTOP0Xn1fBil7RR/O6DfEoAZ14OGsTizyco7KoZCM2APR0VqO0QPB bvnrXWnrWd8fR0me4yT8Ol+6BTrhcj9Wuu6XJ9bBtfQdLCyVdjs/10jphAbwCL6QQh2L NjwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=PpDjF5+Cs65xY0jJ8U5Exm7ufaBncHZzRUmakJNI0ow=; b=C3BaVRpl857gpDZ76/SV3O2Kg314eD0TZ43CM89O9gxABASEn1TZMWCwmbC1XFasHo 8kV4f+F2fVk5kcHgZHrZgnDxaI+q8OEEqGJXL1XZ2kszkBRBgcjTS0nd9a3UybAv1Ppm O5SWd8rhs+EL4FyLUXZniRgxwBv38f9zqQUbsS6QkpdmCCsIGv+yM75JvulF5cHKBIL8 jk2/6gJVJLu57CVI+21sUO2NKJiPtYTpEoAygcC5GrTgKrlUas3GAkNs0+//ZIYaB/aj HfcZzTXLbrS1mc/GTz30bSMhquIHELvZ0RrRgon59EInCmpc/D28VJnaZxvRnBiP6w8R o7OA== X-Gm-Message-State: AMCzsaVr5UBrJo2hbF9KT8ns7rgz0MEIUzWuJGoCqi1tkNfML0nD8Pn4 B8X2AgW3qaPXIyefi+/dMWKHDDxbazg= X-Google-Smtp-Source: AOwi7QA3/z9NrnsvRHFWhAugy90S9negcvDyYc3IrqAEoDB32b1CSRoTSNzcY+VV5p15ylcpWfNe8g== X-Received: by 10.25.40.196 with SMTP id o187mr1944523lfo.149.1506764427568; Sat, 30 Sep 2017 02:40:27 -0700 (PDT) Received: from localhost (mobile-access-5d6a60-234.dhcp.inet.fi. [93.106.96.234]) by smtp.gmail.com with ESMTPSA id u10sm1205134lju.84.2017.09.30.02.40.26 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 30 Sep 2017 02:40:26 -0700 (PDT) From: Jani Nikula To: David Bremner , Daniel Kahn Gillmor Cc: Notmuch Mail Subject: Re: [PATCH 0/9] argument parsing fixes and improvements In-Reply-To: <8760c65we5.fsf@tethera.net> References: <87mv5qxt3d.fsf@fifthhorseman.net> <87o9q5wlnj.fsf@fifthhorseman.net> <87k20st1yl.fsf@nikula.org> <87bmlz57wq.fsf@tethera.net> <8760c7x779.fsf@fifthhorseman.net> <8760c65we5.fsf@tethera.net> Date: Sat, 30 Sep 2017 12:40:23 +0300 Message-ID: <87tvzkr0c8.fsf@nikula.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 09:40:30 -0000 On Mon, 25 Sep 2017, David Bremner wrote: > Daniel Kahn Gillmor writes: >> So from an implementation point of view, it's definitely cleaner/simpler >> to have an internally "explicitly unset" state for the CLI flags. > > I'm trying to separate-out/defer impliementation questions here, at > least until I'm clear on the UI. Patches 1-5 and 8 in this series would be non-committal refactoring and cleanup in the mean time. ;) >> From a CLI UI perspective: do we want to be able to send --foo=default >> for a boolean explicitly? > > I have the feeling that maybe Jani does, but I'm not sure (as sometimes > happens) why my way of thinking about it isn't the only obvious way ;). I'm undecided. Definitely maybe. Going by "worse is better", the implementation *does* impact the decision, at least it impacts my opinion. For example, I don't think we'll open the database before argument parsing even if that turned out to be "the right thing". Looking at the defaults from another angle, if we don't want the ability to set --foo=default explicitly, I still think passing ints as booleans to the argument parser and checking if a boolean is neither true nor false is the wrong thing to do. I'd also like to convert to stdbool more. But those should not be a reason to convert essentially boolean arguments to keyword arguments. I think we need a way to have the argument parser tell us if an argument was present or not. BR, Jani.