An HTTP API to list versions of Python
We do not have a standard way to get (programatically) informations about Python versions, this leads to having to commit to numerous places during each releases, and some other places never get the information (like old docs, see [1]). Maybe we should provide an HTTP API listing Python versions, like: { "current_stable": "3.8.3", "versions": [ { "branch": "master", "status": "dev", "version": "3.10", "release_manager": "Łukasz Langa", "doc_languages": ["en", "es", "fr", "ja", "ko", "pt-br", "zh-cn"] }, { "branch": "3.9", "latest": "3.9.0b1", "status": "features", "pep": 596, "version": "3.9", "release_manager": "Łukasz Langa", "doc_languages": ["en", "fr", "ja", "ko", "pt-br", "zh-cn"] }, { "branch": "3.8", "latest": "3.8.3", "status": "bugfix", "pep": 569, "version": "3.8", "release_manager": "Łukasz Langa", "first_release": "2019-10-14", "end_life": "2024-10", "doc_languages": ["en", "fr", "ja", "ko", "pt-br", "zh-cn"] }, { "branch": "3.7", "latest": "3.7.7", "status": "bugfix", "pep": 537, "version": "3.8", "release_manager": "Ned Deily", "first_release": "2018-06-27", "end_life": "2023-06-27", "doc_languages": ["en", "fr", "ja", "ko", "pt-br"] } ... (Don't really mind this particular example, it's a random first though, the doc_languages should probably be a dict instead, with links to the actual docs, ...) It could be used to (and maybe avoid a commit) to: - build the documentation version switcher and languages switchers - toggle the red deprecated banner (to be seen on [2] if you missed it) - generate the versions table at https://devguide.python.org/ - generate the Docs by version menu - generate the Download menu and download page of python.org - list the documentations versions to be built by docsbuild-script - probably many scripts could use it too, I can think of [3] - ... It could become more detailed about each minor versions, git tag, links to changelogs, links to the repositories, to the docs, download links, and so on. Maybe this idea will just add a commit to do between the numerous commits to already do during a release... (à la https://xkcd.com/927/), and a SPOF. What do you think? [1]: https://mail.python.org/archives/list/docs@python.org/thread/L724YZXXHQZQP4H... [2]: https://docs.python.org/2.7/ [3]: https://gitlab.com/python-devs/ci-images/-/blob/master/Dockerfile#L19 -- [Julien Palard](https://mdk.fr)
Assuming the release managers are on-board with the idea (since it would impact them the most), I'm +1. Overall, it seems like it would help significantly to reduce the total number of different locations to update during the release process once we get it fully configured.
It could become more detailed about each minor versions, git tag, links to changelogs, links to the repositories, to the docs, download links, and so on.
I don't know that it needs to be said, but for now, I think we should start with a minimalist approach by keeping the API focused on reducing the number of *existing* locations to update, rather than predicting what might sort of fields might be useful to include. Otherwise, it could very well end up becoming more work to maintain compared to what it actually saves. On Tue, May 26, 2020 at 6:38 PM Julien Palard via Python-ideas < python-ideas@python.org> wrote:
We do not have a standard way to get (programatically) informations about Python versions, this leads to having to commit to numerous places during each releases, and some other places never get the information (like old docs, see [1]).
Maybe we should provide an HTTP API listing Python versions, like:
{ "current_stable": "3.8.3", "versions": [ { "branch": "master", "status": "dev", "version": "3.10", "release_manager": "Łukasz Langa", "doc_languages": ["en", "es", "fr", "ja", "ko", "pt-br", "zh-cn"] }, { "branch": "3.9", "latest": "3.9.0b1", "status": "features", "pep": 596, "version": "3.9", "release_manager": "Łukasz Langa", "doc_languages": ["en", "fr", "ja", "ko", "pt-br", "zh-cn"] }, { "branch": "3.8", "latest": "3.8.3", "status": "bugfix", "pep": 569, "version": "3.8", "release_manager": "Łukasz Langa", "first_release": "2019-10-14", "end_life": "2024-10", "doc_languages": ["en", "fr", "ja", "ko", "pt-br", "zh-cn"] }, { "branch": "3.7", "latest": "3.7.7", "status": "bugfix", "pep": 537, "version": "3.8", "release_manager": "Ned Deily", "first_release": "2018-06-27", "end_life": "2023-06-27", "doc_languages": ["en", "fr", "ja", "ko", "pt-br"] } ...
(Don't really mind this particular example, it's a random first though, the doc_languages should probably be a dict instead, with links to the actual docs, ...)
It could be used to (and maybe avoid a commit) to: - build the documentation version switcher and languages switchers - toggle the red deprecated banner (to be seen on [2] if you missed it) - generate the versions table at https://devguide.python.org/ - generate the Docs by version menu - generate the Download menu and download page of python.org - list the documentations versions to be built by docsbuild-script - probably many scripts could use it too, I can think of [3] - ...
It could become more detailed about each minor versions, git tag, links to changelogs, links to the repositories, to the docs, download links, and so on.
Maybe this idea will just add a commit to do between the numerous commits to already do during a release... (à la https://xkcd.com/927/), and a SPOF.
What do you think?
[1]:
https://mail.python.org/archives/list/docs@python.org/thread/L724YZXXHQZQP4H... [2]: https://docs.python.org/2.7/ [3]: https://gitlab.com/python-devs/ci-images/-/blob/master/Dockerfile#L19
-- [Julien Palard](https://mdk.fr) _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Y35KK5... Code of Conduct: http://python.org/psf/codeofconduct/
On Tue, 26 May 2020 22:19:12 -0400 Kyle Stanley <aeros167@gmail.com> wrote:
It could become more detailed about each minor versions, git tag, links to changelogs, links to the repositories, to the docs, download links, and so on.
I don't know that it needs to be said, but for now, I think we should start with a minimalist approach by keeping the API focused on reducing the number of *existing* locations to update, rather than predicting what might sort of fields might be useful to include. Otherwise, it could very well end up becoming more work to maintain compared to what it actually saves.
Unless unusual fields are required in the returned information, how about using PyPI as the information store? That way, you don't have to design a new API and implement a new backend... (that doesn't mean PyPI needs to host any downloadable files for Pyhon, by the way - just the metadata) Regards Antoine.
On 27/05/2020 18.59, Antoine Pitrou wrote:
On Tue, 26 May 2020 22:19:12 -0400 Kyle Stanley <aeros167@gmail.com> wrote:
It could become more detailed about each minor versions, git tag, links to changelogs, links to the repositories, to the docs, download links, and so on.
I don't know that it needs to be said, but for now, I think we should start with a minimalist approach by keeping the API focused on reducing the number of *existing* locations to update, rather than predicting what might sort of fields might be useful to include. Otherwise, it could very well end up becoming more work to maintain compared to what it actually saves.
Unless unusual fields are required in the returned information, how about using PyPI as the information store? That way, you don't have to design a new API and implement a new backend...
(that doesn't mean PyPI needs to host any downloadable files for Pyhon, by the way - just the metadata)
Barry and Guido own the Python project on PyPI, https://pypi.org/project/Python/ . There hasn't been an update since 2.5.0 in 2007. Does PyPI still support empty releases without files? I wouldn't mind to upload all sources on PyPI, too. Christian
27.05.20 21:10, Christian Heimes пише:
Barry and Guido own the Python project on PyPI, https://pypi.org/project/Python/ . There hasn't been an update since 2.5.0 in 2007.
There are also https://pypi.org/project/python2/ https://pypi.org/project/python4/ https://pypi.org/project/cPython/ which are unrelated to the Python interpreter.
On 27.05.2020 18:59, Antoine Pitrou wrote:
On Tue, 26 May 2020 22:19:12 -0400 Kyle Stanley <aeros167@gmail.com> wrote:
It could become more detailed about each minor versions, git tag, links to changelogs, links to the repositories, to the docs, download links, and so on.
I don't know that it needs to be said, but for now, I think we should start with a minimalist approach by keeping the API focused on reducing the number of *existing* locations to update, rather than predicting what might sort of fields might be useful to include. Otherwise, it could very well end up becoming more work to maintain compared to what it actually saves.
Unless unusual fields are required in the returned information, how about using PyPI as the information store? That way, you don't have to design a new API and implement a new backend...
(that doesn't mean PyPI needs to host any downloadable files for Pyhon, by the way - just the metadata)
Here's something which is close to an HTTP API and doesn't need any new process, since it's been working for ages... https://www.python.org/ftp/python/ (and it's also easier to use than the regular python.org download mechanisms) If you're looking for the 1.x releases, you can find them here: https://www.python.org/ftp/python/src/ Even earlier ones are on USENET. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 27 2020)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: 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 https://www.egenix.com/company/contact/ https://www.malemburg.com/
The downside to the FTP solution however is that little metadata is present about the versions The FTP pages are primarily for downloading versions which isn't the aim of the proposal, it's to be able to fetch the metadata. Adding some sort of metadata file to all versions on the FTP server would solve the problem but at that point I'm not sure the "doesn't need any new process" argument still holds water. On Wed, 27 May 2020 at 22:36, M.-A. Lemburg <mal@egenix.com> wrote:
On Tue, 26 May 2020 22:19:12 -0400 Kyle Stanley <aeros167@gmail.com> wrote:
It could become more detailed about each minor versions, git tag,
On 27.05.2020 18:59, Antoine Pitrou wrote: links
to changelogs, links to the repositories, to the docs, download links, and so on.
I don't know that it needs to be said, but for now, I think we should start with a minimalist approach by keeping the API focused on reducing the number of *existing* locations to update, rather than predicting what might sort of fields might be useful to include. Otherwise, it could very well end up becoming more work to maintain compared to what it actually saves.
Unless unusual fields are required in the returned information, how about using PyPI as the information store? That way, you don't have to design a new API and implement a new backend...
(that doesn't mean PyPI needs to host any downloadable files for Pyhon, by the way - just the metadata)
Here's something which is close to an HTTP API and doesn't need any new process, since it's been working for ages...
https://www.python.org/ftp/python/
(and it's also easier to use than the regular python.org download mechanisms)
If you're looking for the 1.x releases, you can find them here:
https://www.python.org/ftp/python/src/
Even earlier ones are on USENET.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 27 2020)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: 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 https://www.egenix.com/company/contact/ https://www.malemburg.com/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XMURTT... Code of Conduct: http://python.org/psf/codeofconduct/
On 27.05.2020 23:46, Joseph Banks wrote:
The downside to the FTP solution however is that little metadata is present about the versions
The FTP pages are primarily for downloading versions which isn't the aim of the proposal, it's to be able to fetch the metadata.
Adding some sort of metadata file to all versions on the FTP server would solve the problem but at that point I'm not sure the "doesn't need any new process" argument still holds water.
It was an FTP server. Nowadays, the files are served up via HTTPS. The FTP server has been switched off long ago. The point about not needing more process is that you always need someone to maintain any such addition. It would be fairly easy for someone to step up and start maintaining such an index, perhaps even as a PyPI package, but such resources are only useful when fully maintained over long periods of time. In terms of meta data, the best we currently have are PEPs for each minor release version, the downloads page on python.org for release dates and PEP links, and the location I mentioned for quickly grabbing the download files.
On Wed, 27 May 2020 at 22:36, M.-A. Lemburg <mal@egenix.com <mailto:mal@egenix.com>> wrote:
On 27.05.2020 18:59, Antoine Pitrou wrote: > On Tue, 26 May 2020 22:19:12 -0400 > Kyle Stanley <aeros167@gmail.com <mailto:aeros167@gmail.com>> wrote: >> >>> It could become more detailed about each minor versions, git tag, links >> to changelogs, links to the repositories, to the docs, download links, >> and so on. >> >> I don't know that it needs to be said, but for now, I think we should start >> with a minimalist approach by keeping the API focused on reducing the >> number of *existing* locations to update, rather than predicting what might >> sort of fields might be useful to include. Otherwise, it could very well >> end up becoming more work to maintain compared to what it actually saves. > > Unless unusual fields are required in the returned information, how > about using PyPI as the information store? That way, you don't have to > design a new API and implement a new backend... > > (that doesn't mean PyPI needs to host any downloadable files for Pyhon, > by the way - just the metadata)
Here's something which is close to an HTTP API and doesn't need any new process, since it's been working for ages...
https://www.python.org/ftp/python/
(and it's also easier to use than the regular python.org <http://python.org> download mechanisms)
If you're looking for the 1.x releases, you can find them here:
https://www.python.org/ftp/python/src/
Even earlier ones are on USENET.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 27 2020) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________
::: 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 https://www.egenix.com/company/contact/ https://www.malemburg.com/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org <mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org <mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XMURTT... Code of Conduct: http://python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 28 2020)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: 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 https://www.egenix.com/company/contact/ https://www.malemburg.com/
Does there need to be a webapp? Or could it just be a JSON-LD file in a static site; maybe with a GH Action that validates (and maybe generates) the data according to a schema. Here's a rough sketch of a schema for this data: "Generate Misc/NEWS from individual files" (2017) https://github.com/python/core-workflow/issues/6#issuecomment-290493601 On Thu, May 28, 2020, 4:09 AM M.-A. Lemburg <mal@egenix.com> wrote:
On 27.05.2020 23:46, Joseph Banks wrote:
The downside to the FTP solution however is that little metadata is present about the versions
The FTP pages are primarily for downloading versions which isn't the aim of the proposal, it's to be able to fetch the metadata.
Adding some sort of metadata file to all versions on the FTP server would solve the problem but at that point I'm not sure the "doesn't need any new process" argument still holds water.
It was an FTP server. Nowadays, the files are served up via HTTPS. The FTP server has been switched off long ago.
The point about not needing more process is that you always need someone to maintain any such addition.
It would be fairly easy for someone to step up and start maintaining such an index, perhaps even as a PyPI package, but such resources are only useful when fully maintained over long periods of time.
In terms of meta data, the best we currently have are PEPs for each minor release version, the downloads page on python.org for release dates and PEP links, and the location I mentioned for quickly grabbing the download files.
On Wed, 27 May 2020 at 22:36, M.-A. Lemburg <mal@egenix.com <mailto:mal@egenix.com>> wrote:
On 27.05.2020 18:59, Antoine Pitrou wrote: > On Tue, 26 May 2020 22:19:12 -0400 > Kyle Stanley <aeros167@gmail.com <mailto:aeros167@gmail.com>> wrote: >> >>> It could become more detailed about each minor versions, git tag, links >> to changelogs, links to the repositories, to the docs, download links, >> and so on. >> >> I don't know that it needs to be said, but for now, I think we should start >> with a minimalist approach by keeping the API focused on reducing the >> number of *existing* locations to update, rather than predicting what might >> sort of fields might be useful to include. Otherwise, it could very well >> end up becoming more work to maintain compared to what it actually saves. > > Unless unusual fields are required in the returned information, how > about using PyPI as the information store? That way, you don't have to > design a new API and implement a new backend... > > (that doesn't mean PyPI needs to host any downloadable files for Pyhon, > by the way - just the metadata)
Here's something which is close to an HTTP API and doesn't need any new process, since it's been working for ages...
https://www.python.org/ftp/python/
(and it's also easier to use than the regular python.org <http://python.org> download mechanisms)
If you're looking for the 1.x releases, you can find them here:
https://www.python.org/ftp/python/src/
Even earlier ones are on USENET.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 27
>>> Python Projects, Coaching and Support ...
>>> Python Product Development ...
https://consulting.egenix.com/
________________________________________________________________________
::: 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 https://www.egenix.com/company/contact/ https://www.malemburg.com/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org <mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org <mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/XMURTT...
Code of Conduct: http://python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 28 2020)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: 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 https://www.egenix.com/company/contact/ https://www.malemburg.com/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RGLNRP... Code of Conduct: http://python.org/psf/codeofconduct/
Since cutting releases is done by the release manager, producing such meta would have to be part of his or her role. The tools RMs use are here: https://github.com/python/release-tools/ The PEP describing the process: https://www.python.org/dev/peps/pep-0101/ Looking through the release.py script I found that the python.org seems to already have a REST API for releases: https://www.python.org/api/v1/downloads/release/ for files: https://www.python.org/api/v1/downloads/release_file/ which is defined here: https://github.com/python/pythondotorg/blob/master/downloads/api.py So I guess we can end this discussion with "patches are welcome", but please make sure that the RMs don't get extra work just because someone thinks it would be cool to have more meta data available. Oh, and a PyPI package to read the meta data would be nice as well ;-) Looking at the data that's already available, it seems you're only missing the name of the release manager and a list of available doc languages. Not sure where you'd get the latter from, perhaps check for "python-doc-*" repos on https://github.com/python ?! On 28.05.2020 21:18, Wes Turner wrote:
Does there need to be a webapp? Or could it just be a JSON-LD file in a static site; maybe with a GH Action that validates (and maybe generates) the data according to a schema.
Here's a rough sketch of a schema for this data:
"Generate Misc/NEWS from individual files" (2017) https://github.com/python/core-workflow/issues/6#issuecomment-290493601
On Thu, May 28, 2020, 4:09 AM M.-A. Lemburg <mal@egenix.com <mailto:mal@egenix.com>> wrote:
On 27.05.2020 23:46, Joseph Banks wrote: > The downside to the FTP solution however is that little metadata is > present about the versions > > The FTP pages are primarily for downloading versions which isn't the aim > of the proposal, it's to be able to fetch the metadata. > > Adding some sort of metadata file to all versions on the FTP server > would solve the problem but at that point I'm not sure the "doesn't need > any new process" argument still holds water.
It was an FTP server. Nowadays, the files are served up via HTTPS. The FTP server has been switched off long ago.
The point about not needing more process is that you always need someone to maintain any such addition.
It would be fairly easy for someone to step up and start maintaining such an index, perhaps even as a PyPI package, but such resources are only useful when fully maintained over long periods of time.
In terms of meta data, the best we currently have are PEPs for each minor release version, the downloads page on python.org <http://python.org> for release dates and PEP links, and the location I mentioned for quickly grabbing the download files.
> On Wed, 27 May 2020 at 22:36, M.-A. Lemburg <mal@egenix.com <mailto:mal@egenix.com> > <mailto:mal@egenix.com <mailto:mal@egenix.com>>> wrote: > > On 27.05.2020 18:59, Antoine Pitrou wrote: > > On Tue, 26 May 2020 22:19:12 -0400 > > Kyle Stanley <aeros167@gmail.com <mailto:aeros167@gmail.com> <mailto:aeros167@gmail.com <mailto:aeros167@gmail.com>>> wrote: > >> > >>> It could become more detailed about each minor versions, git > tag, links > >> to changelogs, links to the repositories, to the docs, download > links, > >> and so on. > >> > >> I don't know that it needs to be said, but for now, I think we > should start > >> with a minimalist approach by keeping the API focused on reducing the > >> number of *existing* locations to update, rather than predicting > what might > >> sort of fields might be useful to include. Otherwise, it could > very well > >> end up becoming more work to maintain compared to what it > actually saves. > > > > Unless unusual fields are required in the returned information, how > > about using PyPI as the information store? That way, you don't > have to > > design a new API and implement a new backend... > > > > (that doesn't mean PyPI needs to host any downloadable files for > Pyhon, > > by the way - just the metadata) > > Here's something which is close to an HTTP API and doesn't need any new > process, since it's been working for ages... > > https://www.python.org/ftp/python/ > > (and it's also easier to use than the regular python.org <http://python.org> > <http://python.org> download > mechanisms) > > If you're looking for the 1.x releases, you can find them here: > > https://www.python.org/ftp/python/src/ > > Even earlier ones are on USENET. > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, May 27 2020) > >>> Python Projects, Coaching and Support ... https://www.egenix.com/ > >>> Python Product Development ... https://consulting.egenix.com/ > ________________________________________________________________________ > > ::: 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 > https://www.egenix.com/company/contact/ > https://www.malemburg.com/ > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org <mailto:python-ideas@python.org> > <mailto:python-ideas@python.org <mailto:python-ideas@python.org>> > To unsubscribe send an email to python-ideas-leave@python.org <mailto:python-ideas-leave@python.org> > <mailto:python-ideas-leave@python.org <mailto:python-ideas-leave@python.org>> > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/XMURTT... > Code of Conduct: http://python.org/psf/codeofconduct/ >
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 28 2020) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________
::: 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 https://www.egenix.com/company/contact/ https://www.malemburg.com/ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org <mailto:python-ideas@python.org> To unsubscribe send an email to python-ideas-leave@python.org <mailto:python-ideas-leave@python.org> https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RGLNRP... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XTVROQ... Code of Conduct: http://python.org/psf/codeofconduct/
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 29 2020)
Python Projects, Coaching and Support ... https://www.egenix.com/ Python Product Development ... https://consulting.egenix.com/
::: 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 https://www.egenix.com/company/contact/ https://www.malemburg.com/
participants (8)
-
Antoine Pitrou -
Christian Heimes -
Joseph Banks -
Julien Palard -
Kyle Stanley -
M.-A. Lemburg -
Serhiy Storchaka -
Wes Turner