Google Code In at coala

Dear people!

coala participated in Google Code In thanks to FOSSASIA this year.

We have always been active in engaging newcomers and teaching people about Open Source. It is only natural that we think and work towards helping pupils all over the world take this step and learn about contributing to open source. (If you are a teacher and reading this, reach out to us on – we’re very interested in working with you and are also starting an initiative in germany to connect to schools.)

So let’s get some data: we had 37 successfully completed tasks. Our mentors wrote an impressive amount of 26 GCI tasks – some of which are multiple paged step by step guides that are still used for non GCI purposes.

Our star contributor Kaisar Arkhan is a GCI winner and Ridhwanul Haque made it as a finalist. We are proud of you! Kaisar Arkhan is actively helping us with our infrastructure to get greener every day!

An unimaginable huge part of the credit here goes to John Mark Vandenberg who mainly administered GCI for us and mentored a huge number of students by himself and helped us writing up the best possible tasks we could have. We are very thankful that we could build on his experience with the program and that we had his valuable input at every stage. Backstage, we had Mario Behling and Hong Phuc Dang from FOSSASIA working tirelessly so we could make this happen.

If you meet any of those – consider inviting them for a cup of coffee and thank them for what they are doing for our community, for FOSSASIA and for the Open Source education.

A Git Workflow for Humans


This blog post serves as a documentation for a Git workflow that I successfully use for my Open Source projects (e.g. coala) as well as my commercial clients. It’s focused on two things:

  • Code quality, because we need it. Otherwise our stuff will break.
  • Simplicity, because we’re humans and we don’t want to use something as complicated as Git flow. (I have seen a lot of people claiming to use Git flow, however when we talked about it it almost always turned out they don’t actually use it. :))

It gives general guidelines and I encourage people to change the workflow according to their special needs – however make sure that everything you do goes towards simplificy and quality and happens for a good reason.

The following paragraphs will define the most simple and minimal approach which is a base case of how this workflow works, the extensions paragraph defines some extensions which help you dealing with several common usecases. You will likely end up using the base workflow with one or two extensions.

The last paragraph will recommend some tooling which allows you to run this workflow more efficiently.

Base Workflow

Branch Names

Branch names are important because they influence how we think about the workflow. The main branch for Git repositories is master. Master is supposed to be always stable and the main point for developers to start with. The respect for a branch named master is higher than for e.g. develop and you will yield higher quality results by just naming it like that.

For development you will want to go with user owned branches. If I name my branches feature/newui, the name contains less information than me naming it sils/newui, sils being my user identification. Any developer knows who to contact if there is a stale branch or any problems – the owner of that branch.

As an owner of a branch, I can also reset my branch to a new commit that has nothing to do with the previous history. It’s my branch and it’s my responsibility.

Code Review

Great. I have my owned branch, I developed a crazy new thing and I want it to be in master! How does it work?

Do the natural thing. Submit a Pull Request, Merge Request, patches on BugZilla or whatever review UI you already use.

Start reviewing: my strong recommendation is to make good commits and review every commit on it’s own. Make sure that every commit only changes one thing and is as small as possible. Reviewers will find more bug and you will have saved a lot of time on the long run. “Reduce technical debt.” Of course you will also want to use continuous integration and code analysis on your project to save you lots of review time and enable people to find and fix issues earlier. You can use the git rebase –interactive for fixing up your commits – don’t be afraid, after you lean it once it’ll come in handy in a lot of situations.

Many workflows would now propose to do a merge commit. I recommend to do a fast forward or implement a semi-linear workflow – why? If you worked with merge commits for a longer time you probably saw failing builds on master or other critical branches even if you had CI on all branches – merge commits are changes. If you don’t review them (and that’s a hard thing to do) they may bite you. What does this mean?

Before doing a merge you have to rebase your commits onto the latest version of master. The continuous integration will be retriggered and your builds verify your code again. You should also check manually if the commits you added underneath your existing ones could do any harm! After doing that you can either do a fastforward (git merge –ff-only) or a merge commit (git merge –no-ff) if you want to keep history of your PRs/MRs. I recommend doing the fastforward and thinking in changes, not in features. This purely psychological thing can change the way you develop source code. Your builds will not fail of deterministic reasons anymore.


I recommend doing continuous releases from your master branch. Either push your website to your server or your package as a prerelease to PyPI.

If you manually want to trigger releases, set up your CI to do it for you on your command right from master. (E.g. using the “when: manual” in GitLab CI or when tagging a commit.)

