I would not overload the signature. A typical strategy would be to have the canoncial signature and create a factory classmethod for the other signature:

def __init__(colorizer):    self.colorizer = colorizer@classmethoddef from_norm_and_cmap(cls, norm, cmap):    return cls(Colorizer(norm, cmap)

AFAICT, the situation here is a bit different, because users do not instantiateColorizingArtist directly, and hence, they won't use the factory method. We could do one of the two options:

• only implementdef __init__(colorizer). If subclasses need to initialize from norm + cmap, they'd simply do

  ColorizingArtist.__init__(Colorizer(norm, cmap))

• create an alternative initializer

  def _init_from_norm_and_cmap(norm, cmap):    self.colorizer = Colorizer(norm, cmap)

Given that we'll only have a handfull of subclasses and the solution is quite simple, I'm leaning towards the first option.

The first alternative makes sense to me.

However, we still need the logic where the user can pass aColorizer object as part of the input to the plotting function.

I implemented this with the following function:

def_get_colorizer(cmap,norm):"""    Passes or creates a Colorizer object.    Allows users to pass a Colorizer as the norm keyword    where a artist.ColorizingArtist is used as the artist.    If a Colorizer object is not passed, a Colorizer is created.    """ifisinstance(norm,Colorizer):ifcmap:raiseValueError("Providing a `cm.Colorizer` as the norm while ""at the same time providing a `cmap` is not supported.")returnnormreturnColorizer(cmap,norm)

Such that the initiation of aColorizingArtist in e.g.Collection is:

artist.ColorizingArtist.__init__(self,colorizer._get_colorizer(cmap,norm))

Do we really want to pass aColorizer via thenorm parameter in public API? This feels very hacky. I'm inclined to add acolorizer parameter instead, even if that means we have mutually exclusive parameters. (Note that even with the hack, we'd have to live with partially mutually exclusive parameters, because you cannot passnorm=mycolorizer, cmap='jet').

I have no strong opinions, and am inclined to agree with you@timhoffm.
Since this is a change to the call signature of the plotting functions, we should bring it up at a weekly meeting.@story645 could you add it on the agenda for the next meeting?

(My aversion to new keyword arguments is a result of a discussion at a weekly meeting a long time ago about multivariate color mapping, and how we do not wantthat to increase the number of keyword arguments, but this is a different case entirely.)

Sorry I didn't see this til now 😦 but also anyone can add stuff to the agenda (sorry me and Kyle didn't make that clear)! And also this got resolved as yes add new kwarg, I think.

are we sure that this will always have a.norm?

I'm thinking it will always have a norm, as I think that simplifies the implementation.
However, that norm might beNoNorm.

The implementation here mirrors that ofScalarMappable, which always has aNormalize andColormap object, and I think this is sensible. For images that are already RGB(A) a norm (and cmap) is technically unnecessary, but I believe the overhead of creating them is negligible.