Jason Madden

> Apparently the RichText editor here doesn't like preformatted text. (I've edited the message to fix the formatting. It's three backticks on a new line to open a text block...

Argh. This could be entirely my fault. It's possible that I built both the 'm' and 'mu' wheels in the same directory without deleting the `build` directory first (gevent has...

So probably sequential builds in the same directory simply resulted in a bad wheel, and nothing in the toolchain detected that until runtime? I guess I should go remove that...

I just confirmed that if I do `/opt/2.7m/bin/python ./setup.py bdist_wheel` followed by `/opt/2.7mu/bin/python ./setup.py bdist_wheel`, the same intermediate `build` directories are re-used (they don't contain a wideness designation, just arch:...

Half (or less) baked idea: I wonder if this might just be a fundamentally differently managed type of object. Instead of treating it as a Python object with a pickle...

> I'm not sure I follow this, but I think this can all be managed by the container object as easily. > Perhaps I'm missing some benefit of handling this...

Heh, I just came across the need for this in the logs today and went to open an issue...and here it is.

#53 discusses some of the practical issues with asyncio. More fundamentally, ZODB's programming model of transparent demand-paged objects simply does not fit well with asyncio. In ZODB, any attribute access...

Persistent ZODB objects work by [overridding `__getattribute__` ](https://github.com/zopefoundation/persistent/blob/master/persistent/persistence.py#L277) ( to retrieve their state when needed. (Note that this happens in a base class that all persistent objects must extend.) `__getattribute__`...

Even if that were possible (I'm not sure it is) it would be **extremely unpleasant** because you'd have to do that for *every* attribute access. And like a disease, it...