In this specific case, I'd just deprecate TextWithDash in favor of Annotation (possibly after checking that the latter indeed replaces (reasonable...) use cases of the former).

Even the scaled back version with a single update does yield different plots with python 3.5 on travis. There's something fishy going on if three sequential updates have a different effect compared to one combined update.

Marking as WIP because this needs further investigation.

Ah, dict iteration order is random in 3.5.

This fix may have to wait until we drop 3.5 (which I suspect will be for the next release, but someone needs to turn the crank on making that decision).

Thanks, that's it.

Looking forward to drop 3.5, then we can also use f-strings 😄.

Rebased. Should hopefully work now that were're on Python 3.6+.

Can be squashed.

want to squash?

Squashed.

So this is still not going to do the full constructor change even on 3.6+?

@QuLogic Whst do you mean by „full constructor change“?

This is a basic simplification to just do a single update instead of updating multiple times.

I mean the original description:

This PR changes the code to create effective kwargs and directly pass them to the Text() constructor.

Oh, that 😄 (too long ago to remember). Because of

Turns out, making TextWithDash fully API compatible with Text is a bit more cumbersome. Just passing the kwargs on is not enough. There is an issue with the call sequence TextWithDashes.init -> Text.init -> TextWithDashes.set_transform. I.e. the super init calling a child function before all the attributes of the child are set up.

I've restricted myself to

Option 1: Still delay the kwargs update (but just do one update instead of three).

The call sequence issue is not solved with python 3.6+. Also @anntzer proposed to deprecate TextWithDash. This whole topic would need more effort than I'm currently willing to spend on.

TL;DR

No, this won't do the full constructor change.

PR title and original description updated.