summaryrefslogtreecommitdiffstats
path: root/Objects/fileobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Generalize file.writelines() to allow iterable objects.Tim Peters2001-09-231-31/+31
|
* Add optional docstrings to getset descriptors. Fortunately, there'sGuido van Rossum2001-09-201-2/+2
| | | | | | | | | | 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.
* Add optional docstrings to member descriptors. For backwardsGuido van Rossum2001-09-201-4/+7
| | | | | | | | | | | | | | | 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.
* SF bug [#463093] File methods need doc strings.Tim Peters2001-09-201-14/+94
| | | | Now they don't.
* Patch #462849: Pass Unicode objects to file's .write method.Martin v. Löwis2001-09-191-3/+8
|
* The end of [#460467] file objects should be subclassable.Tim Peters2001-09-141-30/+63
| | | | | | | | 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).
* Get rid of builtin_open() entirely (the C code and docstring, not theTim Peters2001-09-131-2/+2
| | | | | builtin function); Guido pointed out that it could be just another name in the __builtin__ dict for the file constructor now.
* Now that file objects are subclassable, you can get at the file constructorTim Peters2001-09-131-0/+8
| | | | | | 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).
* SF bug [#460467] file objects should be subclassable.Tim Peters2001-09-131-23/+100
| | | | Preliminary support. What's here works, but needs fine-tuning.
* _portable_fseek():Guido van Rossum2001-09-101-0/+6
| | | | | | | | | | | | | | | | | | | | | 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.)
* Enable large file support on Win32 systems.Tim Peters2001-09-061-1/+1
| | | | | | | | | 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).
* Changes to automatically enable large file support on some systems.Guido van Rossum2001-09-051-12/+20
| | | | | | | | | | | | | | | | | | | | | 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.
* repr's converted to using PyString_FromFormat() instead of sprintf'ingBarry Warsaw2001-08-241-7/+5
| | | | | | into a hardcoded char* buffer. Closes patch #454743.
* Patch #427190: Implement and use METH_NOARGS and METH_O.Martin v. Löwis2001-08-161-33/+20
|
* Apply anonymous SF patch #441229.Guido van Rossum2001-08-091-0/+6
| | | | | | | | | | | | 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. :-)
* Remove spurious "closed" attribute definition from the memberlistGuido van Rossum2001-08-061-1/+0
| | | | table. (reported as an aside in SF #446049).
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-27/+18
|
* Kill more warnings from the SGI compiler.Fred Drake2001-07-191-1/+1
| | | | Part of SF patch #434992.
* 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
generated by cgit v0.12 at 2024-12-04 04:21:13 (GMT)