If that is sufficient for you, you won’t need any other branch than master and user owned branches.


The following paragraphs explain how you can extend your workflow.

Hotfix Branches

You may have the need to be able to fix any production issues really quickly. You will want to bypass code review. You might even want to bypass continuous integration. The solution is simple:

Just set up automatic deployment for hotfix/… branches.

The most important thing however is not to use master! Master is always stable and reviewed. You deploy a hotfix *temporarily* and pause all other development until a clean equivalent of the hotfix is merged/fastforwarded to master. This way you don’t get your master broken but you’ll be able to temporarily deploy potentially dirty hacks when needed.

Release Branches

If you want to maintain bugfix releases featuring only selected bugfix commits you will want to branch off a release/… branch when doing a release. Usually you’ll want to name it after the major and minor but not include the micro as your branch will move over your micro releases. (E.g. release/0.8 is good.) Whenever you want to do a bugfix release, just cherry pick your commits onto that branch and trigger a release when needed.

Apply the same code review policies as for master. Doing automatic prereleases may be awesome for the people using your software, being able to get the latest stuff from master in no time.


Long story short: keep away from GitHub. GitHub forces you into their workflow using merges, cluttering history, compromising your code quality (at the advantage of being a bit simpler for them to implement and for you to use).

The best tool I found so far for this is the GitLab Enterprise Edition, which is sadly not free software. The recommended setup is:

  • Protect the master branch. Nobody can push. Everybody can merge.
  • Allow merges only when builds pass.
  • Allow merges only when at least one (potentially more) nonauthor approved a merge request.
  • Set merges to fastforward only. GitLab will offer coders a rebase button even so you don’t have to do it manually every time.
  • Automatic deployment or when: manual for master/release/hotfix branches.
  • Set up GitLab CI to build your stuff and test it, if you’re deploying with docker, test in docker!
  • Use static code analysis like coala in your GitLab CI.
  • Enforce a minimal test coverage, ideally your coverage should always grow or stay. That’s a good way to handle legacy projects as well as mature well tested ones.


Hi again!

I had the pleasure of visiting GUADEC this year again.

A lot of great things happened – as always GUADEC with it’s perfect size got me to speak to a hell lot of new and interesting people. Thank you all for being there – it was a pleasure.

Most of all, GUADEC has brought me to consider running GitMate as a consultancy business. The decision has not been done yet but it’s a viable option that we didn’t really consider yet for some reason.

Among other things I had the pleasure to moderate the interns lightning talks as well as the regular ones and present my annual coala lightning talk as well. My full talk about growing open source communities is available at Youtube and the CCC.

Seeing forward to next year – cheers! /></p>
									</div><!-- .entry-content -->
			<footer class=

That’s it, folks!

So this is it. The end of my Google Summer of Code. An amazing 12 weeks of working on a real project with deadlines and milestones.

Thanks, awesome mentor!

First and foremost, I would like to thank my mentor [Mischa Krüger] for his constant guidance and support through the tenure of my project.

Thank you for clarifying my trivial issues that were way too trivial. Thank you for clearing my doubts on the design of the classes. Thank you for writing a basic layout for a prototype bear. Thank you for understanding when I was not able to meet certain deadlines. Thank you Mischa for being an awesome mentor.

The Beginning

I was first introduced to coala in HackerEarth IndiaHacks Open Source Hackathon. I wanted to participate in it, so I took a look at the list of projects and saw coala. I jumped on their gitter channel and said hi. Lasse hit me back instantly, introduced me to the project, asked me to choose any newcomer issue, and my first patch got accepted in no time.

As the hackathon came to an end, it was time for organisations to start thinking about Google Summer of Code. By then, I had been taking part in regular discussions, and code reviews, Lasse asked me if I’d like to do a GSoC:

I slowly pivoted to choosing language independent documentation extraction as my GSoC project as I found it having greater depth than my other choices.

I feel privileged to be contributing to coala. The project itself is awesome in its entirety. I have contributed to my fair share of open source projects and I have never found any other project that is so organized and newcomer friendly. How coala is awesome should be itself another post.

About my project

Now to my project. As stated repeatedly in my past posts, my project was to build a language independent documentation extraction and parsing library, and use it to develop bears (static analyzing routines.)

How it all fits together

Most of the documentation extraction routines were already written by my mentor. Except a couple of tiny bugs, it worked pretty well. The documentation extraction API was responsible for extracting the documentation given the language, docstyle and markers and return a DocumentationComment object.

