[Python-Dev] PEP 455: TransformDict

[Steven D'Aprano]

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