Samuel Colvin writes:
Python definitely needs a dedicated debug print command.
For *commands* (ie, a REPL), you have Pdb already. It's unlikely a *statement* would be accepted, given that print was demoted from a statement to a function. And it's not obvious why a "debug.print()" function can't just as well be imported from a 3rd party library you get from PyPI. (There's already pdb.Pdb.prettyprint in the stdlib, though it may not be terribly easy to use outside of the Pdb REPL.)
(I'm not trying to promote devtools, just demonstrate what is possible.)
It seems to me that promoting devtools (unless you know a solution that's better for some reason) is exactly what you should do. Not that you should pretend it's already optimal. But it would be a concrete proposal that would serve to focus suggestions, and evaluate whether there is a single module that is sufficiently useful to enough people to deserve inclusion in the stdlib, or whether this is yet another case where a number of modules with varied feature sets available from PyPI is a better solution.
It would be difficult to fully integrate a package like this into the standard lib since it relies on pygments for colouring output, but not impossible.
I don't see why that's a problem, as long as the coloring feature is optional:
have_color = None try: import pygments have_color = 'pygments' except ImportError: pass # or try other color libraries here
and you don't even try to colorize if have_color is None. See the thread on xz and other optional external libraries that don't exist on some platforms and don't give nice errors when the import fails for the wrapper Python library.
A bigger problem is if devtools does stuff on which there is no consensus that it's wanted in the stdlib. That "stuff" would need to be split out, which would possibly be a pain for you and any other existing users.