The DocumentationComment class defines one documentation comment along with its language, docstyle, markers, indentation and range.

My first task was to write a language independent parsing routine that would extract metadata out of a documentation i.e. description, parameter and return information. This resides inside the DocumentationComment class.

The point of this parsing library is to allow bear developers manipulate metadata without worrying about destroying the format.

I then had to make sure that I had support for the most popular languages. I used the unofficial coalang specification to define keywords and symbols that are used in different documentation comments. They are being loaded along with the docstyle.

Although I do not use the coalang stuff yet and still pass keywords and symbols manually, it will be used in future.

Lastly, I had to implement a function to assemble a parsed documentation into a documentation comment.

I separated this functionality into two functions:

  • The first function would take in a list of parsed documentation comment metadata and construct a DocumentationComment object from that. The object would contain the assembled documentation comment and its other characteristics. Note that this just assembles the inside of the documentation comment, not accounting for the indentation and markers.

  • The second function takes this DocumentationComment object and assembles it into a documentation comment, as it should be, taking account of the indentation and the markers.

Difficulties faced

  • The first difficulty I faced was the design of the parsing module itself. With the help of my mentor, I was able to sort that out. We decided on using namedtuples for each of the metadata:
Parameter = namedtuple('Parameter', 'name, desc')
ReturnValue = namedtuple('ReturnValue', 'desc')
Description = namedtuple('Description', 'desc')
  • If I wanted to make the library completely language independent, most settings would have to configurable to the end user. Initially I hardcoded the keywords and symbols that I used, but later the coalang specification was used to define the settings. They are yet to be used in the library.

  • While trying to use the above mentioned settings, I realized that the settings extraction didn’t work for trailing spaces. Since I had to have settings with trailing whitespace, I had to fix the extraction in the LineParser class.

What has been done till now


56e1802 DocumentationComment: Add language, docstyle param
72b6c9c DocumentationComment: Add indent param
bc4d7d0 DocumentationComment: Parse python docstrings
337b7c1 DocumentationComment: Parse python doxygen docs
99fa059 DocumentationCommentTest: Refactor
fc2e3bf DocumentationComment: Add JavaDoc parsing
12ede4f ConsoleInteraction: Fix empty line tab display
07135f5 DocumentationExtraction: Fix newline parsing
5df5932 DocumentationComment: Fix python parsing
f731ee4 DocumentationComment: Remove redundant code
e442dce TestUtils: Create load_testdata for loading docs
7de9aed LineParser: Fix stripping for escaped whitespace
31b0410 DocstyleDefinition: Add metadata param
edc67aa DocumentationExtraction: Conform to pep8
3a78aa9 DocumentationComment: Use DocstyleDefinition
dc35a0a DocumentationComment: Add from_metadata()
78ff315 DocumentationComment: Add assemble()
3c239d7 setup: Package coalang files


What lies ahead

The API still has a long way to go. A lot of things can be added/improved:

  • Maybe the use of namedtuples is not that efficient. I think classes should be used and subclassed from these namedtuples. This will allow the API to be way more flexible than it currently is, and also retaining the advantages with using namedtuple.

  • A cornercase in assembling #2645

  • Range is not being calculated correctly. #2646

  • The API is not using the coalang symbols/keywords. #2629

  • A lot of things are just assumed from the documentation while parsing. Related: #2143

  • Trivial: #2617, #2616

  • A lot of documentation related bears can be developed from this API.

It has been an awesome 3 months and an even more awesome 7 months of contributing to coala. That’s it folks!

Other projects.

Also, I want to talk about the projects of other students:

  • @hypothesist did an awesome job on coala-quickstart. The time saved in using coala-quickstart vs. writing your own .coafile is huge and this will lead to more projects using coala. He has also worked on caching files to speed up coala.

  • @tushar-rishav built coala-html! Its a web app for showing your coala results. He has also been working on a new website for coala.

  • @mr-karan did some cool documentation for the bears and implemented syntax highlighting in the terminal.

  • @Adrianzatreanu worked on the Requirements API.

  • @Redridge’s work on External Bears will help you write bears in your favourite programming language.

  • @abhsag24 worked on the coalang specification. We can finally integrate language independent bears seamlessly!

  • Thanks to @arafsheikh, you can now use coala in Eclipse.

Mischa Kruger

Mutable default arguments in Python

Recently, I came across an interesting feature in Python and thought I should share it with everyone.

Suppose we have a code snippet that looks like:

