Note to myself: don't forget to update the example once some review will have been performed.

Not sure the Travis failure is related to my last commit.

BTW, what should be done about the problem noticed l. 1134 in ticker.py (# TODO: shouldn't we raise a warning if self.places < 0?)? Should an explicite exception be raised, or do we assume users won't call an instance of EngFormatter with a negative value for the kwarg places.

I rewrote the example about the EngFormatter in the API section (engineering_formatter.py) to demonstrate about the new option space_sep. Eventhough most of the lines have been modified, it is the same spirit and data as before (the former example is kept as left panel).

I simply moved the demo of the kwarg places from the former example (left panel) to the new one (right panel) for esthetical reasons: with places=1 in the left panel, the tick labels were a bit mixed.

Here is a example how it now looks like:

Yes, the nose stuff needs to be removed now.

I will try to update to pytest tomorrow (“later today” may be more correct).

I rebased my local copy on the current master (things did not go totally smooth). I removed the changes that I had made in test_ticker because they were conflicting with the ones made during the Pytest migration. And of course, I have issues with Pytest when I want to check if I broke anything (it is complaining about cycler, which is installed and up-to-date on my system though).

So I will wait for CI to finish running on the rebased version before re-adding my previous changes in test_ticker, converted to Pytest.

Huh, what did I do wrong with rebase to get twice my GitHub thumbnail with commits 43d812d, 9121205, a1a38c5 and 7bad242 ^^?

I wouldn't call it wrong, but I bet you have a new email set on github; the second icon is for the person who committed the change, rather than the author.

As Travis seems to be fine with the rebase (and the AppVeyor failure does not look like related), I have just (re-)included to extended test of EngFormatter that I had introduced before (If I did not forget any, it should of course include all the test cases that were tested in the previous commit). I hope I translated it well in Pytest style: we will see if CI (at least Travis) is still happy with this new version!

@dopplershift I think you may be write for the double thumbnail (I remind pushing stuff from computers with different email addresses). Well I guess that in the end, we will play with the mailmap file if it does mess with the statistics.

Well, at least both CI services agree on failing \o/… From a rapid glance at the logs, it seems that I mixed some “expected outputs” in the test revamping. I will double check and take care of it.

Why not use a half space or make the space character customizable?

Well I think it just seemed easier to me to implement this with a boolean flag when I opened this PR (I was more or less a newcomer to mpl/git/test suite & Co).

What you suggest may indeed be better from the user viewpoint. We could replace the kwarg space_sep=True(default)|False with separator=u" " (default)|any string. Because backward compatibility is something we worship, the new default would still have to be a full space (not even unbreakable :/) as it is the original behavior. However, you could remove the space separator with separator="" or even use a narrow no-break white space with separator=u'\u202f' if you prefer.

@tacaswell @QuLogic @phobson @dopplershift (summonning every people who posted in the thread ^^) Thoughts? Who this idea be better than the current one?

BTW, just sep may be a better name for a customizable separator argument. For example, I just discovered that print also has a separator argument, called sep. (Always learning…)

👍 to sep as the kwarg name and 👍 to it being configurable rather than just a boolean.

👎 to a non-ascii default, but 👍 to mentioning that in the docs.

What wrong with an non ASCII default?

@tacaswell Just to be sure, by non-ascii default, you mean that it should be sep=" " instead of sep=u" "?

I mean " " instead of '\u202f'.

You should not need the leading u anywhere. We have unicode_literals at the top of all of our files. We no longer support 3.2 so they are not forbidden anymore, but just not needed.

@WeatherGod I just rebased and dropped the last commit, which introduced the use of a regex.

@HDembinski Thank you for benchmarking :).

I do not understand what is going wrong with AppVeyor :/. I already restarted it twice and it always fails at during the same build (Python 3.5) with what look like network issues

CondaError: CondaHTTPError: HTTP 000 CONNECTION FAILED for url <https://repo.continuum.io/pkgs/free/win-64/mkl-2017.0.3-0.tar.bz2>
Elapsed: -
An HTTP error occurred when trying to retrieve this URL.
HTTP errors are often intermittent, and a simple retry will get you on your way.

But three times in a row, it is not really intermittent to me anymore ^^...

Marking it as release-critical because it is a feature that I would really appreciate to see in next release and I think it is finally in good shape (apart from the AppVeyor failure maybe). Feel free to remove the label if you disagree.

🎉

@tacaswell Thank you :).

And many thanks to all the people who got involved and reviewed this PR!