Reorganise core

[andrewgsavage]

I am finding core.py difficult to work with as there is so much in the file.

I've moved it into it's own folder, then started moving parts to other files in a similar way to what I have seen in other python modules.
eg anything related to formatting to .core/formatting.py, same for parsing etc.

I'd also like to follow pint's Quantity restructuring which uses subclassing and has made it easier to work with. For example, AffineScalarFunc.__format__ is currently in core.py. __format__ could be moved to a class in formatting.py and AffineScalarFunc could inherit __format__ from that class.

What are people thought's on this approach?

[newville]

@andrewgsavage I might suggest also inverting the use of UFloat as an alias for AffineScalarFunc. That is, I think the main interface and way of thinking of the basic object is as a UFloat, and the name "AffineScalarFunc" is slightly odd and confusing to see in exceptions.

[andrewgsavage]

I agree, but I think that's worth doing in another PR to make this easier to review. AffineScalarFunc is refered to in many docstrings that would need changing too. Here I've only moved functions and classes into new files. I've got it to the point where the python 3.5 CI shows tests passing which looks as good as it can get.

I've a branch continuing from this where I've started using subclassing and getting numpy to work on scalars. Was hoping to get this one merged first.

[newville]

@andrewgsavage I agree with all of that, and great to hear about the branch with continued work on arrays.

I'm still in favor of waiting until March 1 in hopes of getting a cleaner transition, but without any communication from @lebigot about this, it is not easy to be optimistic.

Would make sense to start working on lmfit/uncertainties or perhaps some other repo or maybe a wiki where design and priorities could be discussed?

[andrewgsavage]

Yea waiting until March 1 is fine. I think it's easier to keep discussion in this repo for the time being as it keeps everything in the same place.

I think the maintaince issue is fine for disussing design and priorities. If I've got code ready I'll put it in a PR as for things like subclassing and numpy support it's a little easier to see it in code than describe.