This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients brett.cannon, lemburg, serhiy.storchaka, vstinner
Date 2018-11-29.22:53:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <75f42082-412e-d6c4-df87-1d3fa9bb6aa7@egenix.com>
In-reply-to <1543529665.49.0.788709270274.issue35346@psf.upfronthosting.co.za>
Content
Ok, let me add some history here:

When I created the platform module it was clear that this would be
a module which will frequently need updates, since platforms evolve
faster than Python does.

I had developed this with a larger number of contributors outside
the stdlib for a while and then there was a request to add it to the
stdlib.

Now in order to keep the module more or less up-to-date, it still
required regular updates, so the plan was to have it updated in the
current versions of Python, but allow it to be used in older Python
versions as well. That was the compromise to have it in the stdlib
and not external. Otherwise, I would have not added it to the stdlib.

This is why it has a special status and keep backwards compatibility
much longer than other code in the stdlib.

This worked quite well, but for some systems such as the Linux
distros, it was impossible to keep up with the development in that
mode. Well, actually, there were multiple reasons why this part
failed: 1. Linux distros didn't not have a standard when I added
the code, 2. Then some distros started two or three different ones,
3. Distros started to use multiple standards with conflicting data,
4. New distros became popular more often than we could update the
code.

That's why I was fine with removing the code again and leaving this
part to a PyPI package.

Does it make more sense now ?
History
Date User Action Args
2018-11-29 22:53:50lemburgsetrecipients: + lemburg, brett.cannon, vstinner, serhiy.storchaka
2018-11-29 22:53:50lemburglinkissue35346 messages
2018-11-29 22:53:50lemburgcreate