[Python-Dev] PEP 455: TransformDict

[Nick Coghlan]

On 14 September 2013 12:44, Steven D'Aprano <steve at pearwood.info> wrote:
> 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.

Correct, that's exactly what they should do.

> - 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.

Correct, it doesn't help you until it graduates from provisional
status. Less risk averse users may choose to use it sooner (since any
removed modules would almost certainly find a home on PyPI in fairly
short order)

> 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.

"We expect that most of the API of most provisional packages will be
unchanged at graduation. Withdrawals are expected to be rare."

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia