meejah

Personally, I like (drastically) limiting the options available from the endpoint strings. Currently with txtorcon, you _can_ access the "global" tor instance's configuration via "get_global_tor()". It's kind of hacky/whatever-I-thought-of-first but...

Can you also please include the version of Tor being used?

`socks_endpoint()` does take a `port=` parameter too (it is supposed to use the first socks-port). From the code, it looks like unix-sockets *should* work but I think that "space, and...

Also, thanks for the detailed report!

`SocksPort 9050` (for example) should still be a valid thing in new (and old) configs, right? What do you think won't work with previous versions? I haven't had time to...

If you want to attempt a fix, that would be great! Personally, I try to avoid regular-expressions but also sometimes they are the right option :)

It's kind of just doing "dumb matching", so if you did `config.socks_endpoint(..., port=9050)` then it should find the existing `SocksPort 9050` line (https://github.com/meejah/txtorcon/blob/main/txtorcon/torconfig.py#L629)

The `_ListWrapper` thing is a little weird; it's so that `TorConfig` can present a "synchronous" / attribute interface but can intercept new values (so if you `.append()` a thing, it...

So, I think the value should be `_ListWrapper['unix:... WorldWritable', '9050']` .. that is, a single list with two strings (what you've got looks like a single list with a single...

Yes, I'd accept a PR to do that :) And really, I don't think there's a _good_ reason anymore to support python2; major projects that I know that use this...