Pro-tip: put things like this in your ~/.pythonrc so that they're loaded when you start the REPL. I have a few things in mine, like configuring readline, a couple of functions to dump objects as JSON or YAML, and imports for pprint and datetime so that they're all there when I'm doing interactive stuff.
Does .pythonrc also apply to IPython? I’ve been using my .ipython configs to do this, but would prefer to move it to .pythonrc if that applies to all Python interpreters.
Just learned about this tool, also using ipython for this. Seems it is actually controlled by the `PYTHONSTARTUP` env var, which can be set to the path to your `.pythonrc`, so should work with ipython too!
I don’t have nearly so much in mine, but the motivations the same. There are certain tools I use all the time when I’m in the REPL, so I make it as comfy for myself as possible.
I love to see investment in tools like these, so thank you so much for working on it and packaging it.
Another useful tool that I don’t see cheered enough for is vars(). When integrating new api-s, you’d often find yourself at pdb(or ipdb) prompt pretty printing(pp) loaded variables and attributes calls - pp(vars(foo)) has been a great friend reducing the burden of dot walking.
One thing I have longed for, but never took the time to research though, is pagination - your debugger window is often fighting for screen real estate, so data rich API calls becomes a little jarring.
`__foo` is probably not meant for external use, but the real reason to use the leading double underscore is to invoke that name mangling and thus avoid name collisions in subclasses. Some people do still use this feature. (These days, I barely even use inheritance.)
Perhaps it could use the same colour for the `_x` as for other single-underscore names, and a fourth colour for the `__foo` part.
Pro-tip: put things like this in your ~/.pythonrc so that they're loaded when you start the REPL. I have a few things in mine, like configuring readline, a couple of functions to dump objects as JSON or YAML, and imports for pprint and datetime so that they're all there when I'm doing interactive stuff.
Does .pythonrc also apply to IPython? I’ve been using my .ipython configs to do this, but would prefer to move it to .pythonrc if that applies to all Python interpreters.
Just learned about this tool, also using ipython for this. Seems it is actually controlled by the `PYTHONSTARTUP` env var, which can be set to the path to your `.pythonrc`, so should work with ipython too!
https://www.bitecode.dev/p/happiness-is-a-good-pythonstartup
more generic
won't work for pdb though
I don’t have nearly so much in mine, but the motivations the same. There are certain tools I use all the time when I’m in the REPL, so I make it as comfy for myself as possible.
I love to see investment in tools like these, so thank you so much for working on it and packaging it.
Another useful tool that I don’t see cheered enough for is vars(). When integrating new api-s, you’d often find yourself at pdb(or ipdb) prompt pretty printing(pp) loaded variables and attributes calls - pp(vars(foo)) has been a great friend reducing the burden of dot walking.
One thing I have longed for, but never took the time to research though, is pagination - your debugger window is often fighting for screen real estate, so data rich API calls becomes a little jarring.
Is it just a coincidence that the name is https://en.wikipedia.org/wiki/CQD, the old SOS?
I found myself wanting a quick way to navigate dir() from the terminal. This is a tiny, simple python package that helps in this regard.
I think it would be a good idea to consider name-mangled attributes (https://docs.python.org/3/tutorial/classes.html#private-vari... ; https://stackoverflow.com/questions/7456807) separately:
`__foo` is probably not meant for external use, but the real reason to use the leading double underscore is to invoke that name mangling and thus avoid name collisions in subclasses. Some people do still use this feature. (These days, I barely even use inheritance.)Perhaps it could use the same colour for the `_x` as for other single-underscore names, and a fourth colour for the `__foo` part.