DomainKey-Signature: a=rsa-sha1; c=nofws; d=SSpaeth.de; h=from:to:subject
	:date:message-id:mime-version:content-type; q=dns; s=sspaeth.de;
	b=ODT/HFg+ysVXlPeA/yiL+TcTHbqr2o6lnGXaSbVqLOTiGIlAKVU/eKWauX52i
	wwHo8M31fIRGHyAg0L39agpKHx/VKg35rxI7qr4bhezZfAX3HhmFVaEcXQ18iVbY
	1qMzEcoZaW3lXhZzLsmjCpY8MhamKv98SOoEqHwwCWuZtA=
From: Sebastian Spaeth <Sebastian@SSpaeth.de>
To: Notmuch developer list <notmuch@notmuchmail.org>
Subject: [Justus Winter] Re: [PATCH 1/9] python: add a .gitignore file and
	refine the toplevel one
User-Agent: Notmuch/0.7-19-gee4579a (http://notmuchmail.org) Emacs/23.2.1
	(x86_64-pc-linux-gnu)
Date: Thu, 29 Sep 2011 18:06:42 +0200
Message-ID: <87r52z49kd.fsf@SSpaeth.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Precedence: list

--=-=-=

Here goes Justus's reply which he accidentally sent to me only.


--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <teythoon@jade-hamburg.de>
X-Original-To: Sebastian@SSpaeth.de
Delivered-To: sebastian--sspaeth.de@homiemail-mx7.g.dreamhost.com
Received: from diehard.dreamhost.com (caiajhbdcaib.dreamhost.com
 [208.97.132.81])	by homiemail-mx7.g.dreamhost.com (Postfix) with ESMTP id
 B9CF2CF6CD	for <Sebastian@SSpaeth.de>; Thu, 29 Sep 2011 03:37:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by diehard.dreamhost.com (Postfix) with ESMTP id B5BEF17BC062
	for <Sebastian@SSpaeth.de>; Thu, 29 Sep 2011 03:37:59 -0700 (PDT)
X-DH-Virus-Scanned: Debian amavisd-new at diehard.dreamhost.com
X-Spam-Flag: NO
X-Spam-Score: 1.1
X-Spam-Level: *
X-Spam-Status: No, score=1.1 tagged_above=-999 required=3
	tests=[SUBJECT_FUZZY_TION=1.1] autolearn=disabled
Received: from godfather.dreamhost.com ([208.97.132.5])	by localhost
 (diehard.dreamhost.com [208.97.132.157]) (amavisd-new, port 10024)	with ESMTP
 id 0B1H6zbuimbD for <Sebastian@SSpaeth.de>;	Thu, 29 Sep 2011 03:37:59 -0700
 (PDT)
Received: from mail.cryptobitch.de (cryptobitch.de [88.198.7.68])
	by godfather.dreamhost.com (Postfix) with ESMTP id 951FC1B0014
	for <Sebastian@SSpaeth.de>; Thu, 29 Sep 2011 03:37:44 -0700 (PDT)
Received: from mail.jade-hamburg.de (unknown [85.183.11.228])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.cryptobitch.de (Postfix) with ESMTPSA id 6F34F505C8B
	for <Sebastian@SSpaeth.de>; Thu, 29 Sep 2011 12:37:57 +0200 (CEST)
Received: by mail.jade-hamburg.de (Postfix, from userid 401)
	id C0CA5DF2A0; Thu, 29 Sep 2011 12:37:56 +0200 (CEST)
Received: from thinkbox.jade-hamburg.de (unknown [85.183.11.228])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: teythoon)
	by mail.jade-hamburg.de (Postfix) with ESMTPSA id B6AB6DF28B
	for <Sebastian@SSpaeth.de>; Thu, 29 Sep 2011 12:37:55 +0200 (CEST)
Received: from teythoon by thinkbox.jade-hamburg.de with local (Exim 4.76)
	(envelope-from <teythoon@thinkbox.jade-hamburg.de>)
	id 1R9E01-0005VB-5e
	for Sebastian@SSpaeth.de; Thu, 29 Sep 2011 12:37:53 +0200
In-Reply-To: <871uuzlrkt.fsf@SSpaeth.de>
References:
 <1316999137-28257-1-git-send-email-4winter@informatik.uni-hamburg.de>
 <871uuzlrkt.fsf@SSpaeth.de>
Subject: Re: [PATCH 1/9] python: add a .gitignore file and refine the toplevel
 one
To: Sebastian Spaeth <Sebastian@SSpaeth.de>
From: Justus Winter <4winter@informatik.uni-hamburg.de>
Date: Thu, 29 Sep 2011 12:37:53 +0200
Message-Id: <E1R9E01-0005VB-5e@thinkbox.jade-hamburg.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===-=-="

--===-=-=
Content-Type: text/plain; charset=utf-8


Hey Sebastian,

Quoting Sebastian Spaeth (2011-09-29 09:45:38)
>On Mon, 26 Sep 2011 03:05:29 +0200, Justus Winter wrote:
>
>#1) APPLIED
>#2) APPLIED
>#4) APPLIED
>#5&#6) APPLIED
>#9) APPLIED
>Thanks for the patches, most of them are quite nice. For 7&8, I'd like
>to hear more opinions.

Thanks :)

>#3) reorder the arguments of NotmuchError.__init__(): NOT APPLIED
>
>The python tutorial gives an example of custom TransitionError with
>three arguments, a custom message as the third. In addition, a STATUS
>value is always expected to be given, while the additional explanatory
>msg is optional, so STATUS makes for a more logical 1st parameter IMHO.
>Even if it were the case, it makes for lots of code churn, longer code
>(status=foo) to all Exceptions, and existing third party code would be
>broken. Overall, I think there is more potential for trouble than
>cleanup.

Well, #3 wasn't meant to be used standalone, I just wanted an intermediate
step in the refactoring process.

To address your concern wrt status being optional: I do consider code
doing 'raise NotmuchError(status=...)' to be wrong, one should raise
a more specific error in the first case.

>#7) NOT APPLIED, INPUT SOUGHT :)
>I do see the value of more fine grained exceptions, but I am not sure,
>we need this level of fine-grainedness. It would also make things more
>tricky (the API is still actively evolving, and e.g. 4 days ago, a new
>error status was added), so users of the bindings would now have
> +    NotmuchError,
> +    OutOfMemoryError,
> +    ReadOnlyDatabaseError,
> +    XapianError,
> +    FileError,
> +    FileNotEmailError,
> +    DuplicateMessageIdError,
> +    NullPointerError,
> +    TagTooLongError,
> +    UnbalancedFreezeThawError,
> +    UnbalancedAtomicError,
> +    NotInitializedError
>
> [...]
>
>to check where e.g. Xapian could also hide an Out of Memory.
Well, if the underlying API changes, the bindings will have to be
updated as well. What's wrong with that?

> Do people
>really want to catch, say UnbalancedAtomic errors specifically, rather
>than testing whether an operation succeeded, and check the status code
>if not? I could see the case for NotInitializedError, as that is a bit
>specific to the python bindings and users might want to catch it separately.

Well, those not interested in the exact nature of the failure can
still except NotmuchError as before. I also added the status code to
each class so that legacy style exception handling won't break.

(On second thought, we could also provide a .args property that issues
a deprecation warning when used to make the transition  even smoother.)

>Also, not all "status" are an error, e.g. DuplicateMessageId denotes
>success rather than failure, it just communicates a status.
Hm, I didn't knew that. This feels somewhat strange though.

If I were to design an API that uses an integer to indicate both
success and error, I'd reserve one bit indicating error so testing
for errors can be easily done by anding with a bitmask.

Cheers,
Justus
--===-=-=
Content-Type: application/octet-stream
Content-Disposition: attachment; filename=.signature
Content-Transfer-Encoding: base64

bG92ZSB1IGFsb3QgQCxACgo=
--===-=-=--

--=-=-=
Content-Type: multipart/signed; boundary="===-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"

--===-=-=


--===-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEUEARECAAYFAk6El5IACgkQVYX1jMgnoGJFygCY/edvrzAuYWYK0cuZBtacEtHX
LQCgha7pei3FoAc7FxAR0Uf3iiu8/U0=
=xsCn
-----END PGP SIGNATURE-----
--===-=-=--

--=-=-=--