def func(default_immutable_arg="Hello",
key = 'some_key'
default_immutable_arg += "!"
if default_mutable_arg.get(key, None):
print("{key} exists".format(key=key))
print("{key} doesn't exist".format(key=key))
default_mutable_arg[key] = "some_value"
for i in range(3):

Before reading further, please stop and go through the code snippet carefully.

Now, What output do you expect from the above snippet? There is a high probability (unless you are a Python wizard!) that you might expect the output to be

Hello! some_key doesn't exist
Hello! some_key doesn't exist
Hello! some_key doesn't exist

Well, if that’s what you expected, then you are wrong!

The correct output is

Hello! some_key doesn't exist
Hello! some_key exists
Hello! some_key exists

Interesting isn’t it? Let’s dig a little deeper and find out why this happens.

Perhaps, it’s quite known now.

Expressions in default arguments are calculated when the function is defined, not when it’s called.

Before I explain further, let’s verify the above statement quickly:

import time
def time_func(arg=time.time()):
return arg
print [time_func() for _ in range(3)]

For me the output looks like

[1471723451.85, 1471723451.85, 1471723451.85]
# Notice the exact same timestamps here.

Clearly, arg was calculated when time_func was defined and not when it’s called otherwise you would expect arg to be different each time it’s executed.

Coming to our func example. When def statement is executed a new function object is created, bound to the name func and stored in the namespace of the module. Within the function object, for each argument object with a default value, an object is created that holds the default value.

In the above example, a string object (“Hello!”) and an empty dictionary object is created as a default for default_immutable_arg and default_mutable_arg respectively.

Now, whenever func is called without arguments, the arguments will use the values from their default bounded object i.e default_immutable_arg will always be “Hello!” but default_mutable_arg may change. It’s because of the fact that string objects are immutable whereas a dictionary objects are mutable. So whenever in line 4, we append “!” to default_immutable_arg, a new string object is created and returned which is then printed in next line, keeping default string object’s value still intact.

This isn’t the case with mutable dictionary objects. The first time we execute func without any arguments, default_mutable_arg takes its value from default dictionary object which is {} now. Hence, the else block will be executed. Since the dictionary objects are mutable, the else block changes the default dictionary object. So in the next execution of the function, when default_mutable_arg reads from default dictionary object, it receives {'some_key':'some_value'} and not {}. Interesting huh? Well that’s the explanation! :)


Don’t use the mutable argument objects as default arguments! Simple! So how do we improve our func ? Well, just use None as default argument value and check for None inside function body to determine if the arguments were passed or not.

def func(default_immutable_arg="Hello",
default_mutable_arg = ({} if default_mutable_arg is None
else default_mutable_arg)
# rest is same..

Now, you can imagine what would happen if we overlook this feature in defining class methods. Clearly, all the class instances will share the same references to the same object which isn’t something you’d want to have in the first place! :)

I hope that was fun,


Final Submission

This program was one of the best learning experiences I’ve ever had. During the entire GSoC phase i was able to contribute to mainly two repositories of the coala organisation, A sub org under the Python Software Foundation.

These include commits on the coala repository:

and the coala-bears repository:

coala-bears also contains a branch which hasn’t been merged into master yet, All my commits on this branch can be found here:

I’ve been really grateful to my mentor Fabian, and the admin of my sub-org, Lasse, I’ve had the most enriching discussions with these people😀 , Cheers to coala, FOSS and the entire GSoC experience,  i’ll definitely look forward to working beside these people after the program as well.

GSoC’16 final report


Alright folks. It’s officially an end to the amazing 12 weeks of Google Summer of Code 2016! These 12 weeks have certainly helped me become a better person, both personally and professionally. I’ve had a chance to interact and learn from some very interesting and amazing minds from coala. Sadly, I couldn’t meet all but a few of them during the EuroPython conference this summer.


First and foremost, I would like to pay my eternal gratitude to my mentor Attila Tovt who patiently helped me improve the patch through multiple reviews. I was learning something new with each iteration. The major take away for me from his mentorship would be:

There is always a hack to something, then there is a solution to it.

Sadly, I couldn’t meet him during EuroPython conference, but I am hopeful to pay my regards in person someday! :)

Next, I must thank Abdeali for helping and guiding when I started my journey with coala and also Lasse Schuirmann. Well after all he is coala’s BDFL! Wondering what that means? Benevolent Dictator for Life :D

Hmm, on a serious note, if I say I am going to continue contributing to coala or any other FOSS that I may come across in future, one of the major reasons and an influencer would be Lasse! The guy is totally amazing. I don’t think anything else could describe him better than his own words that he said during EuroPython’16

