Re: [tor-dev] Chutney code refactoring

On Fri, 15 May 2020 11:20:54 +1000 teor wrote: > You could try deleting functions, and then running tor's > "make test-network-all". If that test still passes, then the code is probably > unused (in practice). > > Chutney's CI does a few more tests for different tor versions, but I'm pretty >

Re: [tor-dev] Chutney code refactoring

On Thu, 14 May 2020 19:58:45 -0400 Nick Mathewson wrote: > isInExpectedDirInfoDocs looks like it might once have done something useful. My impression is to remove it unless we anticipate needing it in the near future. > configure and restart and wait_for_bootstrap are all in use; they are >

Re: [tor-dev] Chutney code refactoring

Hi Caitlin, > On 15 May 2020, at 09:59, Nick Mathewson wrote: > > On Thu, May 14, 2020 at 7:04 PM c wrote: >> >>> On Sat, 18 Apr 2020 11:02:03 + >>> c wrote: >>> >>> I came across Node.specialize() which does not seem to be called >>> elsewhere, and I cannot guess at its purpose. >>

Re: [tor-dev] Chutney code refactoring

On Thu, May 14, 2020 at 7:04 PM c wrote: > > On Sat, 18 Apr 2020 11:02:03 + > c wrote: > > > I came across Node.specialize() which does not seem to be called > > elsewhere, and I cannot guess at its purpose. > > I ran vulture (a static analyzer for dead code), trimmed the output to > omit

Re: [tor-dev] Chutney code refactoring

On Sat, 18 Apr 2020 11:02:03 + c wrote: > I came across Node.specialize() which does not seem to be called > elsewhere, and I cannot guess at its purpose. I ran vulture (a static analyzer for dead code), trimmed the output to omit things I know were being used (some functions/attributes are

Re: [tor-dev] Chutney code refactoring

On Fri, Apr 17, 2020 at 10:03 PM c wrote: > > On Fri, 17 Apr 2020 18:01:42 -0400 > Nick Mathewson wrote: > > > > Though I think this is likely to be an ongoing change that we see > > over time, since > > Was this sentence supposed to be longer? Yeah, I'm afraid I do that sometimes. I start

Re: [tor-dev] Chutney code refactoring

On Fri, 17 Apr 2020 18:01:42 -0400 Nick Mathewson wrote: > If you want to work on this it would be helpful to maybe start by > listing (here or elsewhere) some places where you *don't* feel like > you could (or would want to) write documentation: those would be a > good target for devs who

Re: [tor-dev] Chutney code refactoring

c writes: > I can look into this; personally I have no experience with Python > style-checking or linting tools, but now's a good time as ever for me > to learn what is available and how it would work for Chutney. For style-enforcement, things seem to be converging around "black" in the Python

Re: [tor-dev] Chutney code refactoring

On Fri, 17 Apr 2020 18:01:42 -0400 Nick Mathewson wrote: > If you want to work on this it would be helpful to maybe start by > listing (here or elsewhere) some places where you *don't* feel like > you could (or would want to) write documentation: those would be a > good target for devs who

Re: [tor-dev] Chutney code refactoring

On Wed, Apr 15, 2020 at 11:45 PM c wrote: Skipping over some design stuff that seems reasonable. [...] > Here is what I have been considering lately, with the code overall. I > hope that laying it out in points will help both myself and others try > to divy up what could be improved about the

Re: [tor-dev] Chutney code refactoring

On Thu, 16 Apr 2020 20:12:18 +0400 meejah wrote: > As to the specific DictWrapper issue, I also found this confusing. It's > kind of tied into a custom templating system too. I would question > whether this is a good idea; there are many templating systems already > for Python -- what does

Re: [tor-dev] Chutney code refactoring

Context: I've done a lot of Python development and once upon a time delved into Chutney a little bit. In general I agree that there are some confusing things including inheritance. So, I think giving it some love through refactoring would make it more approachable. As to the specific DictWrapper

[tor-dev] Chutney code refactoring

I was going to mention this on my pull request but I figured it would be much more fitting to have a more-general thread here. In the PR I mentioned how I believe that, if it quacks like a dict, it should be implemented as a dict. That way we