For those looking for a better language server for python, I would recommend ruff. As of v0.4.5 it's completely written in rust, and much faster than pylance.
If you've got the ruff plugin installed it should use it by default. Should be able to use it in zed as well.
The last time I commented extolling the virtues of uv on here, I got a similar reply, pointing out that PEP 723 specs this behavior, and uv isn’t the only way. So I’ll try again in this thread: I’m bullish on uv, and waiting for Cunningham.
I am all in on uv as well, and advocating for its use heavily at $dayjob. But I think having as much as possible of these things encoded in standards is good for the ecosystem. Maybe in a few years time, someone will make something even better than uv. And in the meantime, having things standardised speeds up adoption in e.g. syntax highlighting in editors and such.
I’ve started migrating all of my ~15 years of one-off python scripts to have this front matter. Right now, I just update when/if I use them. I keep thinking if were handier with grep/sed/regex etc, I’d try to programmatically update .pys system-wide. But, many aren’t git tracked/version controlled, just laying in whatever dir they service(d). I’ve several times started a “python script dashboard” or “hacky tools coordinator” but stop when I remember most of these are unrelated (to each-other) and un/rarely used. I keep watching the chatter and thinking this is probably an easy task for codex, or some other agent but these pys are “mine” (and I knew^ how they worked when I wrote^ them) and also, they’re scattered and there’s no way I’m turning an agent loose on my file system.
^mostly, some defs might have StackOverflow copy/pasta
You could run ripgrep on your file system root to find most of them, its insanely fast, then feed it to claude or something to generate a script to do it for you.
This is an awesome features for quick development.
I'm sure the documentation of this featureset highlights what I'm about to say but if you're attracted to the simplicity of writing Python projects who are initialized using this method, do not use this code in staging/prod.
If you don't see why this is not production friendly it's for the simple a good.reaaon that creating deployable artifacts packaging a project or a dependency of a project this uses this method, creating reproducible builds becomes impossible.
This will also lead to builds that pass your CI but fail to run in their destination environment and vice versa due to the fact that they download heir dependencies on the fly.
There may be workarounds and I know nothing of this feature so investigate yourself if you must.
This isn't really "alternatively"; it's pointing out that in addition to the shebang you can add a PEP 723 dependency specification that `uv run` (like pipx, and some other tools) can take into account.
I'm actually a bit annoyed that uv won. I found pdm to be a really nice solution that fixed a lot of the issues poetry had without the hard ideological stance behind it, while fixing most of its problems. But maybe that ideology was partly what drove it's adoption.
Yeah, but you need Nix. If we are reaching out for tools that might not be around, then you can also depend on `curl | sudo bash` to install Nix when not present.
amazing quote. Adding it to my about page, do you want credit or shall I credit it to archimedes xD
On a serious note, its so brilliant that something like this is now possible when we think about it. It's maddeningly crazy to think about all the process but in the end that you can end up with a system / linux iso whose hash you can trust/independently verify and then you use it and spread around the world. Definitely makes me feel as sky's the only limit or just its very pleasant to think about it.
The issue I have with `nix-shell` is that the evaluation time is long, so if you need to run the script repeatedly it may take a long time. `nix shell` at least fix this issue by caching evaluations, but I think uv is still faster.
That shebang will work on GNU link based systems, but might not work elsewhere. I know that’s the most popular target, but not working on macOS, BSDs, or even busybox.
> Then you don't even need python installed. uv will install the version of python you specified and run the command
What you meant was, "you don't need python pre-installed". This does not solve the problem of not wanting to have (or limited from having) python installed.
I'd like someone to do a comparison of tech company valuations pre GenAI vs post for the same vertical.
I understand there's always some optimism for new tech, but the valuations we're seeing seems absurd to me.
Like, do they expect to see x100 profit for the same vertical? Obviously some new markets have been created, but I don't see them solving any particularly novel business problems.
This is actually bearable compared to the new terminal suggestions in vscode. Not only does it autosuggest bizzare completions for commands, it breaks shell completions. So when I tab a file path, it shoves the absolute path into the partially typed path making it unusable.
Yeah for anyone else (especially Mac and Linux users) who recently had this frustration thrust upon you: Go into VSCode settings and search for terminal integration > uncheck.
I've seen some weird breakage recently in vscode. The C++ support failing to parse sources correctly (for LLVM), Rust debugging no longer showing vectors properly. Not sure if this is some bizarre interaction with my setup (which is pretty vanilla Ubuntu) or a regression in basic functionality brought on by an over-emphasis on AI features.
It is worrying that for many months now, pretty much all the content of changelogs has been about AI.
Recent changes have been a little invasive. The terminal auto complete was a week or so ago, and the popular Gitlens extension also recently pushed a really poor rebase interface. Besides those two in the last weeks, I can't remember any time VS Code has messed up my workflows so badly.
It does weird stuff. I've bitched about it do much to my workmates until they disabled autoformat features wich cause 5k line conflicts in SCM. I'm ysing codium which also does Clippy dmart stuff trying to be helpful and breaks code. They keep pushing AI junk and break functionality to the point that I'm looking for another editor with usable muliple cursors (not *vim and not helix which breaks my vim muscle memory).
They broke it again today with release 1.107 which throwns a weird shadow when I resize the window in Gnome. Got fed up with it, so I pinned the package to 1.106.
Hi from the VS Code team - I recently went into detail about why we did this in https://github.com/microsoft/vscode/issues/282268#issuecomme.... We believe it'll be beneficial overall and go a long way in lowering the bar to make the terminal less intimidating for newcomers. Conflicts with muscle memory was always a big concern which is why we made extra effort to be able to turn it off, the comment below that one outlines some steps we're making to make it more easily configurable inline.
On the roll out side, this is what we observed:
- It was enabled in Insiders for several months, generally only very positive reactions
- It was surprising to me that we shipped this to 25% of our stable users and basically no one complained for 2 weeks before we rolled out to 100%
- After hitting 100% of users we did see some backlash like this comment
- Of course telemetry doesn't show the whole story, but we try to determine both whether the completion was modified and whether the command was successful after using it and both numbers stayed relatively stable since shipping in Insiders at what we consider pretty good numbers (both accept without editing and command success rate is ~80%).
I've had to take a beat to find the right words as all the frustration in the issue ticket impacted me too which has left a very bad taste in my mouth after being initially curious and open to the new feature.
I think you're doing a disservice to newcomers by creating a new method of autocompletion. And I say that as somebody who has mentored a lot of newcomers in high school, University, and now professionally. Very often, including just yesterday, I'll hear something like "I don't really know how to use [very standard thing], we had [esoteric helper] instead." Yesterday it was for makefiles. Their school just abstracted it away to make it easier for them, so they don't know how to make a simple makefile to compile a few source files together. Or literally any other build system, including cmake. So, Lord have mercy on my soul if I have a new hire tell me "I don't know how to use the regular terminals. All I can use is VSCode's terminal." I think sometimes things should be hard, but I don't think terminal autocomplete is very hard. Just hit tab a few times and it'll do its thing or -h.
Where it might come in handy, and I haven't tested this, is programs that haven't registered their completions. For example, I'm often cross compiling, and it would be nice if it knew that ...-objcopy had the same completion as the host objcopy. But I am not going to take the hit of the bad pathing just for that.
I'll conclude with a lesson in biases: your insiders are biased. You need to recognize that only egregious errors might be statistically significant. Not only are they more power users, they're new feature hunters, and more than that, they want new VSCode features. Also, that's very creepy y'all are looking at my command success rate even though I'm not an insider. And if you look at the issue ticket, you'll see that a lot of the issues wouldn't cause failure. `Git add` on the wrong file isn't a negative return code, and they might just muscle memory press enter before seeing they need to edit. A possibly better metric is how many times did the user run the same command up to the completion point. But please don't collect that data, that's creepy. I'm going to have to look through my settings to try and turn that all off.
> So, Lord have mercy on my soul if I have a new hire tell me "I don't know how to use the regular terminals. All I can use is VSCode's terminal." I think sometimes things should be hard, but I don't think terminal autocomplete is very hard. Just hit tab a few times and it'll do its thing or -h.
Thanks for the insights. Something I've learned here is that the vast majority of users don't change their defaults or seek out features they may find very useful. Discoverability vs simplicity/bloat is a hard problem and that's essentially the issue here.
I made a note on the issue that with the planned changes to make it easier to configure, we should consider not overriding tab by default anymore. That would mean that only down arrow is bound by default which would then put focus into the widget.
> I'm going to have to look through my settings to try and turn that all off.
Full details at https://code.visualstudio.com/docs/configure/telemetry, but setting `"telemetry.telemetryLevel": "off"` will disable usage/crash/error telemetry for the VS Code core. Just keep in mind extensions may or may not respect that.
I agree with the point that making the VS Code terminal behave in a special manner without opt-in is going to be disruptive to newer engineers. Why not make it a shell plugin instead and offer to install/customize the shell the first time someone launches a new shell in VS Code instead? Then it changes it system wide, like oh-my-zsh or something would.
While I agree that new feature adoption is hard, changing tab completion is a bit hardcore. I agree that a different key bind, maybe right arrow key, or shift tab, or something would have been better.
Here's a suggestion: maybe you could not track all of our activity extremely invasively by default, and allow those who would like to provide feedback and tracking to enable it on their own. Crazy thought, I know.
No, it's really not that good a feature and turning it off improves my experience so I don't care if they're the only ones with it. That said, if it's part of the open source, when better. And even if it was, I can't complain that a business made a program has a unique feature to attract users.
Nobody at Microsoft has ever used this with WSL, and doing a "cd /", and getting autocomplete for "$RecycleBin" and other windows paths? It completely breaks bash autocomplete, and every single suggestion is completely wrong, in every single command i type.
I, and probably most uses, just hoped this going away as soon as possible again.
One of the things we should definitely action is hiding it in more places where it doesn't work well, that's one of the key pieces of feedback we got and is tracked in https://github.com/microsoft/vscode/issues/282578
The insane behavior in the post is not that you get fancy completions, but that the completion does not match the preview. If the computer starts doing A when you asked it B, it is equivalent to a trash can.
The feedback you receive is from a selection of people who’re trying new features, not people with existing patterns that is broken one of a sudden with an update while they’re trying to get stuff done.
This a byproduct of metric-driven development. The result is a creepy manifestation of force-fed features backed by "telemetry" (action and result logging, and sometimes keystroke or string logging), but I don't place any blame on this developer; this is the way it has been at that company for a while and that horse has long since left the barn.
Certainly this may not even be intended gesture, but it will result in unknowable metric of users being insulted by the half-baked forced nature of these product changes.
I appreciate the effort you put into developing this. However, I'm honestly shocked you received only positive reactions. I booted up my system today and found that it made terminal nearly unusable. The old tab-complete behavior gets you to the branch point you want fast, minimizing typing time. The new behavior quickly shoots past the relevant branch point, meaning I spend considerable effort going back to edit commands.
Also, speaking as an educator, I think there might be a misunderstanding about what makes things intimidating for new users. Systems that make specific decisions without being able to easily control them makes things more intimidating, not less. And if I'm reading your post correctly, it sounds like you are trying to introduce a feature on newcomers, but your internal testing was done on insiders and stable users -- a different population.
Frankly, at this point I may strongly discourage all of my students from using VSCode.
First of all, I appreciate and respect you coming here and defending your choices. That said:
I think that bar-lowering is not really something that Terminal users want, if they wanted simplicity they wouldn't be in a terminal in the first place, at least that holds true for a large portion of the Terminal users.
Sure there are always the new users, who may benefit from some hand-holding. But why don't you ask first if people want their hand held? Normal terminal users are looking for a way to control their computer in a more direct fashion, which makes them faster. They seek a more predictable interface, by moving closer to the true language of the computer itself, by learning a bit about how it works inside and subsequently adapting oneself to it.
You have chosen to alienate a large group of highly knowledgeable users for a user group that may be mostly a myth.
What would make more sense is to provide a switch for "noob mode", while leaving the core experience alone. I for one already hate the difference between my normal terminal when it comes to ctrl-c/ctrl-v and pasting with select/middle-click. This current change feels like a slap in my face.
I don’t know if this is related, but for me the terminal is broken and causes VS Code to crash. It only happens after a command finishes executing and before the shell prompts again
Nope, not crazy. Pretty much solely used it for years but got a lazyvim* setup last week
Still has excellent integrated debugging and is more familiar than nvim, but it has really started to get in its own way the past couple minor versions
*Not "lazy I'm" (though perhaps I am for letting that slide)
after two decades my muscle memory in the terminal is pretty important. that + with keyboard shortcuts ive had multiple jobs ask me to "slow down" when doing screenshares as everything moves so fast.
Ha, was going to come here to complain! It completely breaks my up arrow is history search based on typed chars. First thing I do on a Linux box (and it will blow your mind) is put this in ~/.inputrc :
If you think that you can just start "enhancing" people's terminal experience like it's a Windows 11 taskbar, I don't think you understand terminal users. It's all good, but make it opt in via some config file (i.e. ~/.bashrc)!
For modern scientific rebuttals to race science, I'd start with Sasha Gusev and Eric Turkheimer. You'll read about things like missing heritability and the methodological problems of twin studies (which are grave). I'd also read Cosma Shalizi's "g, a statistical myth", which is also fun just from a sort of mid-level math/stat perspective. A classic in the field that still holds up is Ned Block's "Race, Genes, and IQ", written as a response to The Bell Curve.
I don't have offhand good links to critiques of Gould that are on any site I would recommend you read.
One could argue that learned speed has the hours of practice "baked in" so it's actually much slower. And that's not a bad thing IMO.
I think this post only covers one side of the coin. Sure, getting things done fast achieves the outcome, but in the long run you retain and learn less. Learning new stuff takes time and effort.
Statistical significance comes mostly from N (number of samples) and the variance on the dimension you're trying to measure[1]. If the variance is high, you'll need higher N. If the variance is low, you'll need a lower N. The percentage of the population is not relevant (N = 1000 might be significant and it doesn't matter if it's 1% or 30% of the population)
[^1] This is a simplification. I should say that it depends on the standard error of your statistic, i.e, the thing you're trying to measure (If you're estimating the max of a population, that's going to require more samples than if you're estimating the mean). This standard error, in turn, will depend on the standard deviation of the dimension you're measuring. For example, if you're estimating the mean height, the relevant quantity is the standard deviation of height in the population.
For example, even 300 really random people is enough to correctly assertain the distribution of population for some measurement (say, some personality feauture).
Because the accuracy of an estimated quantity mostly depends on the size of the sample, not on the size of the population [1]. This does require assumptions like somewhat homogenous population and normal distributions etc. However, these assumptions often hold.
If you've got the ruff plugin installed it should use it by default. Should be able to use it in zed as well.
reply