unicode support for string type checks, fixes #929

[belevtsoff]

str comparisons cause exceptions with unrelated error messages when using e.g. unicode port names (see #929 for concrete example).

I just ran for f in grep -rle "isinstance([^)]*str)" .; do sed -i.old "s/isinstance(\([^)]*\)str)/isinstance(\1basestring)/g" $f; done in the nipype directory. Let's see what Travis says...

[mwaskom]

It might make sense to be proactive about the eventual movement to Python 3 and use six.string_types here.

[coveralls]

Coverage remained the same when pulling 55b7d33 on belevtsoff:master into 7afedad on nipy:master.

[belevtsoff]

@mwaskom but that would introduce another dependency... isn't it something automatic code converters can handle easily?

[satra]

+1 for @mwaskom suggestion.

@belevstoff - six can be included as a single file in nipype.externals.

[mwaskom]

Generally projects package six internally (I think it's a single file exactly for this reason). But the other devs should weigh in before we make that decision.

[mwaskom]

isn't it something automatic code converters can handle easily?

The idea is that you use six so that you can have a single codebase that runs on Python 2 and Python 3. This is becoming the preferred way to handle supporting Python 3 over using an automatic converter than runs at package time.

[belevtsoff]

alright, so let's see if there are no objections and then I'll add those commits

[belevtsoff]

not sure why build failed, looks like an unrelated error

[satra]

retrying on travis.

[belevtsoff]

Ok, the new problem seems to be caused by a66018a

[satra]

fixed upstream - if you merge and push this should now go through.

[coveralls]

Changes Unknown when pulling 9c2a9b0 on belevtsoff:master into * on nipy:master*.

[belevtsoff]

uugh, this server connection...