Fix AASTexData py2.6 incompatibility/performance boost

[eteq]

This is a slight adjustment to the change introduced in #4561 . It just pre-compiles the regex into an object that is then re-used in the re.sub call. While this is probably a trivial improvement on it's own, it has a much more important effect when backported to v1.1.x and v1.0.x: it fixes a py2.6 incompatibility introcued in #4561. It turns out that the flags keyword is not in re.sub in py2.6. So this PR works around that by using the compiled regex instead of compiling it as part of the re.sub call.

In principal this could be put only in v1.0.x/v1.1.x... But I think it's better to put it in master, as it has no downside and might be a performance improvement. Any opinions on that, @astrofrog or @taldcroft ?

(note that no changelog entry is needed because #4561 has not been in a release yet)

[astrofrog]

👍 I'm fine with putting this in master!

[taldcroft]

Looks OK. My normal style would be to call it something like re_final_empty_line and define it as a local variable instead of class attribute. I think compiled regexes are cached so this doesn't have any real performance impact.

[taldcroft]

Actually should just be re_final_line.

[eteq]

Hmm... I didn't realize that about the caching, @taldcroft - good to know!

One caveat though: https://docs.python.org/3.5/library/re.html#re.compile says this:

The compiled versions of the most recent patterns passed to re.compile() and the module-level matching functions are cached, so programs that use only a few regular expressions at a time needn’t worry about compiling regular expressions.

Doesn't that mean we should do this because astropy certainly uses a lot of different patterns in different places? I guess "most recent" is fairly ambiguous, though...

[eteq]

Actually I answered my own question by looking at re.py in the standard library. Turns out despite that wording in the docs, the cache looks to be just an ordinary dict, so it's not just the "most recent". So I'll change to as @taldcroft suggests, as that reduces the at-import runtime.

[eteq]

OK, change made. This muddies the water a bit in terms of whether it's worth having this in master... But my inclination is to just merge this and backport it for now as it probably now is basically neutral in terms of performance. If we want to remove it in another PR down the road, that's probably fine, as we just need to not backport it to 1.1.x or 1.0.x.

[taldcroft]

@eteq - I'm fine with this going in master.

[eteq]

Alright, I'll merge this now and backport, and that should restore py2.6 compatibility for the 1.0.x and 1.1.x branches.

[eteq]

backported to v1.1.x in 36d5394 and v1.0.x in 0b3d439