Pretty-print numpy scalars.

[anntzer]

If the "numpy" extra is not installed, never add the "numpy.foo()" constructor; if it is installed, always add it.

Closes #36. The implementation is a bit of a mess :/

[tommikaikkonen]

Thanks for submitting this! I did a bit of cleanup:

• I think we can forgo handling the case where the numpy extra was not installed, and float64 renders differently from the other numpy floats. If a user wants specific output, they can enable the extra or define their own pretty printers. Related to that, I modified the test to just test that they render correctly when the extra is enabled.
• I noticed that bool and NoneType (printed by pretty_singletons) were not being wrapped in a subclass call if the value passed is a subclass. We do this wrapping for all the other native types, so I added the same thing to those types' pretty printers for consistency.

I think this is good to merge to master as it is right now.

Btw, I noticed the prettyprinter.prettyprinter evaluating to the module itself at some point when using the library in a shell, but it seems that if you do a proper import, it'll work. I'm not sure what the issue there is. Was something not specifically working because of that?

[anntzer]

I agree the PR as I made it was quite hackish so your cleanup looks good.

I noticed that bool and NoneType (printed by pretty_singletons) were not being wrapped in a subclass call if the value passed is a subclass. We do this wrapping for all the other native types, so I added the same thing to those types' pretty printers for consistency.

Actually NoneType can't be subclassed

In [5]: class T(type(None)): pass                                                                                   
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-5-3b0b4d13fdb2> in <module>
----> 1 class T(type(None)): pass

TypeError: type 'NoneType' is not an acceptable base type

Btw, I noticed the prettyprinter.prettyprinter evaluating to the module itself at some point when using the library in a shell, but it seems that if you do a proper import, it'll work. I'm not sure what the issue there is. Was something not specifically working because of that?

The prettyprinter._NUMPY_EXTRA_INSTALLED hack was not working (not that it's needed anymore) because of that (because I wanted to stash the flag in the prettyprinter.prettyprinter module, but in prettyprinter.extras.numpy, doing from prettyprinter import prettyprinter would return the toplevel prettyprinter module, not the prettyprinter.prettyprinter module.

In general I find it a bit confusing to have a toplevel package and a submodule with the same name; I would have made the submodule prettyprinter._implementation or something like that but it's up to you.

[tommikaikkonen]

Interesting, didn't know NoneType is not subclassable, I guess I never tried it :) Merging this in.

Fair point about the weird submodule name. Changing the submodule name could break people's imports (if they imported something from there), so to change it, there should be some sort of deprecation process first. I'll keep this in mind and see if it becomes more of a nuisance.

[tommikaikkonen]

Released in 0.16.0.