Circular refs

[Tim Peters]

[Adrian Eyre, on immortal cyclic trash]
> I can dream up a million ways to kludge around this bug, but I
> was referring to a 'fix' to the Python source code. How hard can
> it be?

[Tim]
> It's unclear, but I can give you a lower bound:  in all the years people
> have been whining about how easy this is to "fix", nobody has
> managed to fix it.

[John Skaller]
> I think that is an unfair comment. There have been plenty of people
> who have integrated garbage collectors into Python, including me,
> but the effort is wasted if Guido doesn't adopt the solution.

You post this immediately after explaining to Neel several of the miserable
problems with adopting the Boehm-Demers-Weiser collector for Python?  I
stick by my comment:  nobody has come up with a solution.  Every attempt to
date has been unportable, and/or been grossly slower, and/or grossly
increased memory use, and/or grossly violated the semantics people have come
to rely on in CPython.  Guido isn't going to adopt a non-solution, and
that's all we've seen (plus strident advocacy and, well, whining <wink>);
but that doesn't mean the effort is wasted.  For example, Neel seems quite
happy with his BDW patch -- it solves problems for him.  People running on
sufficiently similar platforms may also find it useful.

> The only exception to that is JPython (which does, of course, 'fix'
> the problem).

Hardly -- JPython *never* calls __del__ methods.  JPython settled for what
it could get, just as CPython did -- and as your Viperi/c will do.

> So the problem, in part, is that the state of Python is controlled by
> Guido, who is not willing to adopt any of the solutions.

Give him something fatter than the empty to set to choose from <0.5 wink>.

> Guido has his own priorities and reasons for doing things (which is
> fair enough!)  Unfortunately, this leaves the community with two choices:
> take what Guido offers, or go elsewhere.

Apart from replacing Guido's name with yours, will we have a third choice
with Viper?

> I'm past complaining about that, but I do think it is unfair to say
> people have been 'whining' about it.

Many have.  I whined about it too, in the early days!

> The same applies to making nested functions work correctly. It has
> been done, several times, but Guido is unwilling to adopt any solution,

Look for a long post from Guido, titled

     Re: proposed scoping rules for nested functions..

posted on Wed 11-Sep-96.  That's more than 3 years ago, and the issues he
raised there still stand.  The prime thing that killed adopting lexical
closures was the cyclic trash problem then, and Greg Ewing just bumped into
that again recently in his implementation.  You can argue that any way you
want, but, no, Guido isn't going to adopt lexical closures unless the trash
problem is solved first.

> which leaves Python programmers with a low level, Basic like language.

Well, if people weren't convinced before, that will sway 'em <wink>.

> Eventually, people developing higher level applications
> will be forced to move on to a more powerful programming language.
> Sigh. Even Perl has lexically scoped functions :-)

See Guido's post (referenced above).

> Viper is implemented for this reason: I'm sick of waiting for sensible
> high level features, so I'm implementing them myself.

More power to you!  This is how all programming languages come into being:
dissatisfaction with what's already there, and with the prospects for
changing it.

> My comments also apply to C++ with an important difference: in that
> case, there was a mechanism for me to contribute to the language
> development, and vote on issue resolution (and I did so).

You can vote here too; the only difference is that Guido doesn't pretend our
votes count <wink>.

> So while I may not much like the result of the consensus formation,
> at least the process admitted community decision making, and generated
> a document describing the semantics (that anyone could implement).

But the process did not generate the document:  many people volunteering
many person-years of hard work generated the document, most of them
subsidized by their employers.  Python's semantics are no worse (or, for the
most part, better) documented than those of Perl, Icon, SNOBOL4, Gema, or
most any other language designed & implemented by a committee of one.

In real life, what drives clarification of semantics is alternative
implementations.  The vast majority of any language's *users* ignore the
std, happy to assume that whatever their current platform does is "it".  Jim
Hugunin's efforts to get JPython going did more to clarify Python's rules
than the entire community combined before that point, and your wrestling
with Viper may have a similar good effect -- provided you make your
deliberations public.

rigorous-docs-don't-write-themselves-ly y'rs  - tim