ESR "Waning of Python" post

[Chris Angelico]

On Tue, Oct 16, 2018 at 4:18 PM dieter <dieter at handshake.de> wrote:
>
> Marko Rauhamaa <marko at pacujo.net> writes:
> > Or you could blame the parts of the software that create too many
> > long-term objects.
>
> I do not do that because I understand why in my application
> there are many long living objects.
>
> > You shouldn't blame the parts of the software that churn out zillions of
> > short-term objects.
>
> I do precisely that: the blamed component produced a very large
> number of short living objects -- without need and while it should
> have been aware that it operates on mass data - among others from the
> fact that its complete environment took special care to work with
> this mass data efficiently.

Exactly. Long-term objects are NOT a problem. Tell me, how many
objects get created as a web app boots up and then are never destroyed
for the lifetime of that process? To find out, I added this line just
before a very VERY small Flask app of mine goes into its main loop:

import gc; print(len(gc.get_objects()), "objects currently tracked")

There are over 40,000 of them. Now, I can't say for sure that every
one of those objects will stick around till the process shuts down,
but I'd say a lot of them will. They're modules, functions, types,
class dictionaries... oh, and the GC doesn't track strings or numbers,
so that's another whole huge slab of objects that you'd have to count.
If you replace the refcounting GC with a pure mark-and-sweep, you have
to check every single one of them every time you do a GC pass.

(For reference, running the same GC check in an empty Python
interpreter gives around five thousand tracked objects, still mostly
functions.)

ChrisA