Hacker News Reader

Comment by cool-RR | Hacker News Reader

Quite similar to my project, Python Toolbox:

https://github.com/cool-RR/python_toolbox

It supports Python 3.

I'd love to explore this further, as it looks like you've put a ton into it, but the simple difference in external documentation being there for bolton makes it much more attractive to me.

Does look like you docstring your functions--can't you autogenerate a docs site?

Edit: I do see the docs site, but it's a pretty sharp subset of the modules. The topical guides are nice, but I really prefer web-accessible basic docs too, so skipping those in favor of topical only isn't awesome from my POV.

I agree, more documentation would be very helpful. Unfortunately, no time...

FWIW, even the most basic module:function:purpose docs would help.

The primary challenge in a toolbox is knowing what tools are there. Having to either browse the code or pydoc it myself to know the scope is a bit of a hump.

First thing I did with bolton was read the docs start to finish. That way when I hit a problem, I'll hopefully remember bolton could solve it.

I will check yours out when I have time to go through it--it looks very multifunctional.

Note that Boltons also supports Python 3, while retaining individual module independence. Happy bolting and cooooool-RRunnings!

4,800 commits without commit messages? Whoa.

Yeah, I get that a lot. I don't believe in commit messages. I know that 99% of developers are disturbed by this, but I think it's the best way to work so I'm willing to deal with people not liking it.

Why do you think it's best to give no indication of what was changed by a particular commit? While I feel strongly against this, I'm really asking out of genuine curiousity, not to bash whatever seems to be working for you :)

I could write an entire article about this (possibly someday I will), but to explain it briefly: I feel it hurts my creative process to have to take the time to write these commit messages at every commit. It's making me not want to commit. I treat a commit as an extended save operation, so unconsciously avoiding saving is definitely not something you want to do. I know most people would object to my use of a commit as an extended save, but I stand by that opinion as well, especially in these days of deploy-by-commit systems like Heroku. Sometimes I make commits that are smaller than a commit message would be so having to write a message will be a big waste.

Also, commit messages are a form of documentation; but they are one of the least useful ones. Much less useful in my opinion than docstrings, topical guides, references and blog posts. So I think that spending time on them is a much lower priority than spending time on the other kinds of documentation.

Thanks for sharing. When I want to commit but it's not a useful unit of work, I'll occasionally just commit with a WIP message and then amend the commit as necessary until it's done and write a real message.

Reply on news.ycombinator.com