git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Sverre RabbelierNext: Sverre Rabbelier
Message 6 of 38 in “Python 3 support for git_remote_helpers”
  1. 0/8 Python 3 support for git_remote_helpersJohn Keeping, Jan 20, 2013
  2. 1/8 git_remote_helpers: Allow building with Python 3John Keeping, Jan 20, 2013
  3. Sverre RabbelierJan 23, 2013
  4. 2/8 git_remote_helpers: fix input when running under Python 3John Keeping, Jan 20, 2013
  5. Sverre RabbelierJan 23, 2013
  6. John KeepingJan 23, 2013
  7. Sverre RabbelierJan 23, 2013
  8. Junio C HamanoJan 23, 2013
  9. Brandon CaseyJan 25, 2013
  10. Erik Faye-LundFeb 5, 2013
  11. 3/8 git_remote_helpers: Force rebuild if python version changesJohn Keeping, Jan 20, 2013
  12. Sverre RabbelierJan 23, 2013
  13. 4/8 git_remote_helpers: Use 2to3 if building with Python 3John Keeping, Jan 20, 2013
  14. 5/8 svn-fe: allow svnrdump_sim.py to run with Python 3John Keeping, Jan 20, 2013
  15. 6/8 git-remote-testpy: hash bytes explicitlyJohn Keeping, Jan 20, 2013
  16. John KeepingJan 26, 2013
  17. Junio C HamanoJan 26, 2013
  18. git-remote-testpy: fix patch hashing on Python 3John Keeping, Jan 26, 2013
  19. Michael HaggertyJan 27, 2013
  20. Junio C HamanoJan 27, 2013
  21. John KeepingJan 27, 2013
  22. Sverre RabbelierJan 27, 2013
  23. Michael HaggertyJan 27, 2013
  24. John KeepingJan 27, 2013
  25. git-remote-testpy: fix patch hashing on Python 3John Keeping, Jan 27, 2013
  26. Junio C HamanoJan 27, 2013
  27. John KeepingJan 27, 2013
  28. Junio C HamanoJan 27, 2013
  29. John KeepingJan 27, 2013
  30. Junio C HamanoJan 27, 2013
  31. Junio C HamanoJan 27, 2013
  32. John KeepingJan 27, 2013
  33. Junio C HamanoJan 27, 2013
  34. Michael HaggertyJan 28, 2013
  35. fixup! git-remote-testpy: fix path hashing on Python 3John Keeping, Jan 28, 2013
  36. Junio C HamanoJan 28, 2013
  37. 7/8 git-remote-testpy: don't do unbuffered text I/OJohn Keeping, Jan 20, 2013
  38. 8/8 git-remote-testpy: call print as a functionJohn Keeping, Jan 20, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.