Commit Graph

247 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
Martin v. Löwis cdc4451222 Include <unistd.h> in Python.h. Fixes #500924. 2002-01-12 11:05:12 +00:00
Neal Norwitz 649b75954a SF Patch #494863, file.xreadlines() should raise ValueError if file is closed
This makes xreadlines behave like all other file methods
(other than close() which just returns).
2002-01-01 19:07:13 +00:00
Jack Jansen b3be216b41 Merged changes made on r22b2-branch between r22b2 and r22b2-mac (the
changes from start of branch upto r22b2 were already merged, of course).
2001-11-30 14:16:36 +00:00
Tim Peters c1bbcb87aa PyFile_WriteString(): change prototype so that the string arg is
const char* instead of char*.  The change is conceptually correct, and
indirectly fixes a compiler wng introduced when somebody else innocently
passed a const char* to this function.
2001-11-28 22:13:25 +00:00
Tim Peters a27a150ea5 open_the_file(): Explicitly set errno to 0 before calling fopen(). 2001-11-09 20:59:14 +00:00
Tim Peters 114486701a open_the_file(): this routine has a borrowed reference to the file
object, so the "Metroworks only" section should not decref it in case
of error (the caller is responsible for decref'ing in case of error --
and does).
2001-11-09 19:23:47 +00:00
Jeremy Hylton 41c8321252 Fix SF buf #476953: Bad more for opening file gives bad msg.
If fopen() fails with EINVAL it means that the mode argument is
invalid.  Return the mode in the error message instead of the
filename.
2001-11-09 16:17:24 +00:00
Michael W. Hudson e2ec3ebcb8 fix for
[ #476557 ] Wrong error message for file.write(a, b)

Makes file.write a METH_VARARGS function.
2001-10-31 18:51:01 +00:00
Guido van Rossum 00ebd46dfc SF patch #474175 (Jay T Miller): file.readinto arg parsing bug
The C-code in fileobject.readinto(buffer) which parses
    the arguments assumes that size_t is interchangeable
    with int:

	    size_t ntodo, ndone, nnow;

	    if (f->f_fp == NULL)
		    return err_closed();
	    if (!PyArg_Parse(args, "w#", &ptr, &ntodo))
		    return NULL;

    This causes a problem on Alpha / Tru64 / OSF1 v5.1
    where size_t is a long and sizeof(long) != sizeof(int).

    The patch I'm proposing declares ntodo as an int.  An
    alternative might be to redefine w# to expect size_t.

[We can't change w# because there are probably third party modules
relying on it. GvR]
2001-10-23 21:25:24 +00:00
Guido van Rossum 79fd0fcae4 Band-aid solution to SF bug #470634: readlines() on linux requires 2 ^D's.
The problem is that if fread() returns a short count, we attempt
another fread() the next time through the loop, and apparently glibc
clears or ignores the eof condition so the second fread() requires
another ^D to make it see the eof condition.

According to the man page (and the C std, I hope) fread() can only
return a short count on error or eof.  I'm using that in the band-aid
solution to avoid calling fread() a second time after a short read.

Note that xreadlines() still has this problem: it calls
readlines(sizehint) until it gets a zero-length return.  Since
xreadlines() is mostly used for reading real files, I won't worry
about this until we get a bug report.
2001-10-12 20:01:53 +00:00
Jack Jansen 2771b5b52b Rather gross workaround for a bug in the mac GUSI I/O library:
lseek(fp, 0L, SEEK_CUR) can make a filedescriptor unusable.
This workaround is expected to last only a few weeks (until GUSI
is fixed), but without it test_email fails.
2001-10-10 22:03:27 +00:00
Guido van Rossum 9475a2310d Enable GC for new-style instances. This touches lots of files, since
many types were subclassable but had a xxx_dealloc function that
called PyObject_DEL(self) directly instead of deferring to
self->ob_type->tp_free(self).  It is permissible to set tp_free in the
type object directly to _PyObject_Del, for non-GC types, or to
_PyObject_GC_Del, for GC types.  Still, PyObject_DEL was a tad faster,
so I'm fearing that our pystone rating is going down again.  I'm not
sure if doing something like

void xxx_dealloc(PyObject *self)
{
	if (PyXxxCheckExact(self))
		PyObject_DEL(self);
	else
		self->ob_type->tp_free(self);
}

is any faster than always calling the else branch, so I haven't
attempted that -- however those types whose own dealloc is fancier
(int, float, unicode) do use this pattern.
2001-10-05 20:51:39 +00:00
Tim Peters 2c9aa5ea8d Generalize file.writelines() to allow iterable objects. 2001-09-23 04:06:05 +00:00
Guido van Rossum 32d34c809f Add optional docstrings to getset descriptors. Fortunately, there's
no backwards compatibility to worry about, so I just pushed the
'closure' struct member to the back -- it's never used in the current
code base (I may eliminate it, but that's more work because the getter
and setter signatures would have to change.)

As examples, I added actual docstrings to the getset attributes of a
few types: file.closed, xxsubtype.spamdict.state.
2001-09-20 21:45:26 +00:00
Guido van Rossum 6f7993765a Add optional docstrings to member descriptors. For backwards
compatibility, this required all places where an array of "struct
memberlist" structures was declared that is referenced from a type's
tp_members slot to change the type of the structure to PyMemberDef;
"struct memberlist" is now only used by old code that still calls
PyMember_Get/Set.  The code in PyObject_GenericGetAttr/SetAttr now
calls the new APIs PyMember_GetOne/SetOne, which take a PyMemberDef
argument.

As examples, I added actual docstrings to the attributes of a few
types: file, complex, instance method, super, and xxsubtype.spamlist.

Also converted the symtable to new style getattr.
2001-09-20 20:46:19 +00:00
Tim Peters efc3a3af3b SF bug [#463093] File methods need doc strings.
Now they don't.
2001-09-20 07:55:22 +00:00
Martin v. Löwis 2777c021fc Patch #462849: Pass Unicode objects to file's .write method. 2001-09-19 13:47:32 +00:00
Tim Peters 4441001b56 The end of [#460467] file objects should be subclassable.
A surprising number of changes to split tp_new into tp_new and tp_init.
Turned out the older PyFile_FromFile() didn't initialize the memory it
allocated in all (error) cases, which caused new sanity asserts
elsewhere to fail left & right (and could have, e.g., caused file_dealloc
to try decrefing random addresses).
2001-09-14 03:26:08 +00:00
Tim Peters 742dfd6f17 Get rid of builtin_open() entirely (the C code and docstring, not the
builtin function); Guido pointed out that it could be just another
name in the __builtin__ dict for the file constructor now.
2001-09-13 21:49:44 +00:00
Tim Peters 8fa45677c1 Now that file objects are subclassable, you can get at the file constructor
just by doing type(f) where f is any file object.  This left a hole in
restricted execution mode that rexec.py can't plug by itself (although it
can plug part of it; the rest is plugged in fileobject.c now).
2001-09-13 21:01:29 +00:00
Tim Peters 59c9a645e2 SF bug [#460467] file objects should be subclassable.
Preliminary support.  What's here works, but needs fine-tuning.
2001-09-13 05:38:56 +00:00
Guido van Rossum 8b4e43e768 _portable_fseek():
Subtlety on Windows: if we change test_largefile.py to use a file
> 4GB, it still fails.  A debug session suggests this is because
fseek(fp, 0, 2) refuses to seek to the end of the file when the file
is > 4GB, because it uses the SetFilePointer() in 32-bit mode.

But it only fails when we seek relative to the end of the file,
because in the other seek modes only calls to fgetpos() and fsetpos()
are made, which use Get/SetFilePointer() in 64-bit mode.  Solution:
#ifdef MS_WInDOWS, replace the call to fseek(fp, ...) with a call to
_lseeki64(fileno(fp), ...).  Make sure to call fflush(fp) first.

(XXX Could also replace the entire branch with a call to _lseeki64().
Would that be more efficient?  Certainly less generated code.)

(XXX This needs more testing.  I can't actually test that it works for
files >4GB on my Win98 machine, because the filesystem here won't let
me create files >=4GB at all.  Tim should test this on his Win2K
machine.)
2001-09-10 20:43:35 +00:00
Tim Peters 6e13a562ae Enable large file support on Win32 systems.
Curious:  the MS docs say stati64 etc are supported even on Win95, but
Win95 doesn't support a filesystem that allows partitions > 2 Gb.

test_largefile:  This was opening its test file in text mode.  I have no
idea how that worked under Win64, but it sure needs binary mode on Win98.
BTW, on Win98 test_largefile runs quickly (under a second).
2001-09-06 00:32:15 +00:00
Guido van Rossum b855216099 Changes to automatically enable large file support on some systems.
I believe this works on Linux (tested both on a system with large file
support and one without it), and it may work on Solaris 2.7.

The changes are twofold:

(1) The configure script now boldly tries to set the two symbols that
    are recommended (for Solaris and Linux), and then tries a test
    script that does some simple seeking without writing.

(2) The _portable_{fseek,ftell} functions are a little more systematic
    in how they try the different large file support options: first
    try fseeko/ftello, but only if off_t is large; then try
    fseek64/ftell64; then try hacking with fgetpos/fsetpos.

I'm keeping my fingers crossed.  The meaning of the
HAVE_LARGEFILE_SUPPORT macro is not at all clear.

I'll see if I can get it to work on Windows as well.
2001-09-05 14:58:11 +00:00
Barry Warsaw 7ce3694a52 repr's converted to using PyString_FromFormat() instead of sprintf'ing
into a hardcoded char* buffer.

Closes patch #454743.
2001-08-24 18:34:26 +00:00
Martin v. Löwis e3eb1f2b23 Patch #427190: Implement and use METH_NOARGS and METH_O. 2001-08-16 13:15:00 +00:00
Guido van Rossum 29206bc8a3 Apply anonymous SF patch #441229.
Previously, f.read() and f.readlines() checked for
  errors on their file object and possibly raised an
  IOError, but f.readline() didn't. This patch makes
  f.readline() behave like the others.

Note that I've added a call to clearerr() since the other calls to
ferror() include that too.

I have no way to test this code. :-)
2001-08-09 18:14:59 +00:00
Guido van Rossum 63e0a64562 Remove spurious "closed" attribute definition from the memberlist
table.  (reported as an aside in SF #446049).
2001-08-06 18:51:38 +00:00
Tim Peters 6d6c1a35e0 Merge of descr-branch back into trunk. 2001-08-02 04:15:00 +00:00
Fred Drake 1bc8fab0e7 Kill more warnings from the SGI compiler.
Part of SF patch #434992.
2001-07-19 21:49:38 +00:00
Guido van Rossum 5b021848ac file_getiter(): make iter(file) be equivalent to file.xreadlines().
This should be faster.

This means:

(1) "for line in file:" won't work if the xreadlines module can't be
    imported.

(2) The body of "for line in file:" shouldn't use the file directly;
    the effects (e.g. of file.readline(), file.seek() or even
    file.tell()) would be undefined because of the buffering that goes
    on in the xreadlines module.
2001-05-22 16:48:37 +00:00
Guido van Rossum 213c7a6aa5 Mondo changes to the iterator stuff, without changing how Python code
sees it (test_iter.py is unchanged).

- Added a tp_iternext slot, which calls the iterator's next() method;
  this is much faster for built-in iterators over built-in types
  such as lists and dicts, speeding up pybench's ForLoop with about
  25% compared to Python 2.1.  (Now there's a good argument for
  iterators. ;-)

- Renamed the built-in sequence iterator SeqIter, affecting the C API
  functions for it.  (This frees up the PyIter prefix for generic
  iterator operations.)

- Added PyIter_Check(obj), which checks that obj's type has a
  tp_iternext slot and that the proper feature flag is set.

- Added PyIter_Next(obj) which calls the tp_iternext slot.  It has a
  somewhat complex return condition due to the need for speed: when it
  returns NULL, it may not have set an exception condition, meaning
  the iterator is exhausted; when the exception StopIteration is set
  (or a derived exception class), it means the same thing; any other
  exception means some other error occurred.
2001-04-23 14:08:49 +00:00
Guido van Rossum 65967259f2 Oops, forgot to merge this from the iter-branch to the trunk.
This adds "for line in file" iteration, as promised.
2001-04-21 13:20:18 +00:00
Guido van Rossum f68d8e52e7 Make some private symbols static. 2001-04-14 17:55:09 +00:00
Guido van Rossum 4f53da07bf Two improvements to large file support:
- In _portable_ftell(), try fgetpos() before ftello() and ftell64().
  I ran into a situation on a 64-bit capable Linux where the C
  library's ftello() and ftell64() returned negative numbers despite
  fpos_t and off_t both being 64-bit types; fgetpos() did the right
  thing.

- Define a new typedef, Py_off_t, which is either fpos_t or off_t,
  depending on which one is 64 bits.  This removes the need for a lot
  of #ifdefs later on.  (XXX Should this be moved to pyport.h?  That
  file currently seems oblivious to large fille support, so for now
  I'll leave it here where it's needed.)
2001-03-01 18:26:53 +00:00
Tim Peters 60f42b50d8 Move distributed and duplicated config for stat() and fstat() into pyport.h. 2001-01-18 03:03:16 +00:00
Guido van Rossum e54e0be3b6 Rationalizing the fallback code for portable fseek -- this is all much
simpler if we use fgetpos and fsetpos, rather than trying to mess with
platform-specific TELL64 alternatives.

Of course, this hasn't been tested on a 64-bit platform, so I may have
to withdraw this -- but I'm hopeful, and Trent Mick supports this
patch!
2001-01-16 20:53:31 +00:00
Tim Peters 142297ac92 Speed getline_via_fgets(), by supplying two "fast paths", although one is
faster than the other.  Should be faster for Mark Favas's 254-character
mail log lines, and *is* 3-4% quicker for my test case with much shorter
lines (but they're typical of *my* text files, and I'm tired of optimizing
for everyone else at my expense <wink> -- in fact, the only one who loses
here is Guido ...).
2001-01-15 10:36:56 +00:00
Tim Peters f29b64d243 Use the "MS" getline hack (fgets()) by default on non-get_unlocked
platforms.  See NEWS for details.
2001-01-15 06:33:19 +00:00
Guido van Rossum e07d5cf966 Jeff Epler's patch adding an xreadlines() method. (It just imports
the xreadlines module and lets it do its thing.)
2001-01-09 21:50:24 +00:00
Guido van Rossum dcf5715db1 Tsk, tsk, tsk. Treat FreeBSD the same as the other BSDs when defining
a fallback for TELL64.  Fixes SF Bug #128119.
2001-01-09 02:00:11 +00:00
Tim Peters 1c73323d6f A few reformats; no logic changes. 2001-01-08 04:02:07 +00:00
Guido van Rossum 8628206b95 Let's hope that three time's a charm...
Tim discovered another "bug" in my get_line() code: while the comments
said that n<0 was invalid, it was in fact still called with n<0 (when
PyFile_GetLine() was called with n<0).  In that case fortunately
executed the same code as for n==0.

Changed the comment to admit this fact, and changed Tim's MS speed
hack code to use 'n <= 0' as the criteria for the speed hack.
2001-01-08 01:26:47 +00:00
Tim Peters 15b838521f Fiddled ms_getline_hack after talking w/ Guido: made clearer that the
code duplication is to let us get away without a realloc whenever possible;
boosted the init buf size (the cutoff at which we *can* get away without
a realloc) from 100 to 200 so that more files can enjoy this boost; and
allowed other threads to run in all cases.  The last two cost something,
but not significantly:  in my fat test case, less than a 1% slowdown total.
Since my test case has a great many short lines, that's probably the worst
slowdown, too.  While the logic barely changed, there were lots of edits.
This also gets rid of the reference to fp->_cnt, so the last platform
assumption being made here is that fgets doesn't overwrite bytes
capriciously (== beyond the terminating null byte it must write).
2001-01-08 00:53:12 +00:00
Tim Peters 86821b2563 MS Win32 .readline() speedup, as discussed on Python-Dev. This is a tricky
variant that never needs to "search from the right".
Also fixed unlikely memory leak in get_line, if string size overflows INTMAX.
Also new std test test_bufio to make sure .readline() works.
2001-01-07 21:19:34 +00:00
Guido van Rossum 4ddf0a01f7 Tim noticed that I had botched get_line_raw(). Looking again, I
realized that this behavior is already present in PyFile_GetLine(),
which is the only place that needs it.  A little refactoring of that
function made get_line_raw() redundant.
2001-01-07 20:51:39 +00:00
Guido van Rossum 1187aa4d33 Restructured get_line() for clarity and speed.
- The raw_input() functionality is moved to a separate function.

- Drop GNU getline() in favor of getc_unlocked(), which exists on more
  platforms (and is even a tad faster on my system).
2001-01-05 14:43:05 +00:00
Fred Drake e7e190ef97 Make the indentation consistently use tabs instead of using spaces just
in one place.
2000-12-20 00:55:07 +00:00
Andrew M. Kuchling 932af110d3 Patch #102868 from cgw: fix memory leak when an EOF is encountered
using GNU libc's getline()
2000-12-19 20:59:04 +00:00
Andrew M. Kuchling 1221e6df3d Only use getline() when compiling using glibc 2000-11-30 18:27:50 +00:00