[Question] Python Formatting
Closed this issue · 10 comments
- What format do you use?
- Would you be opened to reformatting it with a PEP8 standard format? I'm a big fan of the black python formatter, but that's just me.
I'm a retired programmer, so whatever was used in the 90's. : )
I like things compact, so 2 spaces and commands/functions/variables on one line.
I think compact is easier to read, but I'm sure nobody will agree.
How important is it to others?
In the python community, it's quite important.
PEP8 - Style Guide for Python Code is one of the first python enhancement proposals as the creator of python really wanted legible code.
I don't know all the ins and outs of PEP8, but at the very least, it's always 4 spaces in most python projects.
For me, it's not so much about being nit-picky on style, but actually finding an editor that won't put 4 spaces by default on a new indentation..
It really doesn't matter to me, so I guess it's ok.
I can try to comply in the next release (0.7p).
That would be great.
I was thinking of implementing the turbo mode, but have you started implementing it?
I haven't started that. Trying to work on the server/backend to handle the new features before releasing a new client.
I think there may be a case where the node sends a "valid" hash, but it doesn't match the other nodes, so I consider that a failure. It could be an issue for turbo mode because I don't tell the node they failed, I just send the same task again next time (i.e. try again).
I probably need to respond with a pass/fail so the client knows if it can skip the timeout. I'm really worried about "runaway clients" spamming me every cycle when they fail in turbo mode. Need to make sure it only goes "turbo" when it's absolutely sure the previous task was successful.
#7 is another easy one to stop sending hashes with a zero file size. Though I'd need to do something with the error code at the server side.
I really need to get that new algo working. But I can try to update the current algo to accommodate either of these, if you want to start one.
Are you ok with me push an initial PEP8 formatting change?
Or should I leave that up to you to handle?
For the hashes, are you saying that you have multiple users download from the original source but sometimes the hash don't match? I was wondering, how do you handle dynamic ads?
I realize the formatting isn't a big deal, but I'm a little hesitant to keep making changes to this version (0.6). I'd prefer starting a new version (0.7) we can work on without changing the production 0.6 code.
Should I create a branch for 0.7? (I barely know what I'm doing with github)
Correct on the hashes. I validate the hash based on what other nodes have reported (consensus). This prevents malicious nodes from uploading bad content, and generally makes sure all the nodes have the same hash. Nodes could also have network issues, that result in a different file/hash.
DAI is a nightmare. I currently let the first node pin whatever they get from the original source, then instruct the other nodes to pin from the first node, so the hash will match. Podcasters also edit their content after publishing (which is a bigger issue). Currently, the nodes will keep the original file and pin from each other like it was a DAI change.
Generally, on git, people create a dev or develop branch and push to it. When you're ready to make a release, you either create a tag for it, or if you want to still allow updates to that version, like for an long-term-support, than you could branch from there too.
Thanks. I created a develop branch and ran the black formatter on the ipfspodcastnode.py
Let's put the new features here.
https://github.com/Cameron-IPFSPodcasting/podcastnode-Python/blob/develop/ipfspodcastnode.py
Awesome!
Thanks!