
Hi, The download button of https://www.python.org/ currently gives the choice between Python 2.7 and 3.6. I read more and more articles saying that we reached a point where Python 3 became more popular than Python 2, Python 3 has now enough new features to convince developers, etc. Is it time to "hide" Python 2.7 from the default choice and only show Python 3.6 *by default*? For example, I expect a single big [DOWNLOAD] button which would start the download of Python 3.6 for my platform. If we cannot agree on hiding Python 2 by default, maybe we can at least replace the big [DOWNLOAD] button of Python 2 with a smaller button or replace it with a link to a different download page? Latest news: Django 2.0 and Pyramid 2.0 will simply drop Python 2 support. Victor

On 26 January 2017 at 16:11, Victor Stinner <victor.stinner@gmail.com> wrote:
+1 On a similar note, I always get caught out by the fact that the Windows default download is the 32-bit version. Are we not yet at a point where a sufficient majority of users have 64-bit machines, and 32-bit should be seen as a "specialist" choice? Paul

On 26.01.2017 23:09, Random832 wrote:
I think you have to differentiate a bit more between having a 64-bit OS and running 64-bit applications. Many applications on Windows are still 32-bit applications and unless you process large amounts of data, a 32-bit Python system is well worth using. In some cases, it's even needed, e.g. if you have to use an extension which links to a 32-bit library. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 26 2017)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

On Thu, Jan 26, 2017 at 10:49 PM, Paul Moore <p.f.moore@gmail.com> wrote:
Preferring the 64-bit version would be a friendlier experience for novices in general nowadays. I've had to explain WOW64 file-system redirection [1] and registry redirection [2] too many times to people who are using 32-bit Python on 64-bit Windows. I've seen people waste over a day on this silly problem. They can't imagine that Windows is basically lying to them. [1]: https://msdn.microsoft.com/en-us/library/aa384187 [2]: https://msdn.microsoft.com/en-us/library/aa384232

On Thu, Jan 26, 2017 at 2:32 PM, M.-A. Lemburg <mal@egenix.com> wrote:
It's also relatively common to need a 64-bit Python, e.g. if running programs that need more than 4 GiB of address space. (Data analysts run into this fairly often.) I don't know enough about Windows to have an informed opinion about how the trade-offs work out, but as an additional data point, it looks like in the last ~week of PyPI downloads, 32-bit windows wheels have been downloaded 379943 times, and 64-bit windows wheels have been downloaded 331933 times [1], so it's pretty evenly split 53% / 47%. -n [1] SELECT COUNT(*) AS downloads, REGEXP_EXTRACT(file.filename, r"(win32|win_amd64)\.whl") as windows_bitness, FROM TABLE_DATE_RANGE( [the-psf:pypi.downloads], TIMESTAMP("20170119"), TIMESTAMP("20170126") ) GROUP BY windows_bitness ORDER BY downloads DESC LIMIT 1000 -- Nathaniel J. Smith -- https://vorpus.org

On Thu, Jan 26, 2017 at 5:23 PM, Nathaniel Smith <njs@pobox.com> wrote:
How much of that is because of the default download on python.org ? Also % seem swapped depending on python2 vs Python3, and quite different. Python 3 190466 win_amd64 ~ 60% 275949 win32 Python 2 3139051 win32 ~ 87% 463554 win_amd64 -- M SELECT COUNT(*) AS downloads, REGEXP_EXTRACT(file.filename, r"(win32|win_amd64)\.whl") as windows_bitness, REGEXP_EXTRACT(details.python, r"(^\d)") as python FROM TABLE_DATE_RANGE( [the-psf:pypi.downloads], TIMESTAMP("20170119"), TIMESTAMP("20170126") ) WHERE REGEXP_EXTRACT(file.filename, r"(win32|win_amd64)\.whl") <> 'null' GROUP BY windows_bitness, python ORDER BY python DESC, downloads DESC LIMIT 1000

On Thu, Jan 26, 2017 at 6:46 PM, Matthias Bussonnier <bussonniermatthias@gmail.com> wrote:
Did you get something reversed here?
I also don't know why your numbers are so much larger than mine... -n -- Nathaniel J. Smith -- https://vorpus.org

On Thu, Jan 26, 2017 at 7:20 PM, Nathaniel Smith <njs@pobox.com> wrote:
I also don't know why your numbers are so much larger than mine...
That's because copy/pasting from the html table prepend the row number to the download count.
Also % seem swapped depending on python2 vs Python3, and quite different. Did you get something reversed here?
Still small majority of 64bit on Py3, but large majority of 32 Bit download on py2. Python 3 90466 win_amd64 ~ 54% 75949 win32 Python 2 139051 win32 ~ 70% 63554 win_amd64 -- M

