My Contributions to CPython

Voilà, since the October 4th, I am contributing to CPython, and for one time, I am really happy.

Why?

It’s really difficult to find a little bit of time for the CPython contributions because I am freelance and I have a full-time schedule for my customers. At the beginning I was afraid but with time and it is a success (for me) because my company is 1 year old and has its first employee since some months.

On the other side, I also have my family with my daughter and my wife where I have to be present for them, so we can say this is a full-time job.

I also participate in some events, EuroPython, PyCon US, PyCon France, PyCon Ireland, etc… I am also a co-organizer of EuroPython (I do not like this term I prefer to say I am in the website work-group and than I try to work with the other developers and improve the website ;-))

And lately, since April 2018, I started to prepare my Karate black belt, this step of my life requires a lot of time. This step is really important for me, because I began Karaté at the end of the 90s and I would like to pass my exam and have the possibility to say “I did it”. After that, I will continue, for me Karate is respect, the discipline, and the sharing.

In October, I finished my missions for my customers, during 20 months I worked for them. For 20 months I travel a lot, I was often on the road. And thus, I decided to take a sabbatical month, without any customer. Just my family and the #python community

Firstly, I fixed a lot of things at home ;-) now, my family is happy and me as well because I finished all the boring stuff.

Secondly, I started to contribute to CPython and now I can say I proposed pull requests and you can find all my merged PR

On macOS, support the file where the size is greater than 2 GiB.

I am really proud of this PR because it’s a very old pull request. In the past, before the migration to GitHub, Ronald Oussoren had proposed a patch for Python 3.4 but the patch were never merged.

In 2016, I started to work on this patch for 3.5 and 3.6 but there was a problem during the review, the patch must have been for the merge and with the several reviews, I have completely rewritten it.

During the CPython sprints of PyCon US 2017, I have ported the patch to a pull request in GitHub. Not really difficult, excepted there was a problem with Travis, AppVeyor and some others tools, a problem with the memory, the worker is limited to 3GB of RAM on Travis and the job for my PR was simply killed ;-)

Great, how my pull request could be merged if the worker kills the process? ;-)

Normally, once merged, this PR could fix this numpy issue.

• bpo link: open().write() fails on 2 GB+ data (OS X)

Thank you to Victor Stinner for his review.

make doctest in Doc now passes and is enforced in CI

Last week I was playing with Sphinx and the documentation located in the Doc/ directory of the project.

Just execute this command make and I saw there was a doctest target. I was curious (it’s really bad to be curious sometimes ;-)). So I type the command make doctest and I see there were ~ 398 failed tests. What???

It’s just impossible, I work on Python and normally Python is well tested, this is true for the code, maybe not for the documentation. And I have started to work on this issue with Julien Palard.

With this issue, we have updated Sphinx to the last version (1.8.1) because this one supports a :skipif: option for the doctest directive.

In the case of the documentation, this is useful because we could execute the tests excepted for turtle, and for that, we can use the directive with the options:

.. testsetup::

    try:
        import tkinter as tk
    except ImportError:
        tk = None

.. doctest::
    :skipif: tk is None

Now, the documentation of CPython uses Sphinx 1.8.1 \o/

But with Sphinx 1.8.1, there was a DeprecationWarning. Julien has filled an issue on the bug tracker.

Here is the PR 9827 for this issue ;-)

• bpo link: make doctest does not pass
• bpo link: Sphinx is deprecating add_description_unit

Thank you to Julien Palard for his review.

Improve the CLI of Gzip with argparse.

Another surprise, I was looking for a new “easy” issue on the bug tracker and I found on this one bpo-23596. I see there is a patch from Antony Lee, the patch was correct. But there was a problem, before the integration of this patch, we need to have a unit test for the CLI.

The first step, write the test for the current CLI. Why do I need to write this unit test? Because without a test, how can you validate that your patch works fine?

So, I wrote my tests with a lot of assert_python_ok, assert_python_failure, subprocess.Popen, etc…

At the end, I had one pull request with the tests, I was happy because this one has been quickly merged.

The second step, take the patch of Antony Lee and try to improve it. Once the patch converted to a pull request, this one has been merged.

The next step and the last one was the improvement of the documentation. Because I do not know for you but I have discovered the CLI of gzip with this issue, before I did not even know it existed ;-)

Thus a new CLI -> a new documentation and hello to the issue bpo-34913

Finally, I am really glad to announce the gzip module has a documented and tested CLI.

• bpo link: Document gzip command line interface
• bpo link: gzip argparse interface

Thank you to Julien Palard for his review.

Conclusion?

I can say I am just happy because I have fixed some issues and my oldest PR has been merged into master, 3.7 and 3.6.

And now, I have some Pull Requests to improve before merging.

Thank you,

Stéphane