summaryrefslogtreecommitdiffstats
path: root/Objects/fileobject.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Include <unistd.h> in Python.h. Fixes #500924.Martin v. Löwis2002-01-121-4/+0
|
* SF Patch #494863, file.xreadlines() should raise ValueError if file is closedNeal Norwitz2002-01-011-0/+2
| | | | | This makes xreadlines behave like all other file methods (other than close() which just returns).
* Merged changes made on r22b2-branch between r22b2 and r22b2-mac (theJack Jansen2001-11-301-2/+7
| | | | changes from start of branch upto r22b2 were already merged, of course).
* PyFile_WriteString(): change prototype so that the string arg isTim Peters2001-11-281-1/+1
| | | | | | 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.
* open_the_file(): Explicitly set errno to 0 before calling fopen().Tim Peters2001-11-091-0/+1
|
* open_the_file(): this routine has a borrowed reference to the fileTim Peters2001-11-091-1/+0
| | | | | | 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).
* Fix SF buf #476953: Bad more for opening file gives bad msg.Jeremy Hylton2001-11-091-2/+6
| | | | | | If fopen() fails with EINVAL it means that the mode argument is invalid. Return the mode in the error message instead of the filename.
* fix forMichael W. Hudson2001-10-311-2/+2
| | | | | | [ #476557 ] Wrong error message for file.write(a, b) Makes file.write a METH_VARARGS function.
* SF patch #474175 (Jay T Miller): file.readinto arg parsing bugGuido van Rossum2001-10-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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]
* Band-aid solution to SF bug #470634: readlines() on linux requires 2 ^D's.Guido van Rossum2001-10-121-4/+11
| | | | | | | | | | | | | | | | 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.
* Rather gross workaround for a bug in the mac GUSI I/O library:Jack Jansen2001-10-101-1/+7
| | | | | | 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.
* Enable GC for new-style instances. This touches lots of files, sinceGuido van Rossum2001-10-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | 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.
* 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
|
generated by cgit v0.12 at 2025-01-18 21:43:43 (GMT)