Usage docs are... less than useful.

[ferringb]

The usage docs are import lazy_object_proxy, which is... kind of obvious. :) . More to the point, they're just that. I'm fine reading the source, but I suspect your goal is folks not having to do that.

Being you've got sphinx, that can be wired to at least give signatures and invocations for the library- IE, how to use the lib. I'd like clarification there isn't a reason the docs are empty before I contribute that code, however.

Also, I don't see how you're doing your publishing to readthedocs- is this manual? I ask since wiring the doc updates I mentioned isn't hard. The pissy part is just doing it in a version mannered however.

The tone is joking- but my offer of "let me know what you need and I'll sort it" is the main point here. I'd already have cut a PR if it was clear of your intent.

[ionelmc]

Docs building is automated, config is here: https://github.com/ionelmc/python-lazy-object-proxy/blob/master/.readthedocs.yml

Not sure what you're proposing. Kinda pointless to document all the special methods since this is a proxy that just proxies all the special methods. Maybe you want more or better examples? Kindly point out where it's lacking.

[ferringb]

Pardon, my tone was flippant for humor, but uh... quite assholish in looking at it afterwards. Sorry about that, assume I say that being on the receiving end of a-hole tickets.

My request for documentation is actually technical- specifically how transparent the proxy is in regards to just outright lieing and appearing as the resultant object from the thunk.

You know this doesn't fly:

>>> class foon:
...     def __call__(self): print("asdf")
>>> 
>>> f=foon()
>>> f.__call__ = lambda s: print("fdas")
>>> f()
asdf

That's due to cpython not using thing.__getattr__ to pull the special members that are func ptrs on the underlying C object. There's enough it's annoying. This implementation is from py2k era when I wrote something equivalent. I needed the resultant proxy to fully 'lie' through its teeth including for those stupid internal cpython spots where the proxy must be in the class, and where the 'shape' of the class actually influences behavior.

I don't know if modern python's hasattr has special casing to first check the tp_* bits or not, but it 's an example of what I mean for 'shape'. For my implementation, I plumbed the guts of the cpy object- I've not done the same for modern py3k. IE, the things I'm concerned about may not be relevant, but the documentation didn't state the esoterics, thus I raised the ticket.

For most folks "it proxies" suffices- I'm asking since I'm looking to replace my implementation, but I know I have downstream code that was deeply sensitive to never seeing that there was a proxy in use.

Can you clarify either here, or preferably in the docs, how transparent this implementation is?

One difference in our API's was that I required knowing what the resultant class would be, so I could shape a proxy that had the same tp_* shape. I've no clue if that is still relevant now, but this is the sort of intrinsic details I'm hoping the documentation can ellucidate.

Hopefully that's a more usable ticket ;)