3 ms·

>With A REPL first I need to do a load of import statements. Then populate my objects. Then get started with the actual debugging. No, you absolutely do not. Y

>With A REPL first I need to do a load of import statements. Then populate my objects. Then get started with the actual debugging. No, you absolutely do not. You just need to click around until your code hits the point in the code (or, ideally, run an integration test that gets you to that point) where you want the ability to run methods, inspect objects, etc. Just make sure you've shoved an import IPython ; IPython.embed() in there and you're good to go. No additional imports necessary. I agree that having your environment set up with production data (or as close an approximation as you can get) is a good idea, but I'd rather script that with a test framework where it can be used for regression testing rather than bodge it together using an IDE.

collyw 9y ago
"You just need to click around until your code hits the point in the code (or, ideally, run an integration test that gets you to that point) where you want the ability to run methods, inspect objects, etc." This is generally a lot less effort than populating objects in the REPL to reproduce the same set of conditions.
- crdoconnor 9y ago
  That's basically an admission that you're not writing enough realistic tests or your dev environment is set up wrong. For me, it's way way easier the other way around.
  - collyw 9y ago
    Ahh the classic "you're doing it wrong" reply with no advice on why it is wrong.
    - crdoconnor 9y ago
      Do you need advice on why creating a code base not surrounded by realistic & reliable tests is a suboptimal approach? Or did you think that once they're there it would still be a lot of effort to use them to populate objects?
      - collyw 9y ago
        Doesn't mean that its going to catch the bugs that are present. An IDE when properly setup is closer to a production system than a load of unit tests and as such will be able to fix far more bugs in my opinion. But you are welcome to do what works for you. Maybe you work on something more suited to your approach. My approach works better for what I do.
        crdoconnor 9y ago
        I write integration tests, as I mentioned in the first post and realistic ones as mentioned in the second. I try not to write unit tests because, as you mentioned, they are unrealistic (among other reasons), and unrealistic tests tend not to catch bugs. That said, a high level 'unit test' (e.g. one that manufactures a request and checks its response) is often realistic enough and works pretty well with IPython.embed().

collyw 9y ago

"You just need to click around until your code hits the point in the code (or, ideally, run an integration test that gets you to that point) where you want the ability to run methods, inspect objects, etc." This is generally a lot less effort than populating objects in the REPL to reproduce the same set of conditions.

crdoconnor 9y ago
That's basically an admission that you're not writing enough realistic tests or your dev environment is set up wrong. For me, it's way way easier the other way around.
- collyw 9y ago
  Ahh the classic "you're doing it wrong" reply with no advice on why it is wrong.
  - crdoconnor 9y ago
    Do you need advice on why creating a code base not surrounded by realistic & reliable tests is a suboptimal approach? Or did you think that once they're there it would still be a lot of effort to use them to populate objects?
    - collyw 9y ago
      Doesn't mean that its going to catch the bugs that are present. An IDE when properly setup is closer to a production system than a load of unit tests and as such will be able to fix far more bugs in my opinion. But you are welcome to do what works for you. Maybe you work on something more suited to your approach. My approach works better for what I do.
      - crdoconnor 9y ago
        I write integration tests, as I mentioned in the first post and realistic ones as mentioned in the second. I try not to write unit tests because, as you mentioned, they are unrealistic (among other reasons), and unrealistic tests tend not to catch bugs. That said, a high level 'unit test' (e.g. one that manufactures a request and checks its response) is often realistic enough and works pretty well with IPython.embed().