Re: [PATCH v3 2/8] git_remote_helpers: fix input when running under Python 3
- From
John Keeping <john@keeping.me.uk>
- Date
- Jan 23, 2013, 19:47 UTC
- Message-ID
- <20130123194757.GQ7498@serenity.lan>
- 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:
Show 20 quoted lines
> 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.
Show 6 quoted lines
> 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