Add lower_ and upper_ properties and map fn to Span class

[ericzhao28]

Added lower_ and upper_ properties as described in #669.
I also added a generic map function to execute on the string representations of each token in a span.

Types of changes

I added some simple features via very minor additions to spacy/tokens/span.pyx, and added corresponding tests to spacy/tests/spans/test_span.py.

Checklist:

• My change requires a change to spaCy's documentation. (Not sure about this, sorry)
• I have updated the documentation accordingly. (Should I do so in this case?)
• I have added tests to cover my changes.
• All new and existing tests passed.

This is my first commit to a major open-source project - please let me know if I should fix/add anything, and apologies ahead of time in case I somehow break something.

• Eric

[honnibal]

Thanks!

I'm not really convinced by the mapStr function. There are two cosmetic things, but I'm also leaning towards saying it's not necessary.

I'd like to keep the bar for putting things in the interface relatively high. I think the current:

''.join([my_func(token.text) for token in span])

Isn't difficult to read or write. If we needed to do something about this, I'd favour having a span.texts attribute. Then we can do:

map(my_func, span.texts)

Which is to me much better than:

span.map_str(my_func)

I think that it's even better to not have the span.texts attribute, though. If we don't have this, then the user writes:

''.join([my_func(token.text) for token in span])

And this works whether Span is a Doc, list, tuple etc -- any container.

If we do decide to have the mapStr method, we need:

• Rename: Probably map_str or map_text
• The .string attribute is deprecated. The .text attribute is the preferred one.
• The Doc object will need the method as well.

[ericzhao28]

Hi,
I removed mapStr and pushed that commit with only upper_ and lower_. I guess mapStr is a bit extraneous.

• Eric

[honnibal]

Thanks!