meejah

I can get rid of the first traceback (and see the second more-reliably -- but still not "always") if I decorate the method with just `@inlineCallbacks` instead of `@inline_callbacks`..

The thing that is slow in txtorcon is the "microdescriptor parser", which is here: https://github.com/meejah/txtorcon/blob/master/txtorcon/_microdesc_parser.py#L6 This parses a pretty simple line-based file (well, actually its streamed from the network) that...

Okay, here's a simple test-case. I haven't worked it into an "actual benchmark", but did confirm that this shows similar ratio: ~56000 inputs/second vs ~230000 inputs/second by commenting-out the `@wraps`...

I'm not sure if it's possible, but I think the *best* course would be completely eliminating the "create a new function + decorators on every `__get__` call". I haven't looked...

Ah, interesting I'm seeing this same error in Tahoe -- but only under PyPy. My **theory** is that's because somehow pypy is burning in a newer OpenSSL (or better defaults)

Foolscap makes non-standard use of TLS .. I'll let @warner comment on the details, but I can't immediately think of any reason you couldn't just regenerate the keys. (His note...

Not sure of a _better_ way, but one way would be to instantiate a `Tub` (https://github.com/warner/foolscap/blob/291df027d5770f5edd6df01368de3e2cf273ccdf/src/foolscap/pb.py#L124) with the cert data and ask it for its `.tubID` .. then compare the...

I _think_ the (only) failure is due to new-enough Python3's refusing to compare `None` to numbers (whereas earlier versions would do .. something). Other than that, LGTM

To clarify, I believe the current Tahoe plan is **not** to have a "flag day" but to support python2 and python3, deprecate Foolscap and move to an HTTP-based API ......

txtorcon dropped txsocksx by growing its own Python2+Python3 SOCKS5 client -- splitting that out would certainly be a possibility (note that it's currently doing custom Tor SOCKS5 opcodes too)