summaryrefslogtreecommitdiffstats
path: root/Objects/fileobject.c
Commit message (Collapse)AuthorAgeFilesLines
* file_getiter(): make iter(file) be equivalent to file.xreadlines().Guido van Rossum2001-05-221-12/+3
| | | | | | | | | | | | | | 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.
* Mondo changes to the iterator stuff, without changing how Python codeGuido van Rossum2001-04-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* Oops, forgot to merge this from the iter-branch to the trunk.Guido van Rossum2001-04-211-9/+37
| | | | This adds "for line in file" iteration, as promised.
* Make some private symbols static.Guido van Rossum2001-04-141-2/+2
|
* Two improvements to large file support:Guido van Rossum2001-03-011-30/+18
| | | | | | | | | | | | | | - 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.)
* Move distributed and duplicated config for stat() and fstat() into pyport.h.Tim Peters2001-01-181-20/+0
|
* Rationalizing the fallback code for portable fseek -- this is all muchGuido van Rossum2001-01-161-26/+12
| | | | | | | | | 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!
* Speed getline_via_fgets(), by supplying two "fast paths", although one isTim Peters2001-01-151-54/+81
| | | | | | | | 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 ...).
* Use the "MS" getline hack (fgets()) by default on non-get_unlockedTim Peters2001-01-151-30/+47
| | | | platforms. See NEWS for details.
* Jeff Epler's patch adding an xreadlines() method. (It just importsGuido van Rossum2001-01-091-1/+25
| | | | the xreadlines module and lets it do its thing.)
* Tsk, tsk, tsk. Treat FreeBSD the same as the other BSDs when definingGuido van Rossum2001-01-091-1/+1
| | | | a fallback for TELL64. Fixes SF Bug #128119.
* A few reformats; no logic changes.Tim Peters2001-01-081-9/+8
|
* Let's hope that three time's a charm...Guido van Rossum2001-01-081-3/+3
| | | | | | | | | | 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.
* Fiddled ms_getline_hack after talking w/ Guido: made clearer that theTim Peters2001-01-081-65/+67
| | | | | | | | | | | | | 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).
* MS Win32 .readline() speedup, as discussed on Python-Dev. This is a trickyTim Peters2001-01-071-15/+184
| | | | | | 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.
* Tim noticed that I had botched get_line_raw(). Looking again, IGuido van Rossum2001-01-071-47/+30
| | | | | | 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.
* Restructured get_line() for clarity and speed.Guido van Rossum2001-01-051-66/+59
| | | | | | | - 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).
* Make the indentation consistently use tabs instead of using spaces justFred Drake2000-12-201-3/+3
| | | | in one place.
* Patch #102868 from cgw: fix memory leak when an EOF is encounteredAndrew M. Kuchling2000-12-191-0/+3
| | | | using GNU libc's getline()
* Only use getline() when compiling using glibcAndrew M. Kuchling2000-11-301-1/+1
|
* Patch #102469: Use glibc's getline() extension when reading unbounded linesAndrew M. Kuchling2000-11-291-3/+30
|
* Added _HAVE_BSDI and __APPLE__ to the list of platforms that require aGuido van Rossum2000-11-131-1/+1
| | | | | hack for TELL64()... Sounds like there's something else going on really. Does anybody have a clue I can buy?
* Ka-Ping Yee <ping@lfw.org>:Fred Drake2000-10-241-3/+3
| | | | | | Changes to error messages to increase consistency & clarity. This (mostly) closes SourceForge patch #101839.
* Donn Cave <donn@oz.net>:Fred Drake2000-10-061-0/+2
| | | | | | | Fix large file support for BeOS. This closes SourceForge patch #101773. Refer to the patch discussion for information on possible alternate fixes.
* Rationalize use of limits.h, moving the inclusion to Python.h.Fred Drake2000-09-261-4/+0
| | | | | | | | Add definitions of INT_MAX and LONG_MAX to pyport.h. Remove includes of limits.h and conditional definitions of INT_MAX and LONG_MAX elsewhere. This closes SourceForge patch #101659 and bug #115323.
* Untested patch by Ty Sarna to make TELL64 work on older NetBSD systems.Guido van Rossum2000-09-211-2/+6
| | | | | According to Justin Pettit, this also works on OpenBSD, so I've added that symbol as well.
* REMOVED all CWI, CNRI and BeOpen copyright markings.Guido van Rossum2000-09-011-9/+0
| | | | This should match the situation in the 1.6b1 tree.
* Peter Schneider-Kamp <nowonder@nowonder.de>:Fred Drake2000-08-311-7/+3
| | | | | | Remove some of GCC's warning in -Wstrict-prototypes mode. This closes SourceForge patch #101342.
* Fixed a serious typo.Marc-André Lemburg2000-08-251-1/+1
|
* Fix to bug [ Bug #111860 ] file.writelines() crashes.Marc-André Lemburg2000-08-251-9/+34
| | | | | | | file.writelines() now tries to emulate the behaviour of file.write() as closely as possible. Due to the problems with releasing the interpreter lock the solution isn't exactly optimal, but still better than not supporting the file.write() semantics at all.
* Added include for limits.hJack Jansen2000-08-221-0/+4
|
* Add largefile support for Linux64 and WIn64. Add test_largefile and some minorTrent Mick2000-08-111-37/+145
| | | | | | | | | | change to regrtest.py to allow optional running of test_largefile ('cause it's slow on Win64). This closes patches: http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100510&group_id=5470 and http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=100511&group_id=5470
* Added PyObject_AsFileDescriptor, which checks for integer, long integer,Andrew M. Kuchling2000-07-131-0/+58
| | | | or .fileno() method
* ANSI-fication of the sources.Fred Drake2000-07-091-85/+30
|
* Nuke all remaining occurrences of Py_PROTO and Py_FPROTO.Tim Peters2000-07-091-3/+3
|
* Fix to bug #389:Marc-André Lemburg2000-07-051-4/+4
| | | | | | | Full_Name: Bastian Kleineidam Version: 2.0b1 CVS 5.7.2000 OS: Debian Linux 2.2 Submission from: earth.cs.uni-sb.de (134.96.252.92)
* Change copyright notice - 2nd try.Guido van Rossum2000-06-301-6/+0
|
* Change copyright notice.Guido van Rossum2000-06-301-22/+7
|
* Trent Mick <trentm@activestate.com>:Fred Drake2000-06-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The common technique for printing out a pointer has been to cast to a long and use the "%lx" printf modifier. This is incorrect on Win64 where casting to a long truncates the pointer. The "%p" formatter should be used instead. The problem as stated by Tim: > Unfortunately, the C committee refused to define what %p conversion "looks > like" -- they explicitly allowed it to be implementation-defined. Older > versions of Microsoft C even stuck a colon in the middle of the address (in > the days of segment+offset addressing)! The result is that the hex value of a pointer will maybe/maybe not have a 0x prepended to it. Notes on the patch: There are two main classes of changes: - in the various repr() functions that print out pointers - debugging printf's in the various thread_*.h files (these are why the patch is large) Closes SourceForge patch #100505.
* Jack Jansen: Moved includes to the top, removed think C supportGuido van Rossum2000-06-281-18/+20
|
* Vladimir Marangozov's long-awaited malloc restructuring.Guido van Rossum2000-05-031-1/+1
| | | | | | | | | | For more comments, read the patches@python.org archives. For documentation read the comments in mymalloc.h and objimpl.h. (This is not exactly what Vladimir posted to the patches list; I've made a few changes, and Vladimir sent me a fix in private email for a problem that only occurs in debug mode. I'm also holding back on his change to main.c, which seems unnecessary to me.)
* Checking in the new, improve file.writelines() code.Guido van Rossum2000-03-131-24/+78
| | | | | | This (1) avoids thread unsafety whereby another thread could zap the list while we were using it, and (2) now supports writing arbitrary sequences of strings.
* Many changes for Unicode, by Marc-Andre Lemburg.Guido van Rossum2000-03-101-1/+7
|
* Massive patch by Skip Montanaro to add ":name" to as manyGuido van Rossum2000-02-291-5/+5
| | | | PyArg_ParseTuple() format string arguments as possible.
* Patch by Mark Hammond to avoid certain header files on Windows/CE.Guido van Rossum1999-08-271-1/+10
|
* casts for picky compilers.Guido van Rossum1999-04-101-1/+1
|
* Jim Ahlstrom patch: BIGCHUNK is too large for 16-bit int.Guido van Rossum1999-01-141-1/+5
|
* Need to include <sys/types.h> for off_t.Guido van Rossum1999-01-071-0/+2
|
* Changes for long file support by Steve Clift.Guido van Rossum1999-01-061-11/+53
| | | | (This also redoes my previous patch, but better.)
* Fix two places (seek and truncate) where a cascade of PyArg_ParseGuido van Rossum1999-01-041-11/+9
| | | | | calls was used instead of a single PyArg_ParseTuple call with an optional argument.