[Python-Dev] PEP 455: TransformDict (original) (raw)
Steven D'Aprano steve at pearwood.info
Sat Sep 14 04:44:52 CEST 2013
- Previous message: [Python-Dev] PEP 455: TransformDict
- Next message: [Python-Dev] "Provisional" considered harmful? [was: PEP 455: TransformDict]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Sep 13, 2013 at 06:00:18PM -0700, Ethan Furman wrote:
Personally, if there's a bunch of push-back against just adding TransformDict directly, why don't we make it provisional? I thought that was what provisional was for (meaning: we're going to add it, PyPI is not really appropriate, there may be some API changes).
Not according to PEP 411. It implies that only modules/packages can be provisional, not individual functions, and states that "most packages" are expected to be provisional. So either PEP 411 doesn't apply to TransformDict at all, or it applies by default. The PEP doesn't say.
http://www.python.org/dev/peps/pep-0411/
Everything below the line is about PEP 411, not TransformDict. If you don't care about PEP 411, you can stop reading now.
==========================
Personally, I think it's a poor PEP. It doesn't document opposition to the idea, and if I recall the discussion at the time correctly, there was plenty of opposition.
Since people cannot rely on provisional features still being available in the future, if they care the slightest about forward compatibility, they dare not use them.
If people do use them, and we care about backwards compatibility, we dare not remove provisional packages without going through the same deprecation process as for ordinary packages.
It relies on people reading the documentation and noticing that a package is marked "provisional". Like that's going to happen.
None of these arguments are documented in the PEP, let alone refuted. Even if the decision to approve the PEP ends up being vindicated, I think it was poor form for the PEP to ignore arguments against.
I don't think that "provisional" helps end users at all. If anything, it hurts them -- it means more uncertainty and doubt. Packages may languish in provisional status indefinitely. Speaking as an end user, I used to know that once a feature hit the std lib, it was stable and wouldn't be removed without going through a lengthy period of deprecation (except under truly remarkable circumstances). But for provisional packages, that promise doesn't apply, and although PEP 411 says that packages won't be gratuitously removed, I have to assume that any provisional package in version 3.x could be gone without notice or warning in 3.x+1. I don't see how that helps me. It just means that for some indefinite period, there's a package in the std lib doing exactly what I want that I dare not use in production software because there are no stability guarantees.
The PEP has a lengthy section that claims to be about how it will help end users. It actually isn't -- it is about how inclusion in the standard library helps end users. Not surprisingly, there's nothing about why reserving the right to rip out a package without warning is good for end uers, since it isn't.
End of rant.
-- Steven
- Previous message: [Python-Dev] PEP 455: TransformDict
- Next message: [Python-Dev] "Provisional" considered harmful? [was: PEP 455: TransformDict]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]