Guys! Don’t just be a participant. It’s boring! Be and create a conference!

Impressive isn’t it? That’s Lasse for you! :)

I would also thank fellow GSoC students and now my new friends - Adrian, Adhithya, Alex, Karan, Araf, Sanket and Abhay. I look forward to stay in touch with them even after GSoC! :)

Last but far from the least, thanks to Max for giving such a wonderful lightning talk at EuroPython’16, cooking for us with all love at Bilbao, for being such an amazing and wonderful person.

The acknowledgement must end with my gratitude to coala, Google and Python Software Foundation for giving me an opportunity to be a GSoC student in the first place.

Work history

Past summer, I’ve contributed and maintained coala-html and coala-website projects. The commits and live demos are available online.

Table 1
Project Commits Status
coala-html demo coala-html commits, total 49 commits completed
coala website repo and coala embedded in coala-website demo Mentioned in Table 2 It is almost complete, but requires improvement in design.
Table 2

Commits for coala website repository as Gitlab doesn’t support commit filtering by author yet.

Commit SHA Shortlog
244a0b Add coala config, .gitignore and README
f9242a Init setup with flask
36f064 server: Add editor and preloader
51ac6e bower.json: Use bower to install dependencies
ac3cdd beardoc: Display what coala can do interactively
dd4f27 layout.html: Add donation, about and sponsor
1b1efa index.html: Add gitter chat
f90513 bear-doc: Include bear-doc
597a2a Add contributors
9a3491 requirements.txt: Add python dependencies
432f4f Add Installation instructions
220020 sitemap: Add sitemap_template
bd31c1 editor.html: Add editor

Although GSoC period may end, my contributions to FOSS won’t! :)


coala GSoC 2016: Final Report


coala GSoC 2016: Final Report

Before I start on the work summary I would like to thank:

  • Lasse for introducing me to coala and helping me with (almost) any problem I had during this GSoC.
  • Udayan for being a cool guy with good humor (if I say so myself) as well as a good mentor.
  • Mischa for helping me with functional python, decorators and excellent reviewing.
  • Fellow GSoC students that I met at Europython, Adrian, Adhityaa and Tushar for the awesome community bonding.
  • Max because he has dreadlocks. Also the meaningful life teachings and the cooking.
  • Last but not least Google for the sponsorship.

Work Summary

I have several pull/merge requests across the different coala repos which I will list here with links so you can check them for yourself.

Pull/Merge Request Description Status
coala/2198 Add external_bear_wrap decorator Merged
coala/2407 Modify the JSON spec used by the decorator Merged
coala/2452 Migrate some libs to coala-utils Merged
coala/2460 Bump version for coala-utils Merged
coala/2583 Add external bear tutorial Pending
coala-bear-management/3 Extend tool to support external bears Merged
coala-utils/5 Refactor from coala-decorators to coala-utils Merged
coala-utils/7 Migrate StringConverter from coala core Merged
coala-utils/15 Modification for backwards compatibility Merged
coala-utils/19 Revert changes in yield_once as a fix Merged
coala-utils/20 Add open_files context manager Merged
coala-bears/617 Extend tool to support conda packaging Pending


The most important part of the project was to be able to write bears with other languages. I can proudly say that it is now possible to write such an "external" bear.

Some other achieved goals are:

  • Bear creation tool
  • External bear proof of concept with tutorial

Some work left to do:

  • Merge packaging tool extension
  • Add Diff handling to external bears

Now that we have come to an end I can say that the toughest challenge by far was the code merging process since coala has a very strict reviewing workflow.

Wrap Up

So that is it for GSoC 2016. It was an awesome experience in which I learnt a lot of stuff (not only programming related) and I met a lot of cool people. I would definitely recommend at least trying to join the program. Worst case scenario, you will have contributed to an open source community which I have explained from the very first post of my blog why it is important.

That's it from me, feel free to pm me about any questions related to the project (and not only) on the coala gitter channel.


GSoC ’16: Final Report

GSoC 2016 was one of the best things I've had the opportunity to participate in. I've learned so much, had a lot of fun with the community the whole time, got to work on something that I really like and care about, got the once-in-a-lifetime opportunity to visit Europe, and still get paid in the end. And none of this would have been possible without the support and help from the coala community as a whole. Especially Lasse, who was my mentor for the program, from whom I've learned so, so much. And Abdeali, who introduced me to coala in the first place and help me get settled in the community. It honestly wouldn't have been possible without any of them, and I really mean it. Seriously, thank you :)

