survey: is shelve broken? should it be fixed?

[Alex Martelli]

Martin v. Löwis wrote:

> Roman Suzi <rnd at onego.ru> writes:
> 
>> I think it is better to fix and not looking for backward compatibility!
>> It will not be seen on the background of other major changes to Python.
>> So, no smart is needed, IMHO.
> 
> I disagree. The past tells us that great care is needed for backwards
> compatibility.

Right.  We really cannot afford to change semantics wantonly, even though
it may seem the old one was 'broken', it WAS around for years, so clearly
some applications might well have relied on it.


> I wouldn't call the feature 'smart', but rather describe somehow what
> it does, 

What it does it "avoid laying a trap for the user by having a behavior
that tends to be rather surprising".  But that's rather longish as an
argument name.  HOW it does it by "keeping a cache of values retrieved
and/or stored until the next call to method .sync" (that's in the patch
I put on SF, though I think that, as usual for caches, it should be
done with weakrefs where feasible, while still handing not wr-able
values).  That's rather longish too.  If we stick to short adjectives,
alternatives to 'smart' might be 'sane' or 'unsurprising', ot of course
we could flip the boolean and call it 'dumb', 'insane', 'surprising':-).

Clearly I have no good ideas about naming here, but after answering the
N+1 - th poor fellow on the help mailing list that had lost time due to
the trap, I decided that this should ideally be _gradually_ changed --
unless I and the people I help are the only ones who ever use shelve
with mutables, that is:-).

> but I agree that it should be done through an optional
> parameter. Applications that use that feature need to explicitly
> declare that they do. Not specifying the parameter would might cause a
> DeprecationWarning. Then, after some time, the DeprecationWarning
> could be removed, and the default be changed.

Sounds like a good idea.  In 2.2.* we might avoid the DeprecationWarning,
but have it in 2.3, with the default scheduled to be changed in 2.4.


Alex