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 8ECD26DE0222 for ; Thu, 30 Nov 2017 06:57:51 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-0.011] 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 ZsUa5C-XESWp for ; Thu, 30 Nov 2017 06:57:50 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by arlo.cworth.org (Postfix) with ESMTPS id 999B06DE0119 for ; Thu, 30 Nov 2017 06:57:50 -0800 (PST) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 75790F99B; Thu, 30 Nov 2017 09:57:49 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8AC322080C; Thu, 30 Nov 2017 09:19:57 -0500 (EST) From: Daniel Kahn Gillmor To: David Bremner , Floris Bruynooghe , Ruben Pollan , notmuch@notmuchmail.org Subject: Re: [PATCH] python: add bindings for notmuch_message_get_propert(y/ies) In-Reply-To: <87efofdgp8.fsf@tesseract.cs.unb.ca> References: <878tf5uvjm.fsf@fifthhorseman.net> <20171128224611.10712-1-meskio@sindominio.net> <87k1y97sor.fsf@fifthhorseman.net> <87tvxcepc0.fsf@devork.be> <87efofdgp8.fsf@tesseract.cs.unb.ca> Date: Thu, 30 Nov 2017 09:19:57 -0500 Message-ID: <87mv334zn6.fsf@fifthhorseman.net> 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: Thu, 30 Nov 2017 14:57:51 -0000 On Thu 2017-11-30 09:44:19 -0400, David Bremner wrote: > Floris Bruynooghe writes: > >> This also has the binary question problem, is this returned as bytes or >> as str? Current Python bindings seem to go for .decode('utf-8', >> errors='ignore') afaik which is somewhat lossy. >> > > IMHO there's no reason to support non-utf8 properties. We should > document this restriction now while adoption is relatively light. Agreed, my reading of the source is that we expect strings for both property names and property values. If they're both strings, we should not support anything other than UTF-8 in either case. --dkg