I think the general feeling in the community is that the standard library is where packages go to die. Once something is in the standard library, it can't get meaningful features/updates outside of the yearly release cycle. pip and setuptools are already vendoring a TOML implementation, and once you have pip, you can pick from multiple great toml implementations that are all under active development. Maybe once the packages/standards for TOML are finalized and the only thing left to do is fix bugs, maybe then we'll see a TOML implementation in the standard library, but in the modern age where you can fetch dependencies at any time, there's honestly not that much incentive for CPython developers to take on more burden of maintenance and development for the already-massive standard library.
They did settle on something: TOML, in PEP 517/518. There are a ton of in-progress PEPs building on top of PEP 518 to make pyproject.toml the place to put package metadata in a way that will actually be standardized and usable by multiple different packaging tools. setup.cfg is just a crappy form of ini file, with no standards for what it contains other than "what do common tools do". It's a mess, and it's going to get better, but it takes time because consensus is hard and we're all doing this for free.
If you want it in your debugger (or ipython, etc), add an import to your `.pythonrc` or equivalent. Then it's ready and waiting for you without influencing your production environment or other engineer's testing environments.
If you want to use it in all your modules, create a template/snippet so that it's imported at the top ofevery new file you create. Then it's obvious to every new engineer you hire as to what's going on, rather than having non-standard behavior everywhere without any obvious indications.
Even beyond that, if you've imported `from foo import bar` and then `from something import *`, it might work just fine. Then you upgrade the `something` module, and it happens to now include an item named `bar`, and you're suddenly breaking your existing usage without ever having changed your code.
Star imports are convenient, but dangerous in so many subtle ways. There's a very good reason that every major Python linter will call this out as bad behavior.
Python has never used semantic versioning. There is a long history of small, breaking changes between "minor" releases of Python. Eg, Python 3.7 made `async` and `await` global keywords, breaking any case where old code used `async` as a variable name.
As "satisfaction" is such a subjective measure, I'm not sure there's any good public data, but at least a strong majority of folks fill out internal surveys indicating that they are happy in their current roles.
We all find satisfaction in different ways though. Some get it from the products they work on, even if their individual work isn't exciting. Some get it from the actual challenges they're solving and code they're writing. Some get it from the flexibility and engineering-driven work environment and the opportunity to choose which problems they tackle each half. Some get it from the freedom to work 9-5 and have a strong separation of work and home life (barring periodic oncall or the current bizarro pandemic world). Some simply get satisfaction from knowing that the benefits and compensation they receive are helping to protect themselves, their family, and their loved ones, and ensure they have a comfortable life outside of their job.
Many find satisfaction in FAANG roles simply because they have access to one or more or all of those at the same time.
Yes, unions and coordinated negotiation are the correct answer, but that's very difficult to pull off in companies this large with employees compensated so far above the cost of living.
If they're willing to do the integration and support work on their own, then it shouldn't be a roadblock, and they should be able to prove the impact that it offers to other engineers and be rewarded if they did all of the work.
It can vary highly from one half to the next, and changes with your teams, projects, etc. It can be extraordinarily rewarding to work on products that everyone you know uses every day. It can also be very frustrating and demoralizing to work on important components of the stack that noone inside or outside the company ever notices unless it breaks. The golden handcuffs are real, but most of FAANG gives you ample opportunity to switch teams and projects to find something to work on something that interests you, fulfills you, or lets you learn something that traditional companies would never let you work on unless you already had "industry experience". If you are proactive–and are "meeting expectations" in your current position–you almost certainly have the freedom to find something new whenever you start to get bored.
The most recent general election was Dem vs Dem (due to the unique way that CA primaries work). Feinstein still won a strong majority of the statewide vote. :|
Microsoft has been successfully charging subscriptions to millions of players every year without needing to run games in the cloud. Cloud gaming is a play at capturing revenue from people who aren't willing to shell out $300+ for hardware and $60 for every AAA title they want to play.
On Colemak, the T is on the left hand, so the right hand would be moving to the right to press shift, then moving to the left to press the H, the moving right again for E.
After switching to Dvorak many years ago, I picked up the habits for a lot of shell commands to shift my right over two keys, so that my ring finger could hit the hyphen. `ls -l` is much more comfortable to type with middle-ring-middle than pinky-ring-pinky. I'm sure I've picked up other subtle shifts like that as well, and switching to a split layout keyboard also showed me just how much my hands crossed over for F, Y, and X.
We switched a service from 2.7 to 3.5 and saw an immediate 45% reduction in memory usage and 20% reduction in runtime. That's massive IMO. We saw further (but smaller) performances benefits upgrading to 3.6, again when upgrading to 3.7, and expect to see even more with 3.8.
Because no one could ever be justified in moving to Python 3 for AsyncIO, f-strings, ordered dictionaries, assignment expressions, pathlib, new features in shutil/tempfile/subprocess/etc, along with massive improvements to memory consumption, runtime performance, and overall stablility?
By all accounts I've heard, the organizers have wanted to cancel the event for a while now, but for liability and financial reasons, couldn't afford to until they were "forced" to. Eg, venue contracts, sponsorship agreements, etc, generally stipulate that if the conference cancels without good reason, they owe large fees or penalties to the venue, sponsors, etc. The PSF does not have the operational budget to absorb these penalties while also refunding the money for everyone who was planning to attend.
So they had to act as if everything was going ahead as normal while also hoping and planning for any contingency that would allow them to cancel the event without suffering financial ruin.
From what I've used internally, the remote development bits are already better than they were under Nuclide. Adding and managing multiple remote repos/working copies is a breeze.
The point of the article isn't about how expensive gas is, but how much the price of gas varies between different states in the US. It would be like paying $1.46/l in Sydney, while the folks in Adelaide are only paying $0.70/l.
You do realize that VW has been shipping and selling the e-Golf EV for many years now, and in good quantities? They're all over the bay area, and seem almost as popular as the Leaf.
If it's entirely CPU bound, you can use multiprocessing to negate most of the GIL issues, and transparently send inputs/outputs between the parent and child processes. If it's I/O bound, then AsyncIO is a great way to express asynchronous workflows. If it's a combination of both I/O and CPU bound workloads, there are ways to mix multiprocessing and AsyncIO to better saturate your cores without losing the simplicity or readability of Python: https://github.com/jreese/aiomultiprocess
Most likely because a) it happened well before current administration and AG, and b) because Apple didn't saying anything until after it had already been done, rather than declaring intentions and giving the AG plenty of time to draft ridiculous letters.
Meanwhile, my work phone on AT&T has some of the worst LTE coverage imaginable around town in the bay area - constantly without a meaningful data connection - while my wife's identical phone on Google Fi is almost never below fell bars, and her data connection is rock solid.