On 1/26/2017 5:32 PM, M.-A. Lemburg wrote:
I look through the list of a few hundred windows packages at http://www.lfd.uci.edu/~gohlke/pythonlibs/ The two packages that require CUDA 8 and CUDNN are 64-bit only. As far as I saw in a careful check, all other windows binaries are available in both 32- and 64-bit versions. The situation may be different on PyPI, but win64 will cover most thing likely to be used by a beginner. -- Terry Jan Reedy

The problem is not in Python packages, but when gluing Python with other Windows apps or libraries.

On 27.01.2017 06:13, Terry Reedy wrote:
32-bit vs. 64-bit is a still very much a conscious choice on Windows x64, and so whether or not a beginner chose to install 3rd party libs as 32-bit or 64-bit version is not something we can really tell from looking at the browser info. It would probably be better to make the choice for Python a conscious one as well by offering both alternatives or at least make it clear that the default is e.g. x64. Some cases where you'd prefer 32-bit over 64-bit: - MS Office: https://support.office.com/en-us/article/Choose-the-64-bit-or-32-bit-version... - LibreOffice: https://ask.libreoffice.org/en/question/55819/version-5-choose-32-bit-or-64-... - Anything to do with media codecs - Anything that still supports older Windows versions (vendors often don't ship 64-bit variants due to this) You just have to compare the number of entries in your "Programs" dir with the "Programs (x86)" dir to see how common 32-bit applications are today. It's also possible that an application of library installs both 32-bit and 64-bit variants. You can then run into issues when configuring these. The ODBC manager on Windows x64 is a prominent example: there are actually two versions of this, one for 32-bit drivers and one for 64-bit drivers - using distinct configurations. 32-bit apps only see the drivers configured with the 32-bit manager, 64-bit apps only the ones configured with the 64-bit variant. Anyway, I agree that defaulting to x64 is the way forward, and defaulting to x64 for Python on Windows x64 is a good approach, but making the default choice clear to the beginner is probably just as needed to at least give them a hint at what the cause of their problems could be. They have to make the same choice with many other applications as well, so it's not like they've never seen this before. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 27 2017)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

It's certainly an interesting transition period. I'm not sure that the community is quite ready to just drop 2.7, but we could take a hint from angular <https://angularjs.org/>'s solution to this issue and use small descriptions to guide more people to 3.6 rather than 2.7, then move to 2.7 being substantially smaller, then eventually to dropping 2.7. -Ryan Birmingham On 26 January 2017 at 11:11, Victor Stinner <victor.stinner@gmail.com> wrote:

After Django 1.11 (alpha 1 out now, final in few months, LTS EOL 2020) was branched out from master on GH, it was pretty impressive & heartening to see massive commits against master that removed Python 2 compatibility from such a popular library. On Thu, Jan 26, 2017 at 10:11 AM, Victor Stinner <victor.stinner@gmail.com> wrote:

If you only want to vote +1 or -1 with no rationale, you may prefer to vote on my Twitter poll: https://twitter.com/VictorStinner/status/824654597235040257 Otherwise, please explain a little bit. Victor

On 26 January 2017 at 17:11, Victor Stinner <victor.stinner@gmail.com> wrote:
As a related point, there's an open docs issues worth mentioning: http://bugs.python.org/issue26355 That RFE covers setting a "canonical" URL similar to what ReadTheDocs supports: http://docs.readthedocs.io/en/latest/canonical.html Such a change would have two purposes: - consolidating all the links for any given major version into the latest docs for that version in search engines - migrating the legacy deep links in search engine results to the qualified Python 2 URLs Georg has indicated he's fine with the change, so it's just a matter of someone finding the time to poke at the docs build config and how RTFD did it in order to see how to set that up, and then backporting it to *all* the 3.x and 2.x branches that use Sphinx for their docs (even the ones that are otherwise closed to updates). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 26 January 2017 at 16:11, Victor Stinner <victor.stinner@gmail.com> wrote:
Is it time to "hide" Python 2.7 from the default choice and only show Python 3.6 *by default*?
Actually, looking back at the "Download" dropdown for Windows, I see Python 3.6.0 Python 2.7.13 That's not really that bad (I recalled it being worse) - Python 3 is on the left, which I'd interpret as "first", but otherwise the choices are pretty equal. The problem is that because it's 32-bit, I never really look at these options, I always go straight to "Other downloads", which is in a *really* weird order - 3.5.3, then 3.5.3rc1, then 3.6.0, then 2.7.13, ... "Full list of downloads" isn't much better - 3.4.6, 3.5.3, 3.6.0, 2.7.13, 3.4.5, ... +1 on tidying up, and consistently showing an order 3.6.0, 2.7.13, "other older versions". No matter where people end up, they should always see 3.6 as the first option, with 2.7 clearly available as "the other one". +0 on de-emphasising 2.7 still further. I'm in favour, and I think that people who need 2.7 in practice probably need it for compatibility with other parts of their system and so should likely be getting it from their vendor/distro rather than python.org. +1 on making the main download for Windows 64-bit. Paul

