Eliminate superfluous call to _convert_format, since the format objects themselves should already know their Numpy record format...

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2338 ed100bfc-0583-0410-97f2-c26b58777a21
Manual merge of https://github.com/astropy/astropy/pull/906 with a few
small changes, and a few larger changes (read: hacks) to get this change
integrated with my new half-complete table refactoring.  The result is a
big huge mess--even worse than I expected--illustrating why I wanted to
get further with the refactoring in the first place before incorporating
this change.  But c'est la vie...

Another substative change worth pointing is out is I added an internal
switch so that table columns are read as uints *only* if the file was
opened with uint=True, as is the case for images.  How this is handled
will be revisited in a future version (really it should be on by
default, as even the FITS Standard discusses this convention in newer
versions).

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2339 ed100bfc-0583-0410-97f2-c26b58777a21
Fix some syntax and other minor breakages on Python 2.5--this changeset should not be ported to Astropy

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2340 ed100bfc-0583-0410-97f2-c26b58777a21
This function doesn't exist anymore

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2341 ed100bfc-0583-0410-97f2-c26b58777a21
Fix up links

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2342 ed100bfc-0583-0410-97f2-c26b58777a21
Removed some code rot that was only added complication at this point.  It should be noted that the change in the expected output in the tests is due to elmination of unnecessary changes to column format codes as long as the code is still valid

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2343 ed100bfc-0583-0410-97f2-c26b58777a21
Followup to 43c6162c48083fbf1d48757849da588348df6ab3--this entire method can be removed now.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2344 ed100bfc-0583-0410-97f2-c26b58777a21
Justin Ely pointed out a regression where previously it was possible to pass in something like format='f4' to the Column initializer, indicating that a single precision float column should be created (presumably for a binary table, at least by default).  The fact that this even worked before only further compounds the confusion over the 'format' argument, but I didn't intend to cause a regression on this behavior, and who knows how much code is out there that depends on it.  This adds still more sophistication to the column format guessing scheme, and fixes a few other issues that arose when I wrote regression tests covering the previous behavior.  This also reverts the change I (likely sleepily) made to the tests in 43c6162c48083fbf1d48757849da588348df6ab3, which allowed binary tables to be written with format codes for character columns like 'A10' (for 10 character strings).  The proper format, per the FITS standard, should always be '10A'.  Although the Column constructor allows both forms, only the '10A' form should be written.  I couldn't find *any* FITS documentation suggesting flexibility in this matter (the closes I could find is the substring array convention: http://fits.gsfc.nasa.gov/registry/substring.html, but that has never been supported by PyFITS).

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2345 ed100bfc-0583-0410-97f2-c26b58777a21
Added documentation for the new support of pseudo-unsigned integer columns to the changelog

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2346 ed100bfc-0583-0410-97f2-c26b58777a21
The README in cextern says to follow the comments in setup.cfg in order to configure the build to use the system CFITSIO. But at some point those comments were removed (possibly by a tool using ConfigParser).

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2347 ed100bfc-0583-0410-97f2-c26b58777a21
This is necessary to support compiling with older system installs of CFITSIO (older than 3.35 anyways--I don't think any older that 3.28 will work at all)

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2348 ed100bfc-0583-0410-97f2-c26b58777a21
Backported astropy/astropy#968 including updates for Python 2.5.  Will backport this fix to PyFITS 3.1.x and 3.0.x branches

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2351 ed100bfc-0583-0410-97f2-c26b58777a21
Merge pull request #996 from iguananaut/issue-996

Column.null not used when writing FITS table?
Conflicts:

	CHANGES.rst
	astropy/io/fits/column.py
	lib/pyfits/hdu/table.py

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2356 ed100bfc-0583-0410-97f2-c26b58777a21
Ignore warning produced by known issue for now; see https://github.com/spacetelescope/PyFITS/issues/44

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2357 ed100bfc-0583-0410-97f2-c26b58777a21
Fix an obscure issue in one of the tests related to Windows, older versions of Python, and float('nan')

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2358 ed100bfc-0583-0410-97f2-c26b58777a21
Travis doesn't support Python 2.5 anymore; but the 3.3 support should be improved--let's give it a try

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2361 ed100bfc-0583-0410-97f2-c26b58777a21
Re-disable 3.3 for now.  I need to take a closer look at this but I think I may be able to resolve it by using Astropy's wheel of Numpy for Python 3.3

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2364 ed100bfc-0583-0410-97f2-c26b58777a21
Remove the checks for whether the released project is 'pyfits'--these are not necessary since the release hooks are no longer installed as setuptools entry points

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2384 ed100bfc-0583-0410-97f2-c26b58777a21
Update the releaser hooks to tweak how tags are created--this is taken right out of Astropy, and I had forgotten this wasn't the default behavior of zest.releaser...

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2385 ed100bfc-0583-0410-97f2-c26b58777a21
Updated 3.0.12 and 3.1.3 release dates

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2386 ed100bfc-0583-0410-97f2-c26b58777a21