Replace PYTHON_MODES with the more aptly named PYFITS_MODES since they map special named file modes used only by pyfits to their OS-level counterparts.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2282 ed100bfc-0583-0410-97f2-c26b58777a21
Removed most references to the 'copyonwrite' mode, which for some time has been identical in behavior to 'readonly'.  The mode is still supported but only for backwards compat.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2283 ed100bfc-0583-0410-97f2-c26b58777a21
Fixed an apparently long-standing typo in the fileobj_closed utility function

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2284 ed100bfc-0583-0410-97f2-c26b58777a21
Fixed another long-standing minor issue where the filobj_is_binary() utility function always return False on pyfits.file._File objects, even though it's required by definition to wrap a file opened in binary mode.  This solution is a hack but it'll do for now.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2285 ed100bfc-0583-0410-97f2-c26b58777a21
* Added the updated file mode normalization that can detect whether a
 file was opened in append mode (in general case, where 'a' is the mode
 string this is trivial, but the io.FileIO class has a bug that leaves
 'a' out of the mode string even if the file is in append mode.
* Offloaded repetitive handling of guessing the appropriate pyfits mode
  from file objects, and of handling overwriting existing files to the
  _File class.
* While I was at it, fixed handling of open ZipFile objects to work the
  same way of passing in a zip file by filename.
* Added some new tests to confirm the consistency of the file mode
  handling.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2286 ed100bfc-0583-0410-97f2-c26b58777a21
Fixed an issue on Windows where an IOError wasn't raised in the same place as on *nix systems when opening non-existent files for reading; included a unit test.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2287 ed100bfc-0583-0410-97f2-c26b58777a21
Added a changelog entry for the file I/O updates and included as a regression test the example that started all this work--it now passes as expected.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2288 ed100bfc-0583-0410-97f2-c26b58777a21
Fixed a couple Python 2.5 issues that came up in the fix to #33:
* The GzipFile class doesn't support the context manager protocol on
  older Python versions, so I changed a test that assumed it did
* Added a workaround to an issue where reading past the end of a
  GzipFile raised an IOError; not sure why this problem never exhibited
  itself before.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2293 ed100bfc-0583-0410-97f2-c26b58777a21
Fix some Python 3 specific issues.

One of them was a side effect of the issue #33 fixes:

* On any file object opened in append+update mode (that
  is, 'ab+') we need to normalize to seeking to the beginning of the
  file after opening, since on Python 3 it actually seeks FileIO objects
  to the *end* of the file after opening them in append mode.  This is
  not POSIX standard but is apparently a compromise with other systems
  that do have this behavior?

The others I'm not sure are related to #33, but hadn't come up before:

* Fixed writing padding bytes in the FitsHDU class--previously they
  were not ensured to be encoded as bytes.

* A strange issue with memoryview objects which, when used with nd Numpy
  arrays don't actually provide a raw byte buffer like the old buffer
  interface did.  Rather, you get a memoryview with the same shape and
  itemsize as the Numpy array, which is not useful when we tried to
  write to a file.  Instead just flatten the array and let Python's
  f.write work out how to get to the raw bytes.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2294 ed100bfc-0583-0410-97f2-c26b58777a21
This should really probably specify 'ab+', since just 'ab' is write-only anyways.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2295 ed100bfc-0583-0410-97f2-c26b58777a21
Fix a long-standing bug where writing a table with variable length
arrays didn't update the max array size in the column format in the
header.  I thought I had fixed this, but apparently I only did so for
compressed image HDUs.  Normal binary table HDUs still had the problem
(leading me to think there's some more refactoring to be done, given
then compressed image HDUs are just binary tables--they should be
sharing the same code for this I'd imagine).

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2296 ed100bfc-0583-0410-97f2-c26b58777a21
Adds a test that would have caught and a fix for a slight bug in FitsHDU.fromfile.  I think this was always supposed to say HDUList.fromfile.  I don't think this interface is often used though which is why it was not caught before now.

git-svn-id: http://svn6.assembla.com/svn/pyfits/trunk@2308 ed100bfc-0583-0410-97f2-c26b58777a21
Remove unused imports; some of this is redundant with the work done in https://github.com/astropy/astropy/pull/1445 on the astropy end, but some of it was a little different too somehow
Finally fixed up the _FormatX a class a bit to be more responsible for its own affairs a la _FormatP
Cleaned up a bit of code rot found by pylint. This included a handful of small bugs in code not covered by tests (some of which would have been difficult to cover due to external dependencies)
Updated this todo note.  This shouldn't be changed before 3.3.
Simplify the logic in this branch; don't need all the checks for P/Q
As a prerequisite to improving the consistency of how scaled table
columns are handled I finally got around to refactoring the
FITS_rec.field method a bit.  This is work I had been avoiding in
preference to just working on the existing plan of redoing table support
on top of Astropy tables.

That said, this was still relatively easy to do, and I think that the
new, cleaner code will be significantly easier to transfer over to a new
table implementation. It will also lend itself better to supporting
backwards compatibility with the recarray-based approach which will be
necessary for the first few releases that include any new table
implementation.

One major difference to the internal data structures introduced by this
fix is that *all* of the table columns are added to the
FITS_rec._convert list of converted columns, even if they don't require
any scaling or data type conversion.  In the non-conversion case the
array stored in ._convert is just the direct slice of the recarray
returned by recarray.field.  I'm still a little concerned whether this
change leads to memory leaks and that's something I need to test for
before merging this new code.  If it does cause memory leaks it would be
due to a reference cycle, and I think I can find a workaround.

There are a few other TODO items in this commit that need to be
addressed before merging as well.

This commit contains a fix for a bug that hadn't revealed itself until
making these other changes (but was necessary to fix for all the tests
to pass).  This is specifically the fact that the `FITS_rec.copy()`
method (inherited from `ndarray.copy()`) did not perform a deep copy of
all of a FITS_rec's attributes, including the arrays in the `._convert`
list.  This meant that when copying a `FITS_rec` with the copy method
the new array would have its own copy of the *raw* data, but the
converted arrays would remain shared.  This is especially bad in the new
case where slices of *all* of the columns are stored in `._convert`.
This meant that any update to the new table updated the old table as
well (likewise they shared the same column definitions).  So now
`FITS_rec.copy()` is overridden to ensure that all of the table's
attributes get a deep copy.  This in turn revealed that since
`Column.__new__` expects a minimum number of arguments,
`copy.(deep)copy()` did not work on it without first defining custom
`__(deep)copy__` methods.

*whew!*
At some point last week I noticed that the array argument to Column was undocumented, so apparently I added documentation for it.
Made management of the _ASCIIColDefs spans, starts, and _width attributes a little easier to understand and not dependent on as much unncessary magic/state.