FIX str.match uses na flag

[hayd]

fixes #6609

[hayd]

travis failing is a refused connection with fred, unrelated to this pr (you'd think)

https://travis-ci.org/pydata/pandas/jobs/20585139

[jreback]

hmm are the Fred calls wrapped with network. decorator?
that should catch and skip those tests

[jreback]

actually these network errors are 'ok'. because in theory if the URL had changed that's what we'd get

so if it keeps repeating....can investigate further

[jorisvandenbossche]

I was wondering, should it be noted in the docstring that by default it gives NaN for non-strings? (because you could also assume this gives False)

[hayd]

@jorisvandenbossche this fix makes it inline with the current behaviour of contains (et al?), I guess we could change the docstring too (not sure which others this is used in).

...tbh I had assumed that it was equivalent to s.astype(str).str.contains(...) but they aren't (i.e. you can't search for digits of a number).

[hayd]

(re fred, this branch passed on hayd/travis, so it's something intermittent)

[hayd]

@jorisvandenbossche I kind of think I should merge this in first, then have sep issue for the docstring. Maybe adding it to docs example of vectorised string methods would be enough...

Oh goodness, when I implemented get_dummies I used .astype(str) to get around this problem, I had assumed this was how they all worked... I suspect that's going to raise sometimes? :s

[jorisvandenbossche]

Yeah, but I would certainly add something to the docs, since you also expected non-strings to be converted to strings instead of giving NaN.

[jorisvandenbossche]

For further discussion see also #6634

[hayd]

What's weird is that I'm still convinced I'd tested it (on the other methods)!