Closed qwindelzorf closed 11 years ago
Sorry about my slow response on this. This PR does not work as is for python2 and I really don't want to be decoding any more than we need to. Git stores raw bytes, even for filesystem paths. I cherry-picked some of your patches and put together an alternative, which is in jed/python3-win32-compat
. It works for me with python2.7 and python3.3. Could you try it on Windows and confirm that it works?
On Windows, I'm having issues any time data is run into a subprocess:
TypeError: Type str doesn't support the buffer API
Sprinkling yet more .encode('ASCII')
and .decode('ASCII')
commands seems to be helping, but I'm still working through all the places it complains.
Hmm, that error is usually when trying to pass unicode to something expecting bytes
. Are you getting something other than bytes
coming out of any of the streams? If so, could we fix it by unsure_binary_mode()
on those streams before reading from them?
It seems that the subprocess
module is expecting strings
throughout, but is usually being given bytes
. Part of this is because everything that comes out of os.path
seems to be bytes
.
When we call os.path.join
with bytes
, we should be getting back bytes
. Are you sure that we can't pass bytes
, something like the following?
subprocess.check_output([b'echo', b'hello'])
Note that subprocess
should always be outputting bytes
, regardless of how we pass arguments.
I have gone through git-fat and added support for Python 3.3. It mostly consisted of encoding fixes, since 3.3 now has strict string encoding requirements. I have done some testing on my machine, and it seems to be working correctly, but I have not tested across platforms or across versions of Python. It is entirely possible that these changes break 2.7 compatibility.
I have also rather expanded upon the test script to make it exercise a broader subset of the git-fat functionality. Those changes should be relatively benign, but may or may not be in line with your intent for the script.