Type inference is a feature of the type checker, not of Python itself. I’m fairly sure the type checker that’s being developed by the Astral team will have proper inference, and I’ve also had good experiences with pyright in the past.
Though it doesn’t come close to e.g. Typescript, which is a shame - Python could really use the advanced dynamic type checking features TS has.
I’d interpret that as a local social network app, not map/navigation.
But if both sides are your enemies, they’re both your friends. But if they’re your friends, they aren’t the enemies of your enemies anymore, which would make them your enemies once again. But then they are your friends again. But then
Though naming it by the following year instead of the release year is clearly a marketing move.
Oh, you should have mentioned that - or do you think that fsck is Memtest? It is not.
Hm, unfortunately nothing obvious. And your last boot ended with a crash?
Nevertheless you could try running a Memtest (this can take a while) - it will check whether any of your RAM modules are faulty: https://www.memtest.org/
That’s unfortunately a bit cut off. Could you run this again with the following command? sudo journalctl -xeb -1 --no-pager
Sure, though the immutable design makes it very safe to touch these things.
OP, do this - it’s the best way to figure out what’s happening. It could be any number of issues, e.g. faulty RAM. With the output of the command above people can tell you what to test for.
JS itself is great, I prefer it to most other languages due to the flexibility that it allows. Adding types through TS to safeguard against footguns doesn’t mean you’re not still using JS. You can also add the types using comments instead if you prefer it, which means you’re actually writing raw JS.
That’s your prerogative, but it honestly doesn’t make sense. Typescript adds almost no functionality to JS (and the few pieces it adds are now considered mistakes that shouldn’t be used anymore). It only focuses on adding typing information, and in the future you’ll be able to run TS that doesn’t use those few added features as JS (see the proposal).
You can also add the TS types as comments in your JS code, which IMO shows that it’s not a different language.
Not really, considering Typescript only adds static types to JS. It’s not a different language, it’s an extension.
I wouldn’t use raw JS for anything new, yes. Typescript however is an excellent language.
Sure, but at this point it’s your own fault if you don’t use Typescript to keep these issues from happening.
There is operator overloading happening - the + operator has a different meaning depending on the types involved. Your issue however seems to be with the type coercion, not the operator overloading.
It should not happen no matter why it does happen under the hood.
If you don’t want it to happen either use a different language, or ensure you don’t run into this case (e.g. by using Typescript). It’s an unfortunate fact that this does happen, and it will never be removed due to backwards compatibility.
Sure, but then your issue is with type coercion, not operator overloading.
It should just randomly pick any “1”. Add a bit of spice, you know
That’s the case in many languages, pretty much in all that don’t have a separate string concatenation operator.
Sorry, but that’s absolutely wrong - the complexity of articles can vary wildly. Many are easily understandable, while many others are not understandable without a lot of prerequisite knowledge in the domain (e.g. mathematics stuff).
Yep, and some (e.g. Pycharm) do. They have to be a bit careful with not assuming too much since lots of legacy code is written in fairly terrible ways, so e.g. default parameter values don’t necessarily set the type of their respective parameters, but it’s definitely possible and mostly a choice by the editor/IDE.
Depends on the editor! Pycharm is built on a custom engine by Jetbrains, whereas e.g. the Python VS code plugin by Microsoft (Pylance) is based on Microsofts type checker (pyright).