Check that list_samplers returns a list (fix #397)

[DougBurke]

Release notes

The list_samplers function now returns a list in Python 3 as well.

Notes

This is part of #397.

[DougBurke]

Hmmm, I expected the first commit - 16cb167 - to fail the python3 tests.

[DougBurke]

No idea why the first commit passed - looking at https://travis-ci.org/sherpa/sherpa/jobs/273877659#L836 we can see that it has run the new test (test_sim_unit.py) and that this is a python 3.5 installation. On master branch I find (with python 3.5)

% ipython
Python 3.5.4 |Continuum Analytics, Inc.| (default, Aug 14 2017, 13:26:58) 
Type 'copyright', 'credits' or 'license' for more information
IPython 6.1.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from sherpa.sim import MCMC

In [2]: m = MCMC()

In [3]: m.list_samplers()
Out[3]: dict_keys(['mh', 'metropolismh'])

In [4]: f = m.list_samplers()

In [5]: isinstance(f, list)
Out[5]: False

so I don't see how the test could have passed.

[DougBurke]

About to rebase. Original tip was b152b40

[DougBurke]

I have no idea why the travis builds succeeded for the first commit (the equivalent of 71ee06b before the rebase). I'm removing the pr:hold label.

[DougBurke]

@olaurino can we have this labelled for CIAO 4.10?

[olaurino]

I must have done something stupid while I was trying to debug the Travis build, because my initial guess on why Travis was green turned out to be correct but only after I thought I had proved it was not.

Anyhow. Unless you have Travis activated on your fork (which would be a good idea) the only check performed by Travis is the PR build, i.e. how well the PR plays when merged into the master branch. Past experience tells us that this is less safe than the push builds, because the push builds are executed on the individual commits, while for the PR builds Travis uses a special GitHub reference for a fake merge commit of the PR (e.g. https://travis-ci.org/sherpa/sherpa/jobs/273877659#L488), not the commit ID.

That means that if you push multiple commits in rapid succession Travis might run multiple builds on the same commit (well, I think Travis now cancels builds if they are overridden by other commits in the same branch, so that's also different, and it might be what tripped me this time). So, my educated guess is that all the Travis builds were run on merge commits that already had the fix in them.

I can't fully test that the above is actually what happened here, but what I could do was to push the first commit in this PR to my fork and check that it failed in Travis. It did, exactly as expected.