On Sat, Jun 1, 2019 at 2:47 AM Brett Cannon <report@bugs.python.org> wrote:
>
> Brett Cannon <brett@python.org> added the comment:
>
> RE: "I think it needs significant benefits for typical users, not only for Instagram. If only Instagram get benefit from this, keep it as Instagram's internal patch."
>
> But who's typical in this case? You? Me? We're talking code objects, something that the typical Python user doesn't even know exists if you take "typical" to mean "common" or "majority". I suspect if we asked Python developers if they knew what lnotab was an abbreviation of they wouldn't know, let alone how it worked.
>
> And just because Instagram did this work and is making it public doesn't mean (a) others wouldn't use it or (b) others are already doing it privately. There are plenty of other companies with massive server installs of Python beyond Instagram.
>
> My point is we have to be very careful when we start to claim we know what is typical or useful to the wider community considering how huge and diverse the Python community is.
>

I'm sorry for bad word choice.  I didn't mean "majority" or "common".
For example, I was +1 for gc.freeze(), even if majority users doesn't use it.

My point is (a) it's very hard others utilize it, and (b) it's very
hard others confirm the benefit.

And I suspect that Dino's estimation is wrong, but no one can verify
the estimation
because he didn't show enough concrete information.

Elaborately speaking,

* They need to use custom importer and serializer other than marshal
to import code objects.
* They need to use lightweight object for buffer.  At least,
memoryview object is large (192byte
  on Python 3.7.3 amd64).

Even if Instaram can not open source their import system, they can be
show more concrete
data.  For example, their this [1] report is very good at considering
gc.freeze().

[1] https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172

While I agree that mmap pyc files is interesting idea, I feel allowing
buffer object for co_code
is wrong way to achieve it (*).  But there are no enough data to
discuss the benefit.

Current status is Dino claims this idea have benefit in Instagram, but
no one can confirm the benefit.
I think we shouldn't discuss without reliable or reproducible data for
this type of proposal.

(*) One possible idea is code object have just a pointer and length
for co_code, and reference to
   object who owns the data (mmaped file).  code object can load
co_lnotab and docstring lazily too.