On 26.01.2017 17:11, Victor Stinner wrote:
-1 on hiding Python 2.7. It's our LTS release, so something we should be proud of until it goes out of support. +1 on emphasizing the 3.6 button and de-emphasizing 2.7, e.g. by making the 3.6 button yellow and the 2.7 grey. Also +1 on what Paul suggested. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 26 2017)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

On 26/01/2017 17:49, M.-A. Lemburg wrote:
Quite. Please, de-emphasize Python 2.7 if appropriate (it seems to be the consensus), but do not hide it. It is stable, and IMHO the most tried-and-tested version of Python. As a 2.7 user, I would like to *decide* when to upgrade to Python 3, not to be pressured into it by events. Best wishes, Rob Cliffe

Hmm, agreed. BTW, I think the current download page is *way* too complicated for new comers. There should be a giant button for the latest 3.x/64 (platform sniffed), and below it a more subtle button for the "LTS" 2.X/32. The rest of the choices and text should be pushed to another page marked "advanced," including the PGP (boggle) section. The Licenses through History section could be moved to About. -Mike On 2017-01-26 08:11, Victor Stinner wrote:
The download button of https://www.python.org/ currently gives the

On 2/7/17, Mike Miller <python-ideas@mgmiller.net> wrote:
I am afraid that "LTS" could confuse some people because python has not standard LTS versions ( PEP-407 is deffered ) I rather propose to add end-of-life info (which is 2020-01-01 for 2.7 and 2021-12-23 for 3.6) See: https://docs.python.org/devguide/#status-of-python-branches (BTW link to this table could be useful to add on download page too) One could probably also want to consider that some packages plan to drop support for python2 before it's EOL (for example see: http://www.python3statement.org/ ) but I think that download page has not to be overcomplicated.

On 26 January 2017 at 16:11, Victor Stinner <victor.stinner@gmail.com> wrote:
+1 On a similar note, I always get caught out by the fact that the Windows default download is the 32-bit version. Are we not yet at a point where a sufficient majority of users have 64-bit machines, and 32-bit should be seen as a "specialist" choice? Paul

On 26.01.2017 23:09, Random832 wrote:
I think you have to differentiate a bit more between having a 64-bit OS and running 64-bit applications. Many applications on Windows are still 32-bit applications and unless you process large amounts of data, a 32-bit Python system is well worth using. In some cases, it's even needed, e.g. if you have to use an extension which links to a 32-bit library. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 26 2017)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

On Thu, Jan 26, 2017 at 10:49 PM, Paul Moore <p.f.moore@gmail.com> wrote:
Preferring the 64-bit version would be a friendlier experience for novices in general nowadays. I've had to explain WOW64 file-system redirection [1] and registry redirection [2] too many times to people who are using 32-bit Python on 64-bit Windows. I've seen people waste over a day on this silly problem. They can't imagine that Windows is basically lying to them. [1]: https://msdn.microsoft.com/en-us/library/aa384187 [2]: https://msdn.microsoft.com/en-us/library/aa384232

On Thu, Jan 26, 2017 at 2:32 PM, M.-A. Lemburg <mal@egenix.com> wrote:
It's also relatively common to need a 64-bit Python, e.g. if running programs that need more than 4 GiB of address space. (Data analysts run into this fairly often.) I don't know enough about Windows to have an informed opinion about how the trade-offs work out, but as an additional data point, it looks like in the last ~week of PyPI downloads, 32-bit windows wheels have been downloaded 379943 times, and 64-bit windows wheels have been downloaded 331933 times [1], so it's pretty evenly split 53% / 47%. -n [1] SELECT COUNT(*) AS downloads, REGEXP_EXTRACT(file.filename, r"(win32|win_amd64)\.whl") as windows_bitness, FROM TABLE_DATE_RANGE( [the-psf:pypi.downloads], TIMESTAMP("20170119"), TIMESTAMP("20170126") ) GROUP BY windows_bitness ORDER BY downloads DESC LIMIT 1000 -- Nathaniel J. Smith -- https://vorpus.org

