[PATCH v3 6/8] git-remote-testpy: hash bytes explicitly

2013-01-20 Thread John Keeping
Under Python 3 'hasher.update(...)' must take a byte string and not a unicode string. Explicitly encode the argument to this method to hex bytes so that we don't need to worry about failures to encode that might occur if we chose a textual encoding. This changes the directory used by git-remote-t

Re: [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly

2013-01-26 Thread John Keeping
Under Python 3 'hasher.update(...)' must take a byte string and not a unicode string. Explicitly encode the argument to this method as UTF-8 bytes. This is safe since we are encoding a Python Unicode string to a Unicode encoding. This changes the directory used by git-remote-testpy for its git m

Re: [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly

2013-01-26 Thread Junio C Hamano
John Keeping writes: > Junio, can you replace the queued 0846b0c (git-remote-testpy: hash bytes > explicitly) with this? > > I hadn't realised that the "hex" encoding we chose before is a "bytes to > bytes" encoding so it just fails with an error on Python 3 in the same > way as the original code

Re: [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly

2013-01-26 Thread Michael Haggerty
On 01/26/2013 10:44 PM, Junio C Hamano wrote: > John Keeping writes: > >> Junio, can you replace the queued 0846b0c (git-remote-testpy: hash bytes >> explicitly) with this? >> >> I hadn't realised that the "hex" encoding we chose before is a "bytes to >> bytes" encoding so it just fails with an e

Re: [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly

2013-01-26 Thread Junio C Hamano
Michael Haggerty writes: > This will still fail under Python 2.x if repo.path is a byte string that > contains non-ASCII characters. And it will fail under Python 3.1 and > later if repo.path contains characters using the surrogateescape > encoding option [1],... > Here you don't really need byt

Re: [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly

2013-01-26 Thread Sverre Rabbelier
On Sat, Jan 26, 2013 at 8:44 PM, Michael Haggerty wrote: > So to handle all of the cases across Python versions as closely as > possible to the old 2.x code, it might be necessary to make the code > explicitly depend on the Python version number, like: Does this all go away if we restrict ourselv

Re: [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly

2013-01-27 Thread Michael Haggerty
On 01/27/2013 06:30 AM, Sverre Rabbelier wrote: > On Sat, Jan 26, 2013 at 8:44 PM, Michael Haggerty > wrote: >> So to handle all of the cases across Python versions as closely as >> possible to the old 2.x code, it might be necessary to make the code >> explicitly depend on the Python version num

Re: [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly

2013-01-27 Thread John Keeping
On Sun, Jan 27, 2013 at 05:44:37AM +0100, Michael Haggerty wrote: > On 01/26/2013 10:44 PM, Junio C Hamano wrote: > > John Keeping writes: > >> @@ -45,7 +45,7 @@ def get_repo(alias, url): > >> repo.get_head() > >> > >> hasher = _digest() > >> -hasher.update(repo.path) > >> +has

Re: [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly

2013-01-27 Thread John Keeping
On Sat, Jan 26, 2013 at 09:30:00PM -0800, Junio C Hamano wrote: > Michael Haggerty writes: > > > This will still fail under Python 2.x if repo.path is a byte string that > > contains non-ASCII characters. And it will fail under Python 3.1 and > > later if repo.path contains characters using the