Current git branch in a zsh prompt

I've looked for hours to find a way to just display the current git branch in the prompt of my zsh shell and I've come to this more or less understandable solution which should work with any common VCS available:

autoload -U colors && colors
autoload -Uz vcs_info

zstyle ':vcs_info:*:prompt:*' formats "$VCSPROMPT" "[%b]"

precmd() {
vcs_info 'prompt'

if [ -n vcs_info_msg_0_ ]; then
RPROMPT="${vcs_info_msg_1_}"
else
RPROMPT=""
fi
}

PROMPT=$'%F{green}%~#%f '

The result is that the current working directory is shown on the left side and the name of the branch in braces on the right. I could probably configure it in a way which shows me a lot more information but all I want is a little reminder about the branch I'm currently in.

The current state of sphinx-py3k

I have not made a report in quite some time. I know I am supposed to make weekly reports but up until now I have not found anything really worth reporting at least since the last report. So what happend that you can find here one now?

I fixed every error in the test suite, which were about 55, now there are only 7 failures left. They might be even harder to fix then a usual error but I do not think this is going to be much of a problem.

What is a real problem are doctests. Currently there is no way of converting those automatically and even if there was there are certain problems like the change in the results. The representation of the string types has changed and some functions in the math module returns ints instead of floats were applicable and if you look around you can probably find more examples. A converter cannot deal with these changes easiely. I have some ideas on the problem but I will have to talk to my mentor about a solution.

GSoC: Scripts are (mostly) working

Looks like another week or so has ended which means a status report by me. Instead of porting Sphinx itself I took my time to port the scripts which are used to check the coding style and a couple of other things.

This means that there is no difference between developing Sphinx with 2.x or 3.x anymore as long as you ignore the errors and failures the test suite gives you when using 3.x.

There still are some problems with the reindent script which is in use. I got the latest one from the CPython svn, adjusted it a bit so it can be converted with 2to3 but for some reason it behaves differently with 3.x.

P.S.: You might have noticed that I changed the blog title, that is because I plan on publishing more non GSoC related posts and I think opening another blog is not worth it.

Progress on the 3.x Port

Since the beginning of the project I was able to remvove every deprecation warning which occurs when running the Sphinx test suite with python -3. Also it is now possible, using distribute, to install it using Python 3. However there are still several problems which do not cause any deprecation warnings and are not fixed by 2to3. So it is not usable for now.

The remaining problems are usually problems with handling strings and files. Even when used correctly in 2.x the changes made with 3.x are causing several problems.

I did nearly nothing during the last week in terms of coding so I will do a lot of work this weekend and make sure to have more time in the future.

Hashable or Unhashable: That is the question!

Python 3 has changed a lot of things, one of them being that if a class implements __eq__ the __hash__ method will not be inherited. This behavior seems weird at first but if you take a closer look at the topic it shows you a great problem.

Most Python developers do not really think about the design and behavior of an object when they create it, they have a class with an __init__ method, a couple of attributes and methods and may be a __repr__. If they implement other special methods they are usually __getattr__, __*item etc. but given an arbitary class you created could you tell me if it is supposed to be hashable or not and if it is supposed be hashable if it actually is?

Usually you do not care about __hash__ at all, you inherit from object which implements it and on CPython it returns the id of an object on other implementations it may be the same, it may be something different altogether but it is unique to the object.

This result of this is that everytime you create a type and you do not implement __hash__, objects of that type will be hashable even if it is not supposed to be. The worst case is that if you implement __eq__ but not __hash__, equal objects do not behave like equal objects when used as keys in dictionaries, if you put them into a set or if you do something else which relies on hashes as a way to check if objects are equal.

This results in two rules you should always stick to:
1. If you implement __eq__ also implement __hash__.
2. If your object is mutable, set __hash__ to None in order to make it unhashable, this way your object has the same behavior you expect from dictionaries or lists.

If you write new code stick to the rules and you are good to go in your old code make sure to implement those methods and you make it one step easier to port it to Python 3.

Congratulations! Your proposal has been accepted.

Yesterday Google released the list of accepted projects for GSoC, my project is one of them. In the next months I will be one of the three students working on Sphinx, my part will be porting Sphinx to Python 3.x and the integration of the web application which was developed during the last year.

Currently we are in the "Community Bonding Period" which means basically we are all idling in #pocoo to get in touch with the community and get an idea of the development process until May 24 which will be the day everybody starts coding. However as Sphinx is not such a big project at least in terms of the number of contributors, I think that spending so much time on "bonding" is a waste of time so I will probably start earlier.

So that's it for now. I will try to give you as much information as possible through blog posts in the future so everyone can easiely follow the progress.