ambivalence

Please note that according to the benchmark in this blogpost, CPython's builtin JSON decoder is faster than ujson.

What they're describing here is close to the popular 16:8 variant of intermittent fasting. I found that it doesn't really work for weight loss for me.

Instead, I'm using the Every Other Day Diet variant of intermittent fasting which arguably is the best researched one. It helped me drop weight significantly in 2015 with little trouble (details: http://lukasz.langa.pl/9/i-lost-26-pounds-in-3-months/).

Sadly, since I stopped cycling regularly two years back and dropped the diet a year ago, I regained what I lost and then some. So I'm back on intermittent fasting now.

Recommendations based on my experience:

- weigh yourself daily in the morning, as the very second thing you're doing

- a Withings scale or similar helps putting this in a database efortlessly which helps seeing trends

- observe your moving average of 7 days

- eat just a light lunch (circa 500 kcal) every other day; it's easy to skip breakfast knowing there's going to be lunch soon and it's possible to skip dinner knowing "it's Eat Day tomorrow!"

- eat what you want on Eat Day but do it slowly, your body will quickly adapt to your fasts, the stomach will shrink and it's going to be easier to get full

- let people know you're losing weight and how, they will probably tell you you're more grumpy on Non-Eat Days

Good luck!

I must be missing something here. Assuming on a napkin that all users roughly generate the same amount of revenue, losing 10% of them will lose you 10% of your profit, no?

If anything, users of really old iPhones are likely to be less spendy so you're losing less than 10%.

In my time at Facebook that was the killer feature of Nuclide which switched most people to Atom. Ironically, the remote debugger was based on the Visual Studio Tools for Python one.

This experience must have been with a formatter different than Black. That one has no problems with any valid syntax.

Open APIs led to some of the biggest anti-Facebook stories over the last two years. I'd also like to see external clients and so on, but I don't expect that, given how many problems that brings.

Looks like there might be a happy end after all:

http://www.prionalliance.org/2018/12/03/end-of-the-year-upda...

Facebook is migrating everything. The Instagram migration in particular got quite a bit of press coverage due to the PyCon keynote.

Other organizations may choose to not rewrite or migrate. At their own peril. Likely a third party like RedHat will continue patching 2.7 for their customers but no Python.org releases will be done anymore.

More importantly, after 2.7 EOL library maintainers will drop support like it's hot. And that no single player will be able to continue supporting.

So, you might get a few more years out of 2.7 but it will be an increasingly frustrating and insecure experience.

Sigh, looks like you're right. The person who reported the updated version to me in fact saw their homebrewed Python 2.7 as 2.7.15. So I buried a good chance to raise visibility to the issue when it was still on the front page.

Hey everyone, tweet author here. This was posted in June. In the 2.5 months since that tweet Apple apparently did update Python on Mojave to 2.7.15.

Could an admin take this submission down or flag it?

Why this blew up just today is very surprising to me.

FCA and its Dodge line. For example, the Challenger is essentially the same car sold since 2008, save for a few new engine options (3.6L and 6.4L in 2011, Hellcat in 2015, Demon in 2018) and a minimal lighting and interior facelift in 2015.

In case of FCA the speculation is that they will sunset the brand in the USA to focus on SUVs (Jeep) and trucks (RAM). Looks like focusing on what's generating the maximum profit. Just like Apple with consumer electronics.

That's not how this works. All the people who are just happy or indifferent about double quotes don't comment about it. And some of the ones that aren't happy about it commented here multiple times.

Judging from the additional stars on GitHub, and projects that just migrated (pytest!), I'd say there's a very vocal minority which is very attached to single quotes.

Did you actually try Black on a line like this?

> Yes. It's pretty much the only formatting style point that we don't have automated.

Alright, fair enough!

> Black doesn't always reformat it, so we might get linter errors from Black formatted code.

Well, as long as it doesn't add new linter errors, that should be fine, do you disagree?

There are always going to be suboptimal formattings and missing transformations but as long as the situation gets better automatically on average and can be further improved with minimal manual input, you should be fine.

You can see how this was done for Fabric, PyPA/Warehouse, and pytest.

General guidelines:

1. One commit with only the automatic formatting. Afterwards you'll be able to skip over it easily with `git hyper-blame` or `git blame $BLACK_REV^ -- $FILE`.

2. Avoid leaving open pull requests. If you do, after landing the blackening commit, blacken all pull requests, too. They shouldn't conflict then.

3. Set up enforcement with pre-commit or CI (you can run `black --check` on Travis or similar).

4. Don't forget the repo badge ;-)

Yeah, call side was fixed in 3.5 but I don't split hairs here. I consider it either 3.6+ or don't put trailing commas after neither signatures nor calls with stars.

BTW, your signature doesn't demonstrate a call with unpacking. What you meant to test was:

l = [1, 2, 3] foo(0, *l,)

This works in 3.5+ but fails on 3.4 and before.

It's open source software created by a volunteer. Using the latest version of Python lets me leverage features which help me focus on the problem at hand. f-strings, pathlib integration, the latest typing module, and so on.

I'm sorry this makes using my tool harder for you but I'm sure there is an easy way for you to install Python 3.6 without destroying your system Python. There's Homebrew for macOS, deadsnakes for Ubuntu, EPEL for RedHat, and so on.

Black does not take existing formatting into account. Doing so would cause non-deterministic formatting (Black would sometimes change its mind about its own formatting and a second pass would cause a different formatting than the first).

With this in mind, it has to enforce a rule around operators. Since any operand might be complex, it's more robust to default to spaces around operands always. Otherwise we would inevitably end up hugging operands with an operator that humans consider too tight. And since that's subjective, there is actually no rule that we can hard-code about that.

I don't have a formal study, just conversations with several legally blind engineers I work with.

You can still type single quotes. You have a tool to convert that for you.

The visual noise complaint is interesting. Do you also consider the letter W to be more noisy than the letter V? Should we discourage the use of noisy letters in the alphabet?

Sounds like you're joking but I'll bite. Yes, it's different because doing what you suggest introduces barriers for people which make landing changes harder. By forcing people to conform to any style manually, especially by blocking them from landing important features and bug fixes due to styling preferences, you are building up opposition. It's just a bad experience for everybody involved.

In contrast, when you're promising that this exact problem won't happen anymore because an automatic tool will handle stylistic preference for your team, people are more willing to accept stylistic choices they (mildly) disagree with. Because on average the style is still better and on average everybody can move faster.

Black and YAPF introduce consistent formatting within an entire file. Ironically, autopep8 goes against PEP 8 by only targetting the places in the file that generate pycodestyle warnings. Some of the warnings are also incompatible with PEP 8 (W503, E203) and the chosen formattings might very well be inconsistent with the rest of the file.

Answered here: https://news.ycombinator.com/item?id=17155205

Answered here: https://news.ycombinator.com/item?id=17155205

Do you find your team enforcing the string quote rule consistently? It seems to me like it's easy to miss at times as automatic enforcement is impossible. Are there no cases where a string that wasn't originally planned to be user-visible ends up being so? I've heard this idea at times but when I looked at actual codebases it turns out it's more of an aspiration than an actual rule. And if you can't depend on it, why have it?

As for number of lines after imports, how is a lack of enforcement there stopping you from using the tool? Black enforces one line but is fine if you put two (on module level). In general, if you give up on the tool due to a missing rule, you end up having to manually enforce tens of other rules that you'd otherwise be free from.

I put it in the README. Let me know if anything is unclear.

> black doesn't even seem to comply with PEP-8

That is just not true. Where does Black not conform to PEP 8?

It doesn't. Use `git hyper-blame` or `git blame $REV^ -- $PATH`.

Sure, there is an additional step but we feel this shouldn't be a blocker for significant workflow improvements.

In fact, a single big "reformat all" commit is better than a bunch of incremental ones that reformat areas that you also change semantically. That is harder to filter and makes diffs harder to follow (which changes are logic and which are just style?).

Colons in slices are implemented to the letter of PEP 8. Your disagreement here probably stems from pycodestyle mistakenly enforcing a different rule (no spaces before colons on if-statements, defs, and so on) in the slice context.

The language itself doesn't have an established standard in terms of string quote usage. If it did, Black would follow it. What repr() does is a weak indicator and how the documentation is written is random, there was not only no enforcement as to which quotes to use, there wasn't even a recommendation. Black standardizes on double quotes since it has clear benefits whereas the other option does not.

I'm working on that. In the mean time use your Unix fu with `find | grep | grep -v | xargs black`.