Readit NewsAs it is, top-level imports IMHO are only meant to be used for modules required to be used in the startup, everything else should be a local import -- getting everyone convinced of that is the main issue though as it really goes against the regular coding of most Python modules (but the time saved to start up apps I work on does definitely make it worth it).
Sure, lots of self-reported successes by patients with no control to compare against, but at this point there is just as much self-reported evidence that prayer works.
For medical treatments, the bar should be higher than "patient believes it worked".
It's a bit unfortunate that people out of the psychology area don't even really know that there are multiple different Psychotherapies approaches and that they vary wildly in how problems are tackled/studied (source: my wife works in the area).
At first glance, Mill looks like it has many of the pitfalls of Gradle: - Plugins: Creates the temptation to rely on plugins for everything, and suddenly you're in plugin dependency hell with no idea how anything actually works. - Build scripts written in a DSL on top of a new language: Now I have to learn Scala and your DSL. I don't want to do either! - Build scripts written in a language that can be used for code too: Versioning hell when the compiler for the build system needs to be a different version to the compiler for the actual project code. See: Gradle and Kotlin
> Mill can build the same Java codebase 5-10x faster than Maven, or 2-4x faster than Gradle
Speed per se can be a good selling point (having to wait for slow builds is really annoying).
I can't really comment on anything else though as I just stumbled upon it here in HN ;)
People when Microsoft pulls this trick (core repo OSS, most useful things around it are full of DRM and legal traps): silence
The hypocrisy is really astounding and in a way, MS has managed to pacify even the strongest FOSS advocates by offering something which looks like OSS but it actually isn't. This is on par with claiming that a repo is GPL but the build API keys are not. (Yes, this also happened elsewhere, and not even in a corporate project at all!)
The Open Source Definition is hilariously unfit for purpose in 2024 because it allows shenanigans like this.
If you enjoy a rabbithole, look at how much DRM there is in Pylance (another extension that MS has locked down): https://github.com/VSCodium/vscodium/discussions/1641
The short summary is that MS uses multiple, constantly changing methods of DRM to make it impossible for people to patch out the "only official VSCode" check from the Pylance extension. This is very clearly malicious.
> INSTALLATION AND USE RIGHTS. a) General. You may install and use any number of copies of the software only with Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server, and successor Microsoft products and services (collectively, the “Visual Studio Products and Services”) to develop and test your applications. b) Third Party Components. The software may include third party components with separate legal notices or governed by other agreements, as may be described in the ThirdPartyNotices file(s) accompanying the software.
One thing I don't understand is how forks (I'm actually talking about Cursor which is one I'm actually evaluatinng) are getting away with scrapping all extensions from the VSCode marketplace... I even e-mailed them but had no official position on that. Maybe they have some separate contract with Microsoft -- they do have OpenAI backing, so, maybe they have some bridge there, does anyone know? Or maybe Microsoft is just waiting to see how they themselves can profit for it and so is taking no legal action at this point?
-- disclaimer: I'm on the author of PyDev and I do have my own Python extension that I publish to VSCode and OpenVSX (https://marketplace.visualstudio.com/items?itemName=fabioz.v...)... it's completely Open Source in Eclipse, but for VSCode it's currently commercial. I discovered that's a nice way to have less people requesting support, even though 99% of it is still Open Source ;)
I use speeding in vehicles a lot. The point of a 55MPH speed limit isn't really that cars should be going exactly 55MPH at all times. It's an approximation of a complex situation that could handle only one number. But it's not actually a law of physics. Rigidly handing out tickets for people doing 56MPH is missing the point of speed limit. (As are many of the "You're doing X over" flashing signs, generally put in places that are precisely where the speed limit is too low and what people are doing is actually fine.)
Now that we finally have the technology to determine whether a gymnast was or was not one millimeter over some line, the question should be raised, is that what we actually want to judge on? Because just because we humans thought we were judging on that, just because we thought that's what we wanted, is it really?
It is this examination step that has been missing in every rush to insert computers into some judging system. We thoughtlessly reify accidents of history and what used to be easy to judge. At least in the case of gymnastics we're not going to send anyone to jail because of such thoughtlessness, but the sport could be destroyed. In the end, it still needs views, however abstracted the sports may seem to be from that, and after the novelty wears off, seeing humans out there competing for the most robotic and soulless performances runs the risk of gradually, but steadily, destroying all support for the sport.
Now, personally, I'm not sure this wouldn't be a net gain for humanity in this particular place. But it's certainly not what the gymastics community as a whole wants and they really need to slow down and apply some thought to what they really want before they let someone reify that into code.
They won't. Nobody else is either, for things far more important than this. But they should.
The general idea is that pydevd will be able to use that API instead of relying on sys.settrace (which was perceived as slow in general -- pydevd got by because it had a bunch of tricks to just trace the needed contexts but implementing a fast debugger in Python with it is pretty hard).
My initial results are still mixed -- i.e.: on some cases it's definitely faster -- such as when tracking exceptions, but at this point in all other scenarios it's still slower (it's pending a few profiling sessions and I already have some ideas on where to improve), but I'm still not sure it'll ever be as fast as the version that can hook into the python frame eval and change the bytecode for the function to add programatic breakpoints... time will tell (but that approach is also very hard to keep up to date on new python releases, so, I'll probably end up deprecating it as I don't have enough time/resources to keep it up to date).
Anyways, I have most tests already passing, but I have to do a few profiling sessions before the initial release. I guess there's no much point in saying: here's a new version of the debugger using sys.monitoring -- does the same but is slower ;P
from __future__ import annotations
Using `if TYPE_CHECKING` is also useful when you want to speed up the module load time by not importing unnecessary modules (unnecessary at module load time).
And then, also to resolve import cycles, where you still want to annotate the function argument types.
One problem though: If this is a type/object which is not needed for module load time (there it's just used to annotate some function arg type), but which will be needed inside the function, type checkers and IDEs (e.g. PyCharm) will not show any problem, but then at runtime, you will the NameError once it tries to use the type/object.
Example module:
from __future__ import annotations
from typing import TYPE_CHECKING
if TYPE_CHECKING:
import torch
def agi_model(query: torch.Tensor) -> torch.Tensor:
torch.setup_secret_agi()
...
Then you would add another `import torch` inside that `agi_model` function. However, then the IDE might even complain that this hides the outer scope `torch`.
That's not entirely True... I just checked it here and Eclipse/PyDev does flag this correctly -- since version 11.0.0 ;)
See: https://www.pydev.org/history_pydev.html (Imports found inside a typing.TYPE_CHECKING will be considered undefined if the scope that uses it requires it to be available when not type-checking).
I guess you meant "run all imports at startup is desirable to check if they work", but I have a hard time agreeing with that (personally I think having a good test suite is needed, whereas running more code at startup is not wanted).