[PATCH 1 of 4] tests: make 'f' tool open files in binary mode when hexdumping

Gregory Szorc gregory.szorc at gmail.com
Fri Nov 13 00:33:16 CST 2015


On Thu, Nov 12, 2015 at 8:01 PM, Matt Harbison <mharbison72 at gmail.com>
wrote:

> On Thu, 12 Nov 2015 22:24:57 -0500, Matt Mackall <mpm at selenic.com> wrote:
>
> On Mon, 2015-11-09 at 16:30 -0600, Matt Harbison wrote:
>>
>>> # HG changeset patch
>>> # User Matt Harbison <matt_harbison at yahoo.com>
>>> # Date 1447091371 18000
>>> #      Mon Nov 09 12:49:31 2015 -0500
>>> # Node ID 0b2b461f75b2c73adeb0728ed081c0222fc4f52e
>>> # Parent  f9984f76fd90e439221425d751e29bae17bec995
>>> tests: make 'f' tool open files in binary mode when hexdumping
>>>
>>
>> Queued for default, thanks. We need a checkcode rule for this.
>>
>
> That's probably beyond my regex capabilities if anyone else wants to
> attempt it.  Wondering how many different ways there are to open a file got
> me poking around in vfs, and it looks like abstractvfs.open() (and
> __call__) uses 'r' as its default mode.  I assume this is a (potential)
> problem?  Likely all of the current callers are providing an explicit mode.


I think 'r' as the default is a bit worrisome. In addition to the magic
newline handling, Python 3 returns str (unicode in Python 2) for 'r[t]' and
bytes for 'rb'. We'll almost certainly have to convert everything to use
'rb' for Python 3 compatibility.

As a personal practice, I always put 'b' or 't' in my open() modes to avoid
any ambiguity. I would softly suggest requiring one of the letters in in
abstractvfs.open() and __call__ to avoid any ambiguity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151112/6bb370cd/attachment.html>


More information about the Mercurial-devel mailing list