Commit Graph

197 Commits

Author SHA1 Message Date
Peter Astrand f8e74b12b0 If close() fails in file_dealloc, then print an error message to
stderr. close() can fail if the user is out-of-quota, for example.
Fixes #959379.
2004-11-07 14:15:28 +00:00
Skip Montanaro 51ffac6db7 dump HAVE_FOPENRF stuff - obsolete 2004-06-11 04:49:03 +00:00
Raymond Hettinger cb87bc8e7e Add weakref support to array.array and file objects. 2004-05-31 00:35:52 +00:00
Andrew MacIntyre 4e10ed3b86 If a file is opened with an explicit buffer size >= 1, repeated
close() calls would attempt to free() the buffer already free()ed on
the first close().     [bug introduced with patch #788249]

Making sure that the buffer is free()ed in file object deallocation is
a belt-n-braces bit of insurance against a memory leak.
2004-04-04 07:01:35 +00:00
Nicholas Bastin abce8a681c Changed file.name to be the object passed as the 'name' argument to file()
Fixes SF Bug #773356
2004-03-21 20:24:07 +00:00
Fred Drake 086a0f79cd PyFile_WriteObject(): some of the local variables are only used when
Py_USING_UNICODE is defined
2004-03-19 15:22:36 +00:00
Skip Montanaro db6080507d Remove support for --without-universal-newlines (see PEP 11). 2004-02-07 13:53:46 +00:00
Jack Jansen 4bae2d5e46 Getting rid of code dependent on GUSI or the MetroWerks compiler. 2003-11-19 22:52:23 +00:00
Martin v. Löwis 849a972f35 Patch #809535: Mention behaviour of seek on text files. Backported to 2.3. 2003-10-18 09:38:01 +00:00
Raymond Hettinger 8ae4689657 Simplify and speedup uses of Py_BuildValue():
* Py_BuildValue("(OOO)",a,b,c)  -->  PyTuple_Pack(3,a,b,c)
* Py_BuildValue("()",a)         -->  PyTuple_New(0)
* Py_BuildValue("O", a)         -->  Py_INCREF(a)
2003-10-12 19:09:37 +00:00
Martin v. Löwis 7bbcde70d1 Only release buffer after file has been closed. Fixes #800824.
Will backport to 2.2.
2003-09-07 20:42:29 +00:00
Tim Peters f1827cfaab SF bug 801631: file.truncate fault on windows.
file_truncate():  C doesn't define what fflush(fp) does if fp is open
for update, and the preceding I/O operation on fp was input.  On Windows,
fflush() actually changes the current file position then.  Because
Windows doesn't support ftruncate() directly, this not only caused
Python's file.truncate() to change the file position (contra our docs),
it also caused the file not to change size.

Repaired by getting the initial file position at the start, restoring
it at the end, and tossing all the complicated micro-efficiency checks
trying to avoid "provably unnecessary" seeks.  file.truncate() can't
be a frequent operation, and seeking to the current file position has
got to be cheap anyway.

Bugfix candidate.
2003-09-07 03:30:18 +00:00
Martin v. Löwis 1e3bdf6c45 Patch #788249: Pass an explicit buffer to setvbuf in PyFile_SetBufSize().
Fixes #603724. Will backport to 2.3.
2003-09-04 19:01:46 +00:00
Neal Norwitz 98cad48171 Fix SF #789402, Memory leak on open()
If opening a directory, the exception would leak.
2003-08-15 20:05:45 +00:00
Martin v. Löwis 415da6e0b2 Only encode Unicode objects when printing them raw. 2003-05-18 12:56:25 +00:00
Martin v. Löwis 5467d4c0e3 Patch #612627: Add encoding attribute to file objects, and determine
the terminal encoding on Windows and Unix.
2003-05-10 07:10:12 +00:00
Tim Peters 015dd82136 Somewhere along the way, the softspace attr of file objects became read-
only.  Repaired, and added new tests to test_file.py.
2003-05-04 04:16:52 +00:00
Neal Norwitz cb3319f61e SF patch #683187, fix universal newline problems on error 2003-02-09 01:10:02 +00:00
Martin v. Löwis af6a27a704 Allow PyFile_GetLine() to return Unicode objects. Fixes #660165. 2003-01-03 19:16:14 +00:00
Raymond Hettinger ea3fdf44a2 SF patch #659536: Use PyArg_UnpackTuple where possible.
Obtain cleaner coding and a system wide
performance boost by using the fast, pre-parsed
PyArg_Unpack function instead of PyArg_ParseTuple
function which is driven by a format string.
2002-12-29 16:33:45 +00:00
Gustavo Niemeyer a080be8b63 * Objects/fileobject.c
(file_read): Replaced assertion with mixed sign operation by a simple
  comment (thank you Raymond). The algorithm is clear enough in that point.
2002-12-17 17:48:00 +00:00
Gustavo Niemeyer 786ddb29c9 Fixed bug
[#521782] unreliable file.read() error handling

* Objects/fileobject.c
  (file_read): Clear errors before leaving the loop in all situations,
  and also check if some data was read before exiting the loop with an
  EWOULDBLOCK exception.

* Doc/lib/libstdtypes.tex
* Objects/fileobject.c
  Document that sometimes a read() operation can return less data than
  what the user asked, if running in non-blocking mode.

* Misc/NEWS
  Document the fix.
2002-12-16 18:12:53 +00:00
Martin v. Löwis 6233c9b470 Patch #650834: Document 'U' in file mode, remove stale variables. 2002-12-11 13:06:53 +00:00
Martin v. Löwis 0073f2e428 Fix --disable-unicode compilation problems. 2002-11-21 23:52:35 +00:00
Mark Hammond c2e85bd4e2 Patch 594001: PEP 277 - Unicode file name support for Windows NT. 2002-10-03 05:10:39 +00:00
Jeremy Hylton 8b73542cf5 Reflow long lines. 2002-08-14 21:01:41 +00:00
Neal Norwitz d8b995f5e8 Make readahead functions static 2002-08-06 21:50:54 +00:00
Guido van Rossum 7a6e95948c SF patch 580331 by Oren Tirosh: make file objects their own iterator.
For a file f, iter(f) now returns f (unless f is closed), and f.next()
is similar to f.readline() when EOF is not reached; however, f.next()
uses a readahead buffer that messes up the file position, so mixing
f.next() and f.readline() (or other methods) doesn't work right.
Calling f.seek() drops the readahead buffer, but other operations
don't.

The real purpose of this change is to reduce the confusion between
objects and their iterators.  By making a file its own iterator, it's
made clearer that using the iterator modifies the file object's state
(in particular the current position).

A nice side effect is that this speeds up "for line in f:" by not
having to use the xreadlines module.  The f.xreadlines() method is
still supported for backwards compatibility, though it is the same as
iter(f) now.

(I made some cosmetic changes to Oren's code, and added a test for
"file closed" to file_iternext() and file_iter().)
2002-08-06 15:55:28 +00:00
Tim Peters 7a1f91709b WINDOWS_LEAN_AND_MEAN: There is no such symbol, although a very few
MSDN sample programs use it, apparently in error.  The correct name
is WIN32_LEAN_AND_MEAN.  After switching to the correct name, in two
cases more was needed because the code actually relied on things that
disappear when WIN32_LEAN_AND_MEAN is defined.
2002-07-14 22:14:19 +00:00
Martin v. Löwis 6238d2b024 Patch #569753: Remove support for WIN16.
Rename all occurrences of MS_WIN32 to MS_WINDOWS.
2002-06-30 15:26:10 +00:00
Martin v. Löwis 14f8b4cfcb Patch #568124: Add doc string macros. 2002-06-13 20:33:02 +00:00
Barry Warsaw 4be55b5cef file_doc: Add some description of the U mode character, but only when
WITH_UNIVERSAL_NEWLINES is enabled.
2002-05-22 20:37:53 +00:00
Tim Peters 5de9842b34 Repair widespread misuse of _PyString_Resize. Since it's clear people
don't understand how this function works, also beefed up the docs.  The
most common usage error is of this form (often spread out across gotos):

	if (_PyString_Resize(&s, n) < 0) {
		Py_DECREF(s);
		s = NULL;
		goto outtahere;
	}

The error is that if _PyString_Resize runs out of memory, it automatically
decrefs the input string object s (which also deallocates it, since its
refcount must be 1 upon entry), and sets s to NULL.  So if the "if"
branch ever triggers, it's an error to call Py_DECREF(s):  s is already
NULL!  A correct way to write the above is the simpler (and intended)

	if (_PyString_Resize(&s, n) < 0)
		goto outtahere;

Bugfix candidate.
2002-04-27 18:44:32 +00:00
Tim Peters e1682a80fa Py_UniversalNewlineFread(): small speed boost on non-Windows boxes. 2002-04-21 18:15:20 +00:00
Tim Peters 058b141ef7 Py_UniversalNewlineFread(): Many changes.
+ Continued looping until n bytes in the buffer have been filled, not
  just when n bytes have been read from the file.  This repairs the
  bug that f.readlines() only sucked up the first 8192 bytes of the file
  on Windows when universal newlines was enabled and f was opened in
  U mode (see Python-Dev -- this was the ultimate cause of the
  test_inspect.py failure).

+ Changed prototye to take a char* buffer (void* doesn't make much sense).

+ Squashed size_t vs int mismatches (in particular, besides the unsigned
  vs signed distinction, size_t may be larger than int).

+ Gets out under all error conditions now (it's possible for fread() to
  suffer an error even if it returns a number larger than 0 -- any
  "short read" is an error or EOF condition).

+ Rearranged and simplified declarations.
2002-04-21 07:29:14 +00:00
Jack Jansen 7b8c7546eb Mass checkin of universal newline support.
Highlights: import and friends will understand any of \r, \n and \r\n
as end of line. Python file input will do the same if you use mode 'U'.
Everything can be disabled by configuring with --without-universal-newlines.

See PEP278 for details.
2002-04-14 20:12:41 +00:00
Neil Schemenauer aa769ae468 PyObject_Del can now be used as a function designator. 2002-04-12 02:44:10 +00:00
Tim Peters 2ea9111cf1 SF bug 538827: Python open w/ MSVC6: bad error msgs.
open_the_file:  Some (not all) flavors of Windows set errno to EINVAL
when passed a syntactically invalid filename.  Python turned that into an
incomprehensible complaint about the mode string.  Fixed by special-casing
MSVC.
2002-04-08 04:13:12 +00:00
Guido van Rossum 7f7666ff43 isatty() should return a bool. 2002-04-07 06:28:00 +00:00
Guido van Rossum 77f6a65eb0 Add the 'bool' type and its values 'False' and 'True', as described in
PEP 285.  Everything described in the PEP is here, and there is even
some documentation.  I had to fix 12 unit tests; all but one of these
were printing Boolean outcomes that changed from 0/1 to False/True.
(The exception is test_unicode.py, which did a type(x) == type(y)
style comparison.  I could've fixed that with a single line using
issubtype(x, type(y)), but instead chose to be explicit about those
places where a bool is expected.

Still to do: perhaps more documentation; change standard library
modules to return False/True from predicates.
2002-04-03 22:41:51 +00:00
Neal Norwitz 62f5a9d6c2 Convert file.readinto() to stop using METH_OLDARGS & PyArg_Parse.
Add test for file.readinto().
2002-04-01 00:09:00 +00:00
Neil Schemenauer 3a204a7e48 Grow the string buffer at a mildly exponential rate for the getc version
of get_line.  This makes test_bufio finish in 1.7 seconds instead of 57
seconds on my machine (with Py_DEBUG defined).

Also, rename the local variables n1 and n2 to used_v_size and
total_v_size.
2002-03-23 19:41:34 +00:00
Tim Peters ddea208be9 Give Python a debug-mode pymalloc, much as sketched on Python-Dev.
When WITH_PYMALLOC is defined, define PYMALLOC_DEBUG to enable the debug
allocator.  This can be done independent of build type (release or debug).
A debug build automatically defines PYMALLOC_DEBUG when pymalloc is
enabled.  It's a detected error to define PYMALLOC_DEBUG when pymalloc
isn't enabled.

Two debugging entry points defined only under PYMALLOC_DEBUG:

+ _PyMalloc_DebugCheckAddress(const void *p) can be used (e.g., from gdb)
  to sanity-check a memory block obtained from pymalloc.  It sprays
  info to stderr (see next) and dies via Py_FatalError if the block is
  detectably damaged.

+ _PyMalloc_DebugDumpAddress(const void *p) can be used to spray info
  about a debug memory block to stderr.

A tiny start at implementing "API family" checks isn't good for
anything yet.

_PyMalloc_DebugRealloc() has been optimized to do little when the new
size is <= old size.  However, if the new size is larger, it really
can't call the underlying realloc() routine without either violating its
contract, or knowing something non-trivial about how the underlying
realloc() works.  A memcpy is always done in this case.

This was a disaster for (and only) one of the std tests:  test_bufio
creates single text file lines up to a million characters long.  On
Windows, fileobject.c's get_line() uses the horridly funky
getline_via_fgets(), which keeps growing and growing a string object
hoping to find a newline.  It grew the string object 1000 bytes each
time, so for a million-character string it took approximately forever
(I gave up after a few minutes).

So, also:

fileobject.c, getline_via_fgets():  When a single line is outrageously
long, grow the string object at a mildly exponential rate, instead of
just 1000 bytes at a time.

That's enough so that a debug-build test_bufio finishes in about 5 seconds
on my Win98SE box.  I'm curious to try this on Win2K, because it has very
different memory behavior than Win9X, and test_bufio always took a factor
of 10 longer to complete on Win2K.  It *could* be that the endless
reallocs were simply killing it on Win2K even in the release build.
2002-03-23 10:03:50 +00:00
Neil Schemenauer ed19b88f0b Check in (hopefully) corrected version of last change. 2002-03-23 02:06:50 +00:00
Neil Schemenauer 12a6d942d8 Undo last commit. It's causing the tests to file. 2002-03-22 23:50:30 +00:00
Neil Schemenauer 398b9f6d6d Disallow open()ing of directories. Closes SF bug 487277. 2002-03-22 20:38:57 +00:00
Martin v. Löwis f6eebbb435 Patch #530105: Allow file object may to be subtyped 2002-03-15 17:42:16 +00:00
Tim Peters 8f01b680c8 Change Windows file.truncate() to (a) restore the original file position,
and (b) stop trying to prevent file growth.

Beef up the file.truncate() docs.

Change test_largefile.py to stop assuming that f.truncate() moves the
file pointer to the truncation point, and to verify instead that it leaves
the file position alone.  Remove the test for what happens when a
specified size exceeds the original file size (it's ill-defined, according
to the Single Unix Spec).
2002-03-12 03:04:44 +00:00
Tim Peters fb05db2cae file_truncate(): provide full "large file" support on Windows, by
dropping MS's inadequate _chsize() function.  This was inspired by
SF patch 498109 ("fileobject truncate support for win32"), which I
rejected.

libstdtypes.tex:  Someone who knows should update the availability
blurb.  For example, if it's available on Linux, it would be good to
say so.

test_largefile:  Uncommented the file.truncate() tests, and reworked to
do more.  The old comment about "permission errors" in the truncation
tests under Windows was almost certainly due to that the file wasn't open
for *write* access at this point, so of course MS wouldn't let you
truncate it.  I'd be appalled if a Unixish system did.

CAUTION:  Someone should run this test on Linux (etc) too.  The
truncation part was commented out before.  Note that test_largefile isn't
run by default.
2002-03-11 00:24:00 +00:00
Andrew MacIntyre c487439aa7 OS/2 EMX port changes (Objects part of patch #450267):
Objects/
    fileobject.c
    stringobject.c
    unicodeobject.c

This commit doesn't include the cleanup patches for stringobject.c and
unicodeobject.c which are shown separately in the patch manager.  Those
patches will be regenerated and applied in a subsequent commit, so as
to preserve a fallback position (this commit to those files).
2002-02-26 11:36:35 +00:00