From: John Keeping <john@keeping.me.uk>
To: Sverre Rabbelier <srabbelier@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH v3 2/8] git_remote_helpers: fix input when running under Python 3
Date: Wed, 23 Jan 2013 19:47:57 +0000 [thread overview]
Message-ID: <20130123194757.GQ7498@serenity.lan> (raw)
In-Reply-To: <CAGdFq_jp3BrS0zgDpmiXGduwu_m4E2CCL+X32P-7T=z9Qk-wuQ@mail.gmail.com>
On Wed, Jan 23, 2013 at 11:20:39AM -0800, Sverre Rabbelier wrote:
> On Sun, Jan 20, 2013 at 5:15 AM, John Keeping <john@keeping.me.uk> wrote:
> > Although 2to3 will fix most issues in Python 2 code to make it run under
> > Python 3, it does not handle the new strict separation between byte
> > strings and unicode strings. There is one instance in
> > git_remote_helpers where we are caught by this, which is when reading
> > refs from "git for-each-ref".
> >
> > Fix this by operating on the returned string as a byte string rather
> > than a unicode string. As this method is currently only used internally
> > by the class this does not affect code anywhere else.
> >
> > Note that we cannot use byte strings in the source as the 'b' prefix is
> > not supported before Python 2.7 so in order to maintain compatibility
> > with the maximum range of Python versions we use an explicit call to
> > encode().
>
> The three patches that deal with .encode() stuff (2, 7, 8) make me a
> bit uncomfortable, as they add some significant complexity to our
> python code. Is this the recommended way to deal with this (similar to
> the other patch where you linked to the python wiki explaining)?
The best I can offer is this:
http://docs.python.org/3/howto/pyporting.html#deal-with-the-bytes-string-dichotomy
Their recommendation is to use the b() function from the six project,
but given that we don't need it in too many places I prefer the approach
I took here to adding a thirdparty dependency.
> As one datapoint, it seems that it's actually Python 2.6 that
> introduces the b prefix.
>
> http://www.python.org/dev/peps/pep-3112/
>
> When did we last revisit what minimal python version we are ok with requiring?
I was wondering if people would weigh in discussing that in response to
[1] but no one has commented on that part of it. As another datapoint,
Brandon Casey was suggesting patching git-p4.py to support Python 2.4
[2].
[1] http://article.gmane.org/gmane.comp.version-control.git/213920
[2] http://article.gmane.org/gmane.comp.version-control.git/214048
John
next prev parent reply other threads:[~2013-01-23 19:48 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-20 13:15 [PATCH v3 0/8] Python 3 support for git_remote_helpers John Keeping
2013-01-20 13:15 ` [PATCH v3 1/8] git_remote_helpers: Allow building with Python 3 John Keeping
2013-01-23 18:49 ` Sverre Rabbelier
2013-01-20 13:15 ` [PATCH v3 2/8] git_remote_helpers: fix input when running under " John Keeping
2013-01-23 19:20 ` Sverre Rabbelier
2013-01-23 19:47 ` John Keeping [this message]
2013-01-23 20:14 ` Sverre Rabbelier
2013-01-23 20:36 ` Junio C Hamano
2013-01-25 20:23 ` Brandon Casey
2013-02-05 16:07 ` Erik Faye-Lund
2013-01-20 13:15 ` [PATCH v3 3/8] git_remote_helpers: Force rebuild if python version changes John Keeping
2013-01-23 18:51 ` Sverre Rabbelier
2013-01-20 13:15 ` [PATCH v3 4/8] git_remote_helpers: Use 2to3 if building with Python 3 John Keeping
2013-01-20 13:15 ` [PATCH v3 5/8] svn-fe: allow svnrdump_sim.py to run " John Keeping
2013-01-20 13:15 ` [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly John Keeping
2013-01-26 17:51 ` John Keeping
2013-01-26 21:44 ` Junio C Hamano
2013-01-26 23:32 ` [PATCH] git-remote-testpy: fix patch hashing on Python 3 John Keeping
2013-01-27 4:44 ` [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly Michael Haggerty
2013-01-27 5:30 ` Junio C Hamano
2013-01-27 14:21 ` John Keeping
2013-01-27 5:30 ` Sverre Rabbelier
2013-01-27 8:41 ` Michael Haggerty
2013-01-27 14:13 ` John Keeping
2013-01-27 14:50 ` [PATCH] git-remote-testpy: fix patch hashing on Python 3 John Keeping
2013-01-27 19:49 ` Junio C Hamano
2013-01-27 20:04 ` John Keeping
2013-01-27 20:11 ` Junio C Hamano
2013-01-27 20:21 ` John Keeping
2013-01-27 20:38 ` Junio C Hamano
2013-01-27 20:47 ` Junio C Hamano
2013-01-27 22:42 ` John Keeping
2013-01-27 23:18 ` Junio C Hamano
2013-01-28 10:44 ` Michael Haggerty
2013-01-28 11:20 ` [PATCH] fixup! git-remote-testpy: fix path " John Keeping
2013-01-28 17:53 ` Junio C Hamano
2013-01-20 13:15 ` [PATCH v3 7/8] git-remote-testpy: don't do unbuffered text I/O John Keeping
2013-01-20 13:15 ` [PATCH v3 8/8] git-remote-testpy: call print as a function John Keeping
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130123194757.GQ7498@serenity.lan \
--to=john@keeping.me.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=srabbelier@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).