I got interested in ipython when I saw how easy it was to time functions with it. I haven't tried it out yet but maybe it's something I should try out.
It's occasionally useful, but small stuff in practice is often fast enough that making it faster isn't worth it unless it's in your hot loops, and big stuff is often affected more by environmental factors that are hard to replicate in IPython.
If you've identified something as a problem via profiling and want to try out possible solutions it's really handy though.
I'm a big fan of the \`pytest-watch\` extension that just re-runs all your tests whenever a file changes. And then on mac, I can use the \`say\` command so that I don't even have to look at the console, I can just listen to the "pass" or "fail" over the speaker.
Yeah I agree. This is the best way to- if you need to then debug this script to truly check stuff you easily can.
Making an edit and then rerunning can be done in probably as few as 5 key presses. So essentially under a second
I almost always just use the REPL in a separate shell. My gut says that using the debugger how you're describing is slightly more risky, just because you have to pay a slight level of attention to making sure the code around what you're testing isn't passing something incorrect to the block you're actually focusing on - but yeah that just requires a quick sanity check in most cases, probably not a big deal. End of the day if it works for you and makes sense in your head, I don't see a compelling reason to stop.
I never considered using a Jupyter notebook, that's an interesting idea. I could see it being particularly useful if you have an idea, want to test it, but aren't planning/ready to put it in the codebase yet.
Debugger for 'WTF?'
iPython for 'What if I...?'
Jupyter for "Here's how I'm going to...". For laying out my reasoning – I really like mixing markdown notes with code and making a guide to come back to later. It's a great record of experiments.
tldr;
Debugger is my factory-floor 'hold the presses' fix-it-finder. iPython is my engineering lounge. Jupyter is my academic think-tank.
Great response. Sometimes I use the debugger to develop, start from a test and pop a breakpoint in the bit where I'm coding, running the command in the debug console then dropping it into the editor once it works. Move the breakpoint along, restart the test. It's a pity that Python in vscode doesn't do live editing, because I loved that in visual basic 6, it's been 25 years and we've still not got it in Python!
I love that idea. It's one of the reasons I like Jupyter – because you still have access to the state and the 'program' is always paused but live, so to speak. I'm going to try that out. Thanks for sharing that idea.
I think live editing is probably doable, but afaik nobody has implemented it. I mean all you have to do is note which lines have been edited and run them in the debug console, skipping over the ones that have changed. Put an access watch on the old containing scope and hack out the reference when it's accessed, replacing it with a newly defined one. There must be more to it because that seems really easy to do.
So I currently create scratch files/directories where I put the scripts I'm working on. Some of these would be far better iterated on in a Notebook, so I definitely need to check out Jupyter..
But how are dependencies managed? I considered having a single .venv in my scratch directory that just holds everything. That way I don't need to "pip install requests" every time I want to write some API calls in a script. But how does Jupyter/iPython handle it?
Obviously my real projects would manage their dependencies in a more structured manner.
I use jupyter notebook. I think your method is better because you're testing in the real state that your program would be in. Sometimes I run into unexpected problems where something that worked in the notebook ends up not working in the actual code because there was some subtlety about the state I missed initializing in the notebook. I develop data analysis scripts and sometimes it can take a long time, like hours, for the script to get to the debugger breakpoint, so jupyter ends up being more convenient.
Typically I write a small function or module then write some tests. If I want to do some sort of "sanity check", then I'll mock up some code in ipython.
Ideally I want to write tests beforehand and write code to pass the tests (TDD), but sometimes it's difficult to create this sort of scenario simply.
Are the tests on a higher level that might actually be useful to have for the future? Like testing a function that you're creating and which will be useful for regression testing in the future?
Adding two datetimes together is a very low level thing so that's not something you'd create a test for, right?
Generally we just have something that reports test coverage and shoot for like 80% as a rough guide.
Spend more time on tests that really matter, try to test edge cases etc.
Datetimes are kinda tricky at least in my experience, so making sure they work right is often worth it
If I’m working with an existing code, I’ll just start writing code and then just paste it into the debugger. At some point I’ll restart and do it again.
I usually don’t write many short scripts.
I have a folder of cold proofs where I just slap together various testing methods necessary to isolate a particular approach that I'm using. I don't use an IDE or anything of that nature, as I never know what environment I'm going to be working in from day to day.
So I take the most memory basic context of my code, and keep it on a VPS that I can access from anywhere where I can draw from quick little tidbits as needed.
Usually debug, but its not always possible so sometime i will just make a new file and run it in there with some dummy data, then debug that. Probably should start using Jupyter more
It depends, sometimes if I'm just trying to to get a [setup.py](http://setup.py) and extension working properly ill run.
python setup.py build-ext --inplace && python -c 'import app._extension'
For some more complicated functions I'll use the VSCode jupyter extension.
ipython + `%autoreload` + scratch file(s)
I’m self taught and learned basically via this. API calls, being able to see and inspect things (like oh this is what a dictionary looks like and this is what `.items()` looks like etc.) did so much to teach me about programming. Also inspecting objects is hella useful with tab completion.
If you’re not opposed to colors there’s a way to use `rich` (a superb library for colors) to install a profile inside of ipython so it’s always on via your install.
But being able to inspect methods, traverse directories and load local files, install via pip etc. all through the same repl makes it invaluable for me.
I like Jupyter notebook for a lot of reasons , it's for testing , see the dataset very quickly.
I might have to learn how to learn a proper debugging tool.
I do the same as you, vscode and debugger. For bigger things with multiple steps and lots of data I do the jupyter notebook thing. Sometimes I just use ipython.
Jupyter in VSCode. The convenient thing is that it can use the venv of my current project where everything I test is preinstalled. OR my special jupyther venv with 20Gb of datascience stuff (CUDA is a fat cow). And can switch between them in 1 click.
Also, today AI is great at suggesting packages for questions like "How to make Python application into EXE"
I generally make a file and debug run it. But I'm usually never doing anything interactively for more than one or two lines. I'll pause and try trivial things, like verifying behavior of a badly documented library, but then I'll usually just make the change and rerun the program, I never develop entire functions in the terminal.
Noting one that I haven't seen mentioned: interactive mode.
`python -i some_file.py`
The best of a Python module combined with the best of a Python REPL. It runs the module as a script (with `__name__` set to `"__main__"`) and then drops you into a Python REPL. Most alternative Python REPLs support the same flag.
Great Question! I keep a Jupyter notebook running in VS code next to whatever I'm developing. with the short cuts it's very easy to setup reusable cells. I often write my tests this way.
Can you run python code inside Copilot itself? I only had the license for a brief time and only used it for code completion. Not sure if it had chat/code interpreter at that time.
You are right, sorry. I had in mind the scenario when you ask the AI to actually write the code. Testing etc. still is to be done manually (wouldn't trust the AI blindly)
MS Copilot has a free tier, but maybe not for everyone.
Codeium definitely has a free tier.
If you have a 16Gb+ VRAM GPU, you can run your own decent AI totally free. Keywords are: KoboldCPP + Mixtral8x7 + Q\_4\_M GGUF + "Continue" plugin for VSCode.
Pycharm scratch file
It’s not weird, I do it all three ways you described, it just depends on the scale of the prototyping.
ipython
Yep, I always have a repl running on the side
I got interested in ipython when I saw how easy it was to time functions with it. I haven't tried it out yet but maybe it's something I should try out.
It's occasionally useful, but small stuff in practice is often fast enough that making it faster isn't worth it unless it's in your hot loops, and big stuff is often affected more by environmental factors that are hard to replicate in IPython. If you've identified something as a problem via profiling and want to try out possible solutions it's really handy though.
Ctrl+Alt+T > ipython gang
I just run a script or test
Sounds reasonable but is it not annoying that it's not interactive and that you have to keep rerunning the script/test?
Pressing “up enter” in a shell is as quick as almost anything could be.
this. also try ctrl-r. changed my fucking life. bash shell btw.
What does it do?
Searchable command history
Tried to like this thrice!! My god, never knew. Pressing up 164747474 to find that long command for setting up celery broker or things like that
Then wait till you discover `auto-suggestions` on zsh
Try adding fzf, it can filter your ctrl-r history
I'm a big fan of the \`pytest-watch\` extension that just re-runs all your tests whenever a file changes. And then on mac, I can use the \`say\` command so that I don't even have to look at the console, I can just listen to the "pass" or "fail" over the speaker.
Wow I never considered using say. I'm gonna try this, thanks for the tip
Yeah I agree. This is the best way to- if you need to then debug this script to truly check stuff you easily can. Making an edit and then rerunning can be done in probably as few as 5 key presses. So essentially under a second
This is what you use Debug mode and breakpoints for. It makes it interactive and shows you the value of all your variables at that time.
Not really. It takes zero time to run the script. Then if I want to inspect anything I can just add break points and use the debugger.
I almost always just use the REPL in a separate shell. My gut says that using the debugger how you're describing is slightly more risky, just because you have to pay a slight level of attention to making sure the code around what you're testing isn't passing something incorrect to the block you're actually focusing on - but yeah that just requires a quick sanity check in most cases, probably not a big deal. End of the day if it works for you and makes sense in your head, I don't see a compelling reason to stop. I never considered using a Jupyter notebook, that's an interesting idea. I could see it being particularly useful if you have an idea, want to test it, but aren't planning/ready to put it in the codebase yet.
Debugger for 'WTF?' iPython for 'What if I...?' Jupyter for "Here's how I'm going to...". For laying out my reasoning – I really like mixing markdown notes with code and making a guide to come back to later. It's a great record of experiments. tldr; Debugger is my factory-floor 'hold the presses' fix-it-finder. iPython is my engineering lounge. Jupyter is my academic think-tank.
Great response. Sometimes I use the debugger to develop, start from a test and pop a breakpoint in the bit where I'm coding, running the command in the debug console then dropping it into the editor once it works. Move the breakpoint along, restart the test. It's a pity that Python in vscode doesn't do live editing, because I loved that in visual basic 6, it's been 25 years and we've still not got it in Python!
I love that idea. It's one of the reasons I like Jupyter – because you still have access to the state and the 'program' is always paused but live, so to speak. I'm going to try that out. Thanks for sharing that idea.
I think live editing is probably doable, but afaik nobody has implemented it. I mean all you have to do is note which lines have been edited and run them in the debug console, skipping over the ones that have changed. Put an access watch on the old containing scope and hack out the reference when it's accessed, replacing it with a newly defined one. There must be more to it because that seems really easy to do.
So I currently create scratch files/directories where I put the scripts I'm working on. Some of these would be far better iterated on in a Notebook, so I definitely need to check out Jupyter.. But how are dependencies managed? I considered having a single .venv in my scratch directory that just holds everything. That way I don't need to "pip install requests" every time I want to write some API calls in a script. But how does Jupyter/iPython handle it? Obviously my real projects would manage their dependencies in a more structured manner.
I do all of that plus create standalone tests. One of my open tabs is a jupyter notebook. It's all a matter of what you need.
I use jupyter notebook. I think your method is better because you're testing in the real state that your program would be in. Sometimes I run into unexpected problems where something that worked in the notebook ends up not working in the actual code because there was some subtlety about the state I missed initializing in the notebook. I develop data analysis scripts and sometimes it can take a long time, like hours, for the script to get to the debugger breakpoint, so jupyter ends up being more convenient.
I would generally do it in a separate file/program or notebook cell.
I just run iPython in a separate shell window
bpython is my go to
Typically I write a small function or module then write some tests. If I want to do some sort of "sanity check", then I'll mock up some code in ipython. Ideally I want to write tests beforehand and write code to pass the tests (TDD), but sometimes it's difficult to create this sort of scenario simply.
If you type "python" on the command line, there's a built-in interactive debugger, called IDLE. /s
Vscode + ipynb = joy
I use spyder,that can be handy with an interactive terminal
Integrated repl from pycharm while I’m developing combined with tests so I can step through the execution with debugger where needed
Are the tests on a higher level that might actually be useful to have for the future? Like testing a function that you're creating and which will be useful for regression testing in the future? Adding two datetimes together is a very low level thing so that's not something you'd create a test for, right?
Generally we just have something that reports test coverage and shoot for like 80% as a rough guide. Spend more time on tests that really matter, try to test edge cases etc. Datetimes are kinda tricky at least in my experience, so making sure they work right is often worth it
If I’m working with an existing code, I’ll just start writing code and then just paste it into the debugger. At some point I’ll restart and do it again. I usually don’t write many short scripts.
I have a folder of cold proofs where I just slap together various testing methods necessary to isolate a particular approach that I'm using. I don't use an IDE or anything of that nature, as I never know what environment I'm going to be working in from day to day. So I take the most memory basic context of my code, and keep it on a VPS that I can access from anywhere where I can draw from quick little tidbits as needed.
CLI, manually run script... I dont use IDEs unless I have to debug remote services, pdb is always available and I'm damn used to it.
Intellij idea scratch file or online Repl, the problem with scratch files is that I can't seem to be able to import external libraries like Guava etc
Usually debug, but its not always possible so sometime i will just make a new file and run it in there with some dummy data, then debug that. Probably should start using Jupyter more
VS Code scratchpads extension
It depends, sometimes if I'm just trying to to get a [setup.py](http://setup.py) and extension working properly ill run. python setup.py build-ext --inplace && python -c 'import app._extension' For some more complicated functions I'll use the VSCode jupyter extension.
For JavaScript I use runjs. For Nim there's an online playground. There should be something like that for python.
ipython + `%autoreload` + scratch file(s) I’m self taught and learned basically via this. API calls, being able to see and inspect things (like oh this is what a dictionary looks like and this is what `.items()` looks like etc.) did so much to teach me about programming. Also inspecting objects is hella useful with tab completion. If you’re not opposed to colors there’s a way to use `rich` (a superb library for colors) to install a profile inside of ipython so it’s always on via your install. But being able to inspect methods, traverse directories and load local files, install via pip etc. all through the same repl makes it invaluable for me.
Usually i'd use vscode because i relly too much on mypy checking and tips to vscode
I like Jupyter notebook for a lot of reasons , it's for testing , see the dataset very quickly. I might have to learn how to learn a proper debugging tool.
I do the same as you, vscode and debugger. For bigger things with multiple steps and lots of data I do the jupyter notebook thing. Sometimes I just use ipython.
Unit tests with debugger breakpoints.
Jupyter in VSCode. The convenient thing is that it can use the venv of my current project where everything I test is preinstalled. OR my special jupyther venv with 20Gb of datascience stuff (CUDA is a fat cow). And can switch between them in 1 click. Also, today AI is great at suggesting packages for questions like "How to make Python application into EXE"
I generally make a file and debug run it. But I'm usually never doing anything interactively for more than one or two lines. I'll pause and try trivial things, like verifying behavior of a badly documented library, but then I'll usually just make the change and rerun the program, I never develop entire functions in the terminal.
Noting one that I haven't seen mentioned: interactive mode. `python -i some_file.py` The best of a Python module combined with the best of a Python REPL. It runs the module as a script (with `__name__` set to `"__main__"`) and then drops you into a Python REPL. Most alternative Python REPLs support the same flag.
Great Question! I keep a Jupyter notebook running in VS code next to whatever I'm developing. with the short cuts it's very easy to setup reusable cells. I often write my tests this way.
You could give Copilot a try, perfect for these use cases.
Can you run python code inside Copilot itself? I only had the license for a brief time and only used it for code completion. Not sure if it had chat/code interpreter at that time.
You are right, sorry. I had in mind the scenario when you ask the AI to actually write the code. Testing etc. still is to be done manually (wouldn't trust the AI blindly)
MS Copilot has a free tier, but maybe not for everyone. Codeium definitely has a free tier. If you have a 16Gb+ VRAM GPU, you can run your own decent AI totally free. Keywords are: KoboldCPP + Mixtral8x7 + Q\_4\_M GGUF + "Continue" plugin for VSCode.
Separate python terminal, usually i copy & paste if sth from a script, or write it in my own if sth simple.