survey: is shelve broken? should it be fixed?

[Alex Martelli]

On Wednesday 08 May 2002 12:16 am, holger krekel wrote:
	...
> Might i ask whether you read my suggestion to
> implement the "smart"-switch at the global module level?

Yes, you might:-).

Unfortunately, globals always have downsides as well as sometimes pluses.

Say my program uses frameworks A, B, and C.  How ever should I know
which of those frameworks uses shelve, and how it uses it?  What if
framework B happens to need shelve's old behavior -- how shall a global
flag in module shelve deal with that?  If shelve.open's behavior is
controlled with a local argument, each shelve.open is responsible to know
whether it needs old or new behavior or is indifferent.  This is doable.  If 
the control is less fine-grained, and must apply to ALL shelve.open's in
several independently developed frameworks used by the same program,
I don't think the problem is even theoretically solvable.

It's convenient for middling/small programs which have a few calls to
shelve all under the program author's control.

It's poisonous for very large programs.

Globals are often this way.  Handy for a middling program, disaster as
the program scales up.

If you've ever participated in developing really large programs I'm sure
you know this, and only need to be reminded.

Do we REALLY want to add huge difficulties for authors of very large
programs (who already have many others) to add a small convenience
for authors of small/midddling programs?

Maybe we collectively do.  Personally, since small/middling programs
give me so few problems in Python, I wouldn't skew architecture in their
favor -- on really large programs, despite all of Python's pluses, I _still_
need all further help I can get.

Eschewing globals IS further help for very large programs.  Thus, if the
decision was up to me, i'd eschew globals.


Alex