eberle1080 / dulwich-py3k Goto Github PK

The Sha1Sum class is probably one of the biggest changes introduced in the port. It definitely needs some unit tests to make sure it works, since there are so many areas that rely on it working correctly.

Heh, just noticed a small potential memory leak in _objects.c introduced by yours truly:

Look right around Py_DECREF(key_string);

There are a number of places in the code (C, Python, and Makefile) that check the python version. I should make sure that the version numbers are correct, and that the checks are actually needed in python 3.

The main point of this particular fork. See https://bugs.launchpad.net/dulwich/+bug/883315.

This only covers the "pure" python implementation. The C extensions will need their own task.

It occurs to me that I'm using the default encoding when switching from bytes to strings, which is ASCII. Upon attempting to view "real-world" log entries, I'm getting all kinds of UnicodeEncodeError exceptions because the characters are out of range.

dulwich, I guess, will be using utf-8 as the default encoding until I see a compelling reason not to.

First of all, I need to add comments to my new stuff. That's just polite.

Secondly, there's one major change between python 2 and python 3 that will affect how this is called: Strings vs Bytes. In some places Strings are necessary (e.g. path names). In other places, Bytes objects are preferred. When to use each should be very clearly documented, and reflected in the documentation and comments.

Finally I suppose I should probably also document precisely what changed from 2 to 3, so that any future maintainers can make any necessary changes when porting from upstream.

The C python 3 C API has changed somewhat, mainly related to the strings / bytes calls. The C extensions can be deactivated for now, but eventually they'll need ported over too.

The committer is mandatory in your ported version of dulwich but according to the documentation:

"The committer and author will be retrieved from the repository configuration or global configuration if they are not specified"

(see http://www.samba.org/~jelmer/dulwich/docs/tutorial/repo.html last paragraph)

By default it seems that python 3 likes to use the ascii codec when you call decode. This is fine and good for us US users, but try running dulwich log on the dulwich project itself and see what happens (spoiler alert: there are utf8 characters in the commit logs, and no errors are thrown until you actually try to print the string).

There need to be unit tests that check that everything that could potentially be a unicode string, actually supports unicode (i.e. decode is being called correctly).

The port is finished, but it relies very heavily on decorators to do a lot of the heavy lifting. In particular, wrap3kstr and convert3kstr. These are simple wrapper methods I wrote (the first is a decorator) that transparently converts between String and Bytes objects.

They're very nice, and very necessary, but they slow things down considerably and make the code behave in a mysterious fashion (passing in a string may result in a bytes object being returned, hardly intuitive). I believe strongly in the principle of least astonishment, so I'd like to remove these things slowly, instead preferring explicit conversions and type checking (assertions?).

To support this, I've added a flag to the wrap3kstr decorator: enforcing=True. This does an assert on the type, rather than a conversion. This should allow me to slowly convert the calling code into something explicit, and eventually get rid of the decorators completely.