So, uh, can anybody suggest a #Python editor for someone who happily just does R and rust and c++ within helix? I'm tempted to continue my ludism but I'm willing to try fancier...? Is running a jupyter server going too far?
Sep 1, 2026, 5:25 PM@wronglang I do most of my coding with just a plain text editor (well, fancy enough to offer syntax highlighting but that's as much as I need) and the command line, so sticking with the basics is a perfectly legitimate choice if it works for you.
That bring said, running a Jupyter server on your own computer is a perfectly reasonable and common thing to do. I don't think I'd use it as an IDE, personally; I find that Jupyter is great at the "exploratory computation" workflow but the experience of just editing source files is not quite as good as my trusty text editor. But you can give it a shot.
I have also used PyCharm in the past and it wasn't bad, although I never found it to give *that* much of a benefit over the plain text editor. Some of the fancy IDE features were handy but never essential.
@diazona thanks for the summary, it's really helpful!
@wronglang Agree with other responses that complex IDEs are nice, but usually overkill. A text editor you enjoy with syntax highlighting is a great place to start, then you can develop a feeling for what specific features you might use on your workflows & projects.
PyCharm, VSCode are common choices. They have more buttons than you need. 🤷
(I use Vim which I can't recommend unless you are enthralled by it, but I climbed the steep learning curve while young and have never looked back.)
@wronglang One part of this is that Python's dynamism undermines the usefulness of many of the compile time checks you are used to. To really feel at ease with Python is to lean into the benefits of judicious dynamic typing (it can bring conciseness, simplicity, clarity), very actively let go of expecting the type system & compile time checks to catch everything, and read up on the ways Python can make testing easier.
@wronglang I have no exposure to academic / numerical computing, having only worked in commercial / industrial domains, and have never run Jupyter, nor ever seen a peer running it at work.
@wronglang like, as an illustrative example that would have horrified me in my C++ days: currently working on a 15 million line codebase, and consider type annotations an occasional "nice to have", 50% for the purpose of documenting intent to future human readers.
@tartley I would take rust or c++ over that any day but instead most of the code I write is in R out of necessity for collaboration so.. I can't judge.... 🫣
@wronglang well, I used to be a straight static typing zealot, so I hear you, but on the other hand, I began wading through so much evidence to the contrary that eventually I snapped and flipped like only a true believer can.
@wronglang By way of one example: I ran developer interview questions as a side-role for a few orgs now, and keep detailed stats. On questions designed to be language agnostic (which tend to be pretty unfriendly to Python tech and culture, eg. consisting of complex byte twiddling exercises.), when candidates are allowed to choose their own programming language...
@wronglang The candidates who chose Python average 2.6 times the successful progress through the problem in the allotted time than the next best scoring language, Go.
This goes back to what I said about making code simpler and more expressive. They literally make the problem simpler by building abstractions that required them to write less code. Python lends itself to that, and if one is going to take a stand about theoretical correctness, one had to at least understand data points like this.
@wronglang Because those rapid Python solutions were correct. We built extremely robust test suites to run against candidate solutions, precisely to uncover subtle bugs not evident from experienced inspection. So if that can be true under some circumstances, how much is the type safety really buying you? Figuring out the boundaries and nuance there, on both sides, is huge.
@tartley you do have the issue of measuring two correlated things: Pr[success], Pr[choose python] whereas what you want to measure is Pr[success|chose Python] ... but that said I wouldn't have a problem with choosing it over something more strongly typed for any project I've been involved in. In academic code usually the problem is being able to get a team to work coherently at all so you gotta be flexible on technical details.
@wronglang Right, that is true, with the probabilities, but given constrained time and resource, which is always the case, we are lumping the 'not finished yet' solutions in as pragmatically equivalent to the 'not demonstrated bug free' solutions, in which case the numbers I quote above is the final measurement we actually want.
But yeah, it's not a ubiquitous slam dunk. There are times when taking extra time to gain extra correctness confirmations is worth it.
@wronglang oh and, forgot to say explicitly, choosing the right tool is one of the skills we desire to hire. Where "right" means "whatever tool solves the following problems more correctly, maintainably, and implemented faster than the next guy"
@tartley that makes sense, I did a bunch with Python years ago and the rampant shallow copies in the context of lists/dictionaries annoyed me so much that I mostly stuck with other languages since. There's a few folks I used to work with on Stan that have interesting stuff lately that happens to be in Python/JAX so I'm going to have to give it another chance 😅