Vote to promote Paul Ganssle as a core developer

  • Promote Paul Ganssle
  • Do not promote Paul Ganssle
0 voters

Victor Stinner and I want to propose Paul Ganssle as a core developer, who would center his efforts on co-maintaining datetime together with Alexander Beloposky.

Some of you may already know Paul Ganssle as the main maintainer of dateutil, as maintainer of setuptools or for his contributions to CPython. On the technical side, Paul has proven many times to have a great domain knowledge around the datetime module and related functionality but he also has remarkable knowledge about Python and CPython internals. As a reviewer, Paul has made several reviews of datetime-related pull requests but also other general pull requests involving Python
and C code as well as documentation. In the reviews he always shows a great care towards the contributor (as can be seen as well in the reviews in the packages that Paul maintains) but also he has spend a lot of time reviewing the wording as a native English speaker, always in a detailed and pedagogical way. Paul always listens to other ideas and viewpoints when discussing and he reacts very positively to criticism in his PRs and work.

Paul would like to focus on co-maintain datetime together with Alexander Beloposky (who has expressed that he is ok with that).

We consulted with Paul prior to the nomination, and he said he is interested in becoming a core developer so that he can expand his ability to improve the datetime module and CPython in general; he also participates in many sprint events, and it would improve his ability to bring new contributors on to the project. In short, we think Paul is an exceptional developer, a kind and compassionate person, and CPython would benefit from having him on the core team.

As a reminder from PEP 13 regarding voting rules:

… It is granted by receiving at least two-thirds positive votes in a core team vote that is open for one week and with no veto by the steering council."
PEP 13 – Python Language Governance | peps.python.org

Here is a summary of Paul’s work and achievements:

Background Information about Paul Ganssle

  1. Maintainer of dateutil since 2014. First and most prominent third-party implementation of PEP 495 (Local Time Disambiguation).
  2. Maintainer of setuptools since 2018.
  3. Frequently run sprints on dateutil and setuptools. Would like to be able to offer mentorship on CPython at conference sprints.
  4. Organized and ran the PyPA mini-summit at PyCon US 2018 and 2019, active in the PyPA generally.
  5. Wrote datetime bindings for PyO3 (CPython bindings for Rust), and has continued to contribute regularly to that project with PRs, reviews and issues. Interested in contributing to the C API from the perspective of someone writing cross-language bindings.
  6. Frequently helps maintain datetime-related code on other projects:
  7. Spoke at the language summit about adding more time zones to the standard library. Slides, Repo

Major accomplishments in CPython

  1. Implemented datetime.fromisoformat, the inverse of datetime.isoformat. This is still the fastest constructor for datetime accessible from Python. (PR #4699, PR #8959)
  2. Exposed datetime.timezone and datetime.timezone.utc in the CPython API. (PR #5032)
  3. Implemented and made the case for changing the return type of datetime + timedelta arithmetic to respect the subclass of the datetime object. Similarly has been working to make datetime safer to subclass in general. (PR #10902, Python-dev thread 1 2)
  4. Improved the speed of all datetime alternate constructors. (PR #4993)
  5. Add datetime.fromisocalendar, the inverse function from datetime.isocalendar in PR #11888. Intends to continue improving and maintaining symmetry between “serialization” and “deserialization” functions.

General maintenance tasks

  1. Generally follows and comments on datetime and packaging related issues in the issue tracker, among other things.
  2. Reviews PRs, generally to datetime and time, but also unrelated PRs (e.g. PR #7605 adding shlex.join).
    Also has been trying to help give a native English speaker’s perspective on documentation PRs.

Future plans

During our discussion, Paul has provided a list of improvements to Python he’d like to make:

  1. Improve Python datetime C API test suite and documentation (partially completed at the PyCon sprints, Paul created the issues and helped Edison Abahurire with reviews and in-person guidance while he made his first pull requests adding tests and documentation for the datetime C API).
  2. Expand time zone support in the standard library with a concrete implementation of IANA time zones and an explicit representation of “local” time.
  3. Add nanosecond support to datetime
  4. Improve compatibility across platforms where possible in things like strftime and timestamp.
  5. Improve locale-specific testing

Most of this is datetime related because that is the primary area where his expertise is most needed (plus most packaging changes occur on setuptools itself and not distutils), but he is interested in general contributions to the language as well.

Contributions

Selected bpo issues

7 Likes

Pablo mostly wrote the message, so let me add mine :slight_smile:

I’m working with Paul for 1 year on the datetime module. I mean, he is doing the work, and I enjoy to watch him doing stuff, and sometimes helping a little bit :smiley: From what I saw, he knows how to write tests, document changes, handle backward compatibility, etc. Things that a core dev should know.

The datetime module is ok-ish: I counted 12 “datetime” modules on PyPI, my list: https://pythondev.readthedocs.io/datetime.html I understand that datetime is “good”… but it lacks many features and its API can be enhanced. It lacks important features like getting the local timezone. It also lacks nanoseconds supports, and maybe even… leap seconds! (I already discussed a solution with Paul, he is open to experiment my idea!) Well, Paul knows way better than me what’s missing. Even where datetime cannot evolve, Paul already made changes to allow to extend datetime more easily (his change on subclasses).

It seems like Alexander Beloposky became less available, so I’m sure that he would appreciate a co-maintainer, especially because I asked him and he is ok to have Paul as a co-maintainer :smiley:

Pablo’s message is already very complete, I will no repeat what he said :wink:

2 Likes

Pablo mostly wrote the message

The message itself is making such an impact. Thanks for taking effort and writing a detailed proposal, @pablogsal.

5 Likes

Huge +1 from me. Working with Paul the past two years has been a pleasure. He’s thoughtful, experienced, and patient. Thanks for proposing Pablo and Victor.

4 Likes

Oh by the way, Paul has the bug triage permission since last February: https://mail.python.org/pipermail/python-committers/2019-February/006567.html (When I gave him this permission, I had already in mind to promote him later :wink: )

2 Likes

Wait, Paul has more free time? :wink:

Definitely in favour, for all the reasons given above.

6 Likes

Pablo, thank you for an excellent nomination that answers nearly any question that one might have.

4 Likes

The vote closed 12 hours ago:

  • Promote Paul Ganssle: 41
  • Don’t promote Paul Ganssle: 2
  • Total: 43 voters

I now let the Steering Committee make its call on this promotion vote.

2 Likes

Too bad nobody gave out their negative reasons.

4 Likes