List of commits I've made over the summer

The last three months have been action packed. Check 'em out for yourself:


Commit SHA Commit
b8d8349 Add tests directory for testing
df99516 py.test: Execute doctests for all modules
3d01aed Create coala-quickstart executable
28a33f9 Add coala bear logo with welcome message
759e445 generation: Add validator to ensure path is valid
111d984 generation: Identify most used languages
4ace132 generation: Ask about file globs
8f7fe23 generation: Identify relevant bears and show help
839fa19 FileGlobs: Simplify questions
7c98e48 Settings: Generate sections for each language
b28e20c Settings: Write to coafile
69a5d2f Generate coafile with basic settings
60bee9a Extract files to ignore from .gitignore
62978ad Change requirements
36c8486 Enable coverage report
d78e85e Bears: Change language used in tests
4a8819e Add myself to the list of maintainers
54f21c6 gitignore: Ignore .egg-info directories
6a7b63a Bears: Use only important bears for each language


Commit SHA Commit
45bfec9 Processing: Reuse file dicts loaded to memory
ef287a4 ConsoleInteraction: Sort questions by bear
7d57784 Caching: Make caching default
1732813 Processing: Switch log message to debug
01890c2 CachingUtilitiesTest: Use Section
868c926 README: Update it
f79f53e Constants: Add strings to binary answers
2d7ee93 LICENSE: Remove boilerplate stuff
da6c3eb Replace listdir with scandir
ad3ec72 coalaCITest: Remove unused imports
91c109d Add option to run coala only on changed files
5a6870c coala: Add class to collect only changed files
622a3e5 Add caching utilities
e1b3594 Tagging: Remove Tagging


Commit SHA Commit
27ee83c Update version
64b0e0b Question: Validate the answer
1046c29 VERSION: Bump version
bd1e8fa setup.cfg: Enable coverage report
79fee96 Question: Use input instead of prompt toolkit
cfd81c1 coala_utils: Move ContextManagers from coalib
c5a4526 Add MANIFEST
f019962 Change VERSION
9db2898 Add map between file extension to language name
a52a309 coala_utils: Add Question module

That's a +2633 / -471 change! I honestly didn't know it'd be that big. Anyway, those were the technical stats. On to the showcase!

Stuff I worked on

My primary GSoC proposal: coala-quickstart


And here's the coafile that's generated:

Pretty neat stuff, huh? :)

Anyway, that was my whole project in a nutshell. I worked on other stuff too during the coding period. Here are some of the results:

Caching in coala

This is another thing I'm proud of: caching in coala. Remember how you had to lint all your files every time even if you changed just one line? No more. With caching, coala will only collect those files that have changed since the last run. This produces a terrific improvement in speed:

Trial 1 Trial 2 Trial 3 Average
Without caching 9.841 9.594 9.516 9.650
With caching 3.374 3.341 3.358 3.358

That's almost a 3x improvement in speed!

Initially, caching was an experimental feature since we didn't want to break stuff! And this can break a lot of stuff. But fortunately, everything went perfectly smoothly and caching was made default.

README overhaul

The coala README page got a complete overhaul. I placed a special emphasis on simplicity and the design; and to be honest, I'm quite happy with the outcome.

Other miscellaneous stuff

I worked on other tiny things during the coding phase:

  • #2585: This was a small bugfix (to my annoyance, introduced by me). This also led to a performance improvement.
  • #2322: listdir is a new python3.5 feature that is faster than the traditional scandir that is used to get a directory's contents.
  • e1b3594: I removed Tagging with this commit. It was unused.
  • #11, #14: A generic tool to ask the user a question and return the answer in a formatted manner. This is now used in several packages across coala.

There were other tiny changes, but you can find them in the commit list.


It's really been a blast, right from the start to the start to the finish. Thanks to everyone who has helped me in any way. Thanks to Google for sponsoring such an awesome program. Thanks to the PSF for providing coala with an opportunity at GSoC. I honestly can't see how this would have been possible without any of you.

To everyone else, I really recommend contributing to open-source. It doesn't have to be coala. It doesn't even need to be a big project. Just find a project you like: it can even be a silly project that doesn't do anything useful. The whole point is to get started. GSoC is one way to easily do that. There is such a wide variety of organizations and projects, I'm pretty sure at least one project will be to your liking. And you're always welcome at coala. Just drop by and say hello at our Gitter channel.