Live data from Hacker News

Python in Visual Studio Code

blogs.msdn.microsoft.com

51–60 of 202 posts

Re: Python in Visual Studio Code

#51
post #23

Tried to use python within vscode last month, it works fine, but I still have to hack around for my own workflow. I eventually switched to pycharm for its autocompletion, class help, even pipenv support natively built-in. for html/css/js I keep using vscode though. there is no such thing called universal editor, I still have to use various(vim,geany,vscode,pycharm...) for different scenarios, which is fine but just v…

I've been trying to get into VSCode for Python development, especially Django since the first official release of VSCode, every time I returned to PyCharm.

I just decided to accept PyCharm the only IDE that can make me productive and go fast!

Re: Python in Visual Studio Code

#52
post #4

I am somewhat embarrassed, but also relieved to admit that I switched from vim (nvim to be precise) to VSCode (OMG M$FT!) and am very happy about it. I still use vim bindings as much as I can, but I guess giving up a bit of ideology can benefit one a lot. Although, that is until I start running out of memory on my personal laptop, then it's back to the terminal!

The vscode vim bindings are atrocious. I use them because there's nothing better, but they're bad . Slow, super buggy, and did I mention slow? I hit tab and sometimes instead of inserting a \t, it inserts the letters " ". And it re-runs mypy/flake8/etc whenever I enter or exit insert mode, which I do a ton... so my CPU is constantly pegged. And commands like "2d}" don't delete the correct amount of paragraphs. And on…

What's the bug that you have with `2d}`? It seems to work fine for me.

There shouldn't be any reason that it reruns save upon entering/exiting insert mode; are you sure you don't have some kind of keybinding/other setting that's autosaving for you?

The `` issue is kind of a pesky race condition that's most likely exacerbated by VSCodeVim running slowly on your computer.

Speaking of it running slowly, I would argue against characterizing them as "slow". Some small subset of users seems to have consistently run into this issue, and a decently large subset of those users have realized that the issue is caused by some conflicting plugin, so I'd suggest trying that too.

As for the undo issue, I have mixed feelings about it. Perhaps it could be synced with VSCode, but it's definitely true that when it was first implemented, VSCode did not provide the flexibility to do so.

Overall, I do agree that there's stuff that can improved, but it kinda hurts to see people call them "atrocious". I suspect your main issue with VSCodeVim is really the "slowness" issue. I would try disabling other plugins and see whether it helps.

EDIT: Forgot to mention. Disclaimer: I'm one of the primary maintainers for VSCodeVim.

Re: Python in Visual Studio Code

#54
post #24

I've been using VI since the 90's and VIM since... well the 90's. VSCode is the first IDE I've been able to live, and happily. It blows my mind. I have a tonne of tooling around automated python environments, vim plugins (now vscode plugins), tasks - and it's made the whole thing significantly more 'unixy' than it was before. And to think - MSFT! I have git hooks for my homedir's dotfiles that automatically look to s…

Just out of curiosity, what are some of the tasks that you run in vscode ?

I've never found a real use for them, so I want to know what other people use them for.

Re: Python in Visual Studio Code

#55

Earlier quoted context omitted.

The Python VSCode extension started out as an independent open source project. It independently reached a pretty high level of maturity - and helped VSCode get popular among Python developers - before, a bit under a year ago, Microsoft hired the maintainer. Since then it's acquired a few new goodies, but most of what makes the extension great happened before Microsoft adopted it, so I shouldn't think there's anything…

Following up on that - Shooting from the hip, though, if the desire is for funding, I'm guessing Microsoft wouldn't see much strategic value in putting money into a Ruby extension. The Ruby ecosystem has largely congealed around an ASP.NET competitor, some devops tools that don't really work on Windows, and not much else. Python, on the other hand, is widely used in Microsoft shops. Windows shops need data scientists…

Maybe that might change now that they bought github (heavy users of ruby) but I doubt it ;)

Re: Python in Visual Studio Code

#56
post #12
post #4

I am somewhat embarrassed, but also relieved to admit that I switched from vim (nvim to be precise) to VSCode (OMG M$FT!) and am very happy about it. I still use vim bindings as much as I can, but I guess giving up a bit of ideology can benefit one a lot. Although, that is until I start running out of memory on my personal laptop, then it's back to the terminal!

I would really love to ditch more of my nvim setup for vscode, but this bug [1] from 3 months ago absolutely wrecks my productivity. I rely on splits as the primary means to navigate the codebase and having a single cursor position per file is maddening! The vim bindings aren't perfect and are sometimes slow (you can see a macro insert things character by character) but about on-par with IdeaVim for the IntelliJ side…

Ooohhh, this is something that I've been meaning to get back to...

There was an atrociously bad "undoing work" issue that I popped out of hiatus to fix, and that bug was the cost of the fix. I meant to add proper support for that, but me not using splits that much (especially for the same file) as well as other commitments have prevented that.

Re: Python in Visual Studio Code

#57
post #24

I've been using VI since the 90's and VIM since... well the 90's. VSCode is the first IDE I've been able to live, and happily. It blows my mind. I have a tonne of tooling around automated python environments, vim plugins (now vscode plugins), tasks - and it's made the whole thing significantly more 'unixy' than it was before. And to think - MSFT! I have git hooks for my homedir's dotfiles that automatically look to s…

How do you have global tasks setup?

Re: Python in Visual Studio Code

#58
What's mind blowing is the community support behind VSCode. If you report a bug, you get a reply in less than 24h, your bug gets tagged, assigned to someone and fixed ASAP. Then you get a new release every month with ton of bug fixes, improvements and new features.

Compare that to any other IDE or even any other open source projects.

Re: Python in Visual Studio Code

#59
post #30

I wonder how intellij will survive if vscode becomes a standard for pretty much every language. Which makes me wonder if kotlin will also survive if intellij goes bankrupt.

I have used the full-blown Visual Studio.NET for over 15 years now, and JetBrains has got my $150 for the latest ReSharper update every one of those years.

VS Code is still years of dev work behind the baseline VS.NET, and likely will remain that way indefinitely (so that people like me can continue paying for the Real Thing). JetBrains will be happy to fill in the gap to bring one up to speed with the other.

They'll do just fine.

Re: Python in Visual Studio Code

#60
post #13
post #4

I am somewhat embarrassed, but also relieved to admit that I switched from vim (nvim to be precise) to VSCode (OMG M$FT!) and am very happy about it. I still use vim bindings as much as I can, but I guess giving up a bit of ideology can benefit one a lot. Although, that is until I start running out of memory on my personal laptop, then it's back to the terminal!

> can benefit one a lot. What are those benefits? I tried to switch from vim to VSCode, and it just felt like it confined me. To be fair, I don't "run vim", per say, I run a shell with tmux inside, split horizontally in two, with vim on top, and two shells (a vertical split) underneath. The left shell on the bottom being used for miscellaneous things, and the right one running some kind of live code checking (with vi…

> it felt like it wanted me to do things "its way", instead of letting me decide what I have found out works through years of experimentation.

Arguably that's not "your way" either but "vim's way", which you've adopted over those years of experimentation by force. Only now that there are alternative options which are equally as powerful is it apparent that there are other ways of doing those things.

Post reply on HN