On Thu, Jan 26, 2017 at 5:23 PM, Nathaniel Smith <njs@pobox.com> wrote:
How much of that is because of the default download on python.org ? Also % seem swapped depending on python2 vs Python3, and quite different. Python 3 190466 win_amd64 ~ 60% 275949 win32 Python 2 3139051 win32 ~ 87% 463554 win_amd64 -- M SELECT COUNT(*) AS downloads, REGEXP_EXTRACT(file.filename, r"(win32|win_amd64)\.whl") as windows_bitness, REGEXP_EXTRACT(details.python, r"(^\d)") as python FROM TABLE_DATE_RANGE( [the-psf:pypi.downloads], TIMESTAMP("20170119"), TIMESTAMP("20170126") ) WHERE REGEXP_EXTRACT(file.filename, r"(win32|win_amd64)\.whl") <> 'null' GROUP BY windows_bitness, python ORDER BY python DESC, downloads DESC LIMIT 1000

On Thu, Jan 26, 2017 at 6:46 PM, Matthias Bussonnier <bussonniermatthias@gmail.com> wrote:
Did you get something reversed here?
I also don't know why your numbers are so much larger than mine... -n -- Nathaniel J. Smith -- https://vorpus.org

On Thu, Jan 26, 2017 at 7:20 PM, Nathaniel Smith <njs@pobox.com> wrote:
I also don't know why your numbers are so much larger than mine...
That's because copy/pasting from the html table prepend the row number to the download count.
Also % seem swapped depending on python2 vs Python3, and quite different. Did you get something reversed here?
Still small majority of 64bit on Py3, but large majority of 32 Bit download on py2. Python 3 90466 win_amd64 ~ 54% 75949 win32 Python 2 139051 win32 ~ 70% 63554 win_amd64 -- M

On 1/26/2017 5:32 PM, M.-A. Lemburg wrote:
I look through the list of a few hundred windows packages at http://www.lfd.uci.edu/~gohlke/pythonlibs/ The two packages that require CUDA 8 and CUDNN are 64-bit only. As far as I saw in a careful check, all other windows binaries are available in both 32- and 64-bit versions. The situation may be different on PyPI, but win64 will cover most thing likely to be used by a beginner. -- Terry Jan Reedy

The problem is not in Python packages, but when gluing Python with other Windows apps or libraries.

On 27.01.2017 06:13, Terry Reedy wrote:
32-bit vs. 64-bit is a still very much a conscious choice on Windows x64, and so whether or not a beginner chose to install 3rd party libs as 32-bit or 64-bit version is not something we can really tell from looking at the browser info. It would probably be better to make the choice for Python a conscious one as well by offering both alternatives or at least make it clear that the default is e.g. x64. Some cases where you'd prefer 32-bit over 64-bit: - MS Office: https://support.office.com/en-us/article/Choose-the-64-bit-or-32-bit-version... - LibreOffice: https://ask.libreoffice.org/en/question/55819/version-5-choose-32-bit-or-64-... - Anything to do with media codecs - Anything that still supports older Windows versions (vendors often don't ship 64-bit variants due to this) You just have to compare the number of entries in your "Programs" dir with the "Programs (x86)" dir to see how common 32-bit applications are today. It's also possible that an application of library installs both 32-bit and 64-bit variants. You can then run into issues when configuring these. The ODBC manager on Windows x64 is a prominent example: there are actually two versions of this, one for 32-bit drivers and one for 64-bit drivers - using distinct configurations. 32-bit apps only see the drivers configured with the 32-bit manager, 64-bit apps only the ones configured with the 64-bit variant. Anyway, I agree that defaulting to x64 is the way forward, and defaulting to x64 for Python on Windows x64 is a good approach, but making the default choice clear to the beginner is probably just as needed to at least give them a hint at what the cause of their problems could be. They have to make the same choice with many other applications as well, so it's not like they've never seen this before. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 27 2017)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

It's certainly an interesting transition period. I'm not sure that the community is quite ready to just drop 2.7, but we could take a hint from angular <https://angularjs.org/>'s solution to this issue and use small descriptions to guide more people to 3.6 rather than 2.7, then move to 2.7 being substantially smaller, then eventually to dropping 2.7. -Ryan Birmingham On 26 January 2017 at 11:11, Victor Stinner <victor.stinner@gmail.com> wrote:

After Django 1.11 (alpha 1 out now, final in few months, LTS EOL 2020) was branched out from master on GH, it was pretty impressive & heartening to see massive commits against master that removed Python 2 compatibility from such a popular library. On Thu, Jan 26, 2017 at 10:11 AM, Victor Stinner <victor.stinner@gmail.com> wrote:

If you only want to vote +1 or -1 with no rationale, you may prefer to vote on my Twitter poll: https://twitter.com/VictorStinner/status/824654597235040257 Otherwise, please explain a little bit. Victor

On 26 January 2017 at 17:11, Victor Stinner <victor.stinner@gmail.com> wrote:
As a related point, there's an open docs issues worth mentioning: http://bugs.python.org/issue26355 That RFE covers setting a "canonical" URL similar to what ReadTheDocs supports: http://docs.readthedocs.io/en/latest/canonical.html Such a change would have two purposes: - consolidating all the links for any given major version into the latest docs for that version in search engines - migrating the legacy deep links in search engine results to the qualified Python 2 URLs Georg has indicated he's fine with the change, so it's just a matter of someone finding the time to poke at the docs build config and how RTFD did it in order to see how to set that up, and then backporting it to *all* the 3.x and 2.x branches that use Sphinx for their docs (even the ones that are otherwise closed to updates). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 26 January 2017 at 16:11, Victor Stinner <victor.stinner@gmail.com> wrote:
Is it time to "hide" Python 2.7 from the default choice and only show Python 3.6 *by default*?
Actually, looking back at the "Download" dropdown for Windows, I see Python 3.6.0 Python 2.7.13 That's not really that bad (I recalled it being worse) - Python 3 is on the left, which I'd interpret as "first", but otherwise the choices are pretty equal. The problem is that because it's 32-bit, I never really look at these options, I always go straight to "Other downloads", which is in a *really* weird order - 3.5.3, then 3.5.3rc1, then 3.6.0, then 2.7.13, ... "Full list of downloads" isn't much better - 3.4.6, 3.5.3, 3.6.0, 2.7.13, 3.4.5, ... +1 on tidying up, and consistently showing an order 3.6.0, 2.7.13, "other older versions". No matter where people end up, they should always see 3.6 as the first option, with 2.7 clearly available as "the other one". +0 on de-emphasising 2.7 still further. I'm in favour, and I think that people who need 2.7 in practice probably need it for compatibility with other parts of their system and so should likely be getting it from their vendor/distro rather than python.org. +1 on making the main download for Windows 64-bit. Paul

On 26.01.2017 17:11, Victor Stinner wrote:
-1 on hiding Python 2.7. It's our LTS release, so something we should be proud of until it goes out of support. +1 on emphasizing the 3.6 button and de-emphasizing 2.7, e.g. by making the 3.6 button yellow and the 2.7 grey. Also +1 on what Paul suggested. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jan 26 2017)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

On 26/01/2017 17:49, M.-A. Lemburg wrote:
Quite. Please, de-emphasize Python 2.7 if appropriate (it seems to be the consensus), but do not hide it. It is stable, and IMHO the most tried-and-tested version of Python. As a 2.7 user, I would like to *decide* when to upgrade to Python 3, not to be pressured into it by events. Best wishes, Rob Cliffe

Hmm, agreed. BTW, I think the current download page is *way* too complicated for new comers. There should be a giant button for the latest 3.x/64 (platform sniffed), and below it a more subtle button for the "LTS" 2.X/32. The rest of the choices and text should be pushed to another page marked "advanced," including the PGP (boggle) section. The Licenses through History section could be moved to About. -Mike On 2017-01-26 08:11, Victor Stinner wrote:
The download button of https://www.python.org/ currently gives the

On 2/7/17, Mike Miller <python-ideas@mgmiller.net> wrote:
I am afraid that "LTS" could confuse some people because python has not standard LTS versions ( PEP-407 is deffered ) I rather propose to add end-of-life info (which is 2020-01-01 for 2.7 and 2021-12-23 for 3.6) See: https://docs.python.org/devguide/#status-of-python-branches (BTW link to this table could be useful to add on download page too) One could probably also want to consider that some packages plan to drop support for python2 before it's EOL (for example see: http://www.python3statement.org/ ) but I think that download page has not to be overcomplicated.
participants (19)
-
Berker Peksağ
-
Brett Cannon
-
David Mertz
-
Denis Akhiyarov
-
eryk sun
-
M.-A. Lemburg
-
Matthias Bussonnier
-
Mike Miller
-
Nathaniel Smith
-
Nick Coghlan
-
Nick Timkovich
-
Paul Moore
-
Pavol Lisy
-
Random832
-
Rob Cliffe
-
Ryan Birmingham
-
Sven R. Kunze
-
Terry Reedy
-
Victor Stinner