Fixes for traitlets 4.1 deprecation warnings

[jcb91]

since 4.1, traitlets complains (issues DeprecationWarnings) about using TraitType classes to set the allowed trait types for container traits like Set and List. This PR switches to using instances, to avoid the warnings in the RegexRemovePreprocessor and ClearOutputPreprocessor classes.

[mpacer]

I don't actually see that documented anywhere and when I run these tests, I don't get those warnings…

Importantly, I fear that because it's not receiving a traittype anymore that it's not going to restrict the contents of the containers.

Could you actually paste the deprecation warnings you're running into?

[minrk]

@mpacer this has been the right way to do it for some time, but there's some traitlets magic where if it sees a TraitType instead of TraitType instance, it will instantiate it automatically in the constructor. The implicit, automatic instantiation is what's deprecated. Behavior is unchanged.

To see the warning:

from traitlets import HasTraits, Unicode, List

class Klass(HasTraits):
    trait = List(Unicode)

c = Klass()

run with PYTHONWARNINGS=d gives:

$> PYTHONWARNINGS=d python tst.py
tst.py:4: DeprecationWarning: Traits should be given as instances, not types (for example, `Int()`, not `Int`). Passing types is deprecated in traitlets 4.1.
  trait = List(Unicode)

[jcb91]

@minrk exactly, thanks for the clarification, apologies @mpacer, I should have given a better explanation. See traitlets/traitlets.py#L2443-L2448 for where the warnings originate from. I encountered them in nbconvert in the course of writing a warning checker for our nbextensions' nbconvert_support stuff ipython-contrib/jupyter_contrib_nbextensions#1137. I was a little surprised that I hadn't seen them before, but I guess it makes sense that the model is more opt-in-to-see than warn-everybody-all-the-time.

[mpacer]

Whats bizarre is pytest --PYTHONWARNINGS=all did not surface this. I didn't realise "all" didn't include deprecation warnings…