Any formatter will violate established usage in most Python projects. I find black at least makes your code readable, compared with pprint-esque styles.
This is a strange comment. It sounds like you’re using black wrong. First of all, when you pick Black, you throw away your own style guide (at least where black is concerned; keep the bits about function naming, etc). Secondly, you should only have one noisy commit, that being the very first commit in which you integrate Black. Thereafter, Black runs before code is committed so all code in code review is already formatted. Yes, if you already have comprehensive style linters and a team that agrees on style, you won’t see as much benefit, but you won’t need to maintain your custom linters or style guide or have all of these conversations about style (you also don’t need to iterate with a linter).
I’m pretty sure Black doesn’t do that, it will fit them onto a single line if possible, then it will move the kv pairs onto their own line, and failing that, one kv pair per line. In any case, I’m fine with more lines. Clarity is much more important than minimizing line count.
In this case the shell hasn’t aged well. Besides the globing feature, the bash language is arcane and few can actually reliably write correct bash despite it being ubiquitous. Personally I would like to see a completely reimagined take on the shell.
All the more reason to be glad when said company tilts away from the sort of fringe ideological positions described in TFA. A fortune 50 company shouldn’t be driving extreme positions; if you disagree, consider if they were driving extreme positions antithetical to your own.
Exceptional doesn’t mean uncommon, it means your program is in an invalid state. Your programming style is inherently unsafe, and you are derelict of your most basic responsibility as a software professional if you apply it on any software of consequence. This is why we can’t have nice things.
This thread is discussing whether exceptions are bad for handling unexceptional events. We are arguing that APIs that throw exceptions for valid program states, such as a missing key for some user input, is an abuse of exceptions. There are lots of these APIs in the world and we find that objectionable. You seem to agree with all of that, but you also present yourself as disagreeing with us, and it’s not at all clear what you’re disagreeing with specifically? Are you just being contrarian for its own sake or are we misunderstanding each other?
It’s a poorly designed API, full stop. It doesn’t matter whether or not it has an API to check existence, it’s not the dictionary’s job to know whether or not a missing key is a valid state in the broader program, and most often it is. Moreover, it’s insane to do a separate “if exists” check every time you need some resource. And the world is littered with these poorly designed APIs, as they are idiomatic in Python, JS, C#, and Java.
The problem is that these systems are built in a way in which the data access latter is throwing the exception even though it can’t reasonably know if the record is expected to exist or not. It can’t or shouldn’t know that this is an invalid program state. Specifically, if exceptions are being used properly, you should almost never need to use try/catch.
Those aren’t contradictory views; you are consistent, but your views aren’t consistent with those of the “other people” you refer to, which is my point.
I’m skeptical that there is a significant body of critics that share these patently conflicting views. More likely there are different groups who each value one of these, or more likely still, lots of individuals like me who are fine with specific, entirely consistent concessions from each of these major categories. For example, I would like to see C++ support some sane build and package ecosystem and I’m ok if it breaks my projects. I would also be happy to do away with the C compatibility requirements.
It would probably be too much to ask to re-evaluate every design decision that was predicated on C compatibility, but I would be okay with reevaluating them gradually over decades, deprecating language features here and there. In general we need to get rid of the idea that we only need to write software once and then every future version of the toolchain will support it. Instead I would like to see a world where the language changes gradually and project maintainers simply have to make small, almost mechanical changes every 5 years or so.
Your statement implies a lot of assumptions about a business’s model. Our company cares about user interactions in our app, software development metrics, quality metrics, sales metrics, etc. GA is just one small piece of the puzzle.
“Data lake” may not be the right answer, but GA certainly isn’t.
You’re being pedantic. Docker for Mac shouldn’t use the full VM allotment at idle, full stop. Nitpicking the parent for speaking in terms of the host cores instead of the VM cores is off topic and boring.
Absolutely this. Native apps are just so much smoother, and I say this as someone who really wants the web to win, and who used web apps almost exclusively because my 16GB iPhone 6 had very little space for apps. Also, the quality of native apps was much higher (e.g., Twitter feed doesn’t abruptly jump all over on mobile) although this could just be due to more budget allocation into native apps for whatever reason.
If the language makes you jump through unnecessary hoops to get passable performance, the issue is with the language, not the program. Otherwise we could generalize your perspective such that all languages are above criticism (no languages have problems, users just fail to find and implement the proper hacks).
No, but very often those programs are slower overall because of the pickling cost. Multiprocessing isn’t a magic bullet / there’s a reason threads exist.
> Python is not fundamentally single threaded - it just has a lock that stops it from taking advantage of threads in cpu bound scenarios.
Tomato tomahto
> Python is used in data science because of the C bindings that make it not slow. Also, when in C, you can take advantage of threads since they live outside the GIL. e.g. Dask.
Correct. Python is fast when you aren’t running Python. Of course using C (or anything else) only works in certain situations—there is a cost to crossing the language boundary and very often that cost is greater than what you save by using C. Never mind the added build/package complexity, the security issues, the maintainability issues, etc.
Python is a neat language, but it’s really expensive if your project ever might have tight performance requirements (where “tight” is laughably easy for most other languages). Python can often be made to meet them with enough shenanigans, it’s just costly to implement and maintain said shenanigans.
Async doesn’t help with CPU-bound tasks, but yes, you can rig up systems that involve running multiple Python processes behind a load balancer. It’s just more work.
blocking webservers are a common problem in Python. Even if you have async, all it takes is a CPU bound task or some sync IO deep in some third party library and its lights out for your server, and no debug info for you either.