summaryrefslogtreecommitdiffstats
path: root/Include
Commit message (Collapse)AuthorAgeFilesLines
* Add _Py_AS_GC macro. It will be used by the trashcan code on object.c.Neil Schemenauer2002-03-281-2/+4
|
* PYMALLOC_DEBUG routines: The "check API family" gimmick was going nowhereTim Peters2002-03-281-6/+6
| | | | | fast, and just cluttered the code. Get rid of it for now. If a compelling case can be made for it, easy to restore it later.
* Introduce two new flag bits that can be set in a PyMethodDef methodFred Drake2002-03-281-1/+7
| | | | | | | | | | | | | | | | | | | descriptor, as used for the tp_methods slot of a type. These new flag bits are both optional, and mutually exclusive. Most methods will not use either. These flags are used to create special method types which exist in the same namespace as normal methods without having to use tedious construction code to insert the new special method objects in the type's tp_dict after PyType_Ready() has been called. If METH_CLASS is specified, the method will represent a class method like that returned by the classmethod() built-in. If METH_STATIC is specified, the method will represent a static method like that returned by the staticmethod() built-in. These flags may not be used in the PyMethodDef table for modules since these special method types are not meaningful in that case; a ValueError will be raised if these flags are found in that context.
* Add a comment that PyArg_GetInt is deprecated and should not be usedNeal Norwitz2002-03-251-0/+1
|
* Remove many uses of PyArg_NoArgs macro, change METH_OLDARGS to METH_NOARGS.Neal Norwitz2002-03-251-0/+3
|
* Give Python a debug-mode pymalloc, much as sketched on Python-Dev.Tim Peters2002-03-232-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Disable the parser hacks that enabled the "yield" keyword using a futureNeil Schemenauer2002-03-221-0/+2
| | | | statement.
* Make PyObject_{NEW,New,Del,DEL} always use the standard malloc (PyMem_*)Neil Schemenauer2002-03-221-8/+23
| | | | | | and not pymalloc. Add the functions PyMalloc_New, PyMalloc_NewVar, and PyMalloc_Del that will use pymalloc if it's enabled. If pymalloc is not enabled then they use the standard malloc (PyMem_*).
* Arrange to export the _PyMalloc_{Malloc, Realloc, Free} entry points. OnTim Peters2002-03-201-3/+3
| | | | | | | | | | | | | Windows some modules are considered (by me, and I don't care what anyone else thinks about this <wink>) to be part of "the core" despite that they happen to be compiled into separate DLLs (the "to DLL or not to DLL?" question on Windows is nearly arbitrary). Making the pymalloc entry points available to them allows the Windows build to complete without incident when WITH_PYMALLOC is #define'd. Note that this isn't unprecedented. Other "private API" functions we export include _PySequence_IterSearch, _PyEval_SliceIndex, _PyCodec_Lookup, _Py_ZeroStruct, _Py_TrueStruct, _PyLong_New and _PyModule_Clear.
* [Bug #528914] PyTraceBack_Store/Fetch were deleted in 1997, but theirAndrew M. Kuchling2002-03-191-3/+1
| | | | | | prototypes remain. Noted by Yakov Markovitch. Bugfix candidate.
* Drop the PyCore_* memory API.Neil Schemenauer2002-03-182-70/+34
|
* Simpilify PyCore_* macros by assuming the function prototypes forNeil Schemenauer2002-03-182-97/+13
| | | | malloc() and free() don't change.
* Patch #530105: Allow file object may to be subtypedMartin v. Löwis2002-03-151-0/+11
|
* SF bug 525705: [2.2] underflow raise OverflowException.Tim Peters2002-03-091-0/+35
| | | | | | | | | | | | | | | | | | | | Another year in the quest to out-guess random C behavior. Added macros Py_ADJUST_ERANGE1(X) and Py_ADJUST_ERANGE2(X, Y). The latter is useful for functions with complex results. Two corrections to errno- after-libm-call are attempted: 1. If the platform set errno to ERANGE due to underflow, clear errno. Some unknown subset of libm versions and link options do this. It's allowed by C89, but I never figured anyone would do it. 2. If the platform did not set errno but overflow occurred, force errno to ERANGE. C89 required setting errno to ERANGE, but C99 doesn't. Some unknown subset of libm versions and link options do it the C99 way now. Bugfix candidate, but hold off until some Linux people actually try it, with and without -lieee. I'll send a help plea to Python-Dev.
* Whether platform malloc(0) returns NULL has nothing to do with whetherTim Peters2002-03-022-9/+22
| | | | | | | | | | | platform realloc(p, 0) returns NULL, so MALLOC_ZERO_RETURNS_NULL can be correctly undefined yet realloc(p, 0) can return NULL anyway. Prevent realloc(p, 0) doing free(p) and returning NULL via a different hack. Would probably be better to get rid of MALLOC_ZERO_RETURNS_NULL entirely. Bugfix candidate.
* For clarity, change _longobject to build directly from PyObject_VAR_HEADTim Peters2002-03-021-3/+6
| | | | | instead of faking it by hand. It *is* a var object, and nothing but hysterical raisins to pretend it's an oddball.
* Cells are not VAR objects.Jeremy Hylton2002-02-281-1/+1
| | | | | | Noted by Jason Orendorff, SF #520768. Bug fix candidate for 2.1 & 2.2.
* PyGC_Head: Use "long double" instead of "double" as the worst-caseTim Peters2002-02-281-1/+1
| | | | | | | alignment gimmick. David Abrahams notes that the standard "long double" actually requires stricter alignment than "double" on some Tru64 box. On my box and yours <wink>, it's the same, so no harm done on most boxes.
* OS/2 EMX port changes (Include part of patch #450267):Andrew MacIntyre2002-02-262-0/+9
| | | | | | Include/ osdefs.h // EMX promotes Un*x path separators pyport.h
* Change the version string from "2.2+" to "2.3a0". disutils peels offTim Peters2002-02-021-1/+1
| | | | | | the first 3 characters of this string in several places, so for as long as they remain "2.2" it confuses the heck out of attempts to build 2.3 stuff using distutils.
* Got rid of a few more NeXT ifdefs. The last, I think.Jack Jansen2002-02-011-2/+1
|
* Remove the unused & broken PyThread_*_sema() functions and related constants.Fred Drake2002-01-191-7/+0
| | | | This closes SF patch #504215.
* Patch #477752: Drop old-style getargs from curses.Martin v. Löwis2002-01-171-16/+7
|
* Include <unistd.h> in Python.h. Fixes #500924.Martin v. Löwis2002-01-121-0/+3
|
* Implement PyObject_DelItemString. Fixes #498915.Martin v. Löwis2002-01-051-0/+8
|
* Patch #494783: Rename cmp_op enumerators.Martin v. Löwis2002-01-011-3/+3
|
* SF bug #495548: troublesome #define in pyport.hTim Peters2001-12-251-1/+0
| | | | | | | | | Removed the ancient "#define ANY void". Bugfix candidate? Hard call. The bug report claims the existence of this #define creates conflicts with other packages, which is easy to believe. OTOH, some extension authors may still be relying on its presence. I'm afraid you can't win on this one.
* And we start all over again!Barry Warsaw2001-12-211-3/+3
|
* As usual, bump the version number.Barry Warsaw2001-12-141-3/+3
|
* Add helper macro to get the number of free variables for a PyCodeObject.Jeremy Hylton2001-12-131-0/+1
|
* SF bug #491415 PyDict_UpdateFromSeq2() unusedTim Peters2001-12-111-1/+19
| | | | | | | PyDict_UpdateFromSeq2(): removed it. PyDict_MergeFromSeq2(): made it public and documented it. PyDict_Merge() docs: updated to reveal <wink> that the second argument can be any mapping object.
* Patch supplied by Burton Radons for his own SF bug #487390: ModifyingGuido van Rossum2001-12-081-1/+1
| | | | | | | | | | | | | type.__module__ behavior. This adds the module name and a dot in front of the type name in every type object initializer, except for built-in types (and those that already had this). Note that it touches lots of Mac modules -- I have no way to test these but the changes look right. Apologies if they're not. This also touches the weakref docs, which contains a sample type object initializer. It also touches the mmap test output, because the mmap type's repr is included in that output. It touches object.h to put the correct description in a comment.
* PyMethodObject(): Update the comment about im_class based upon aGuido van Rossum2001-12-071-1/+1
| | | | conversation with Robin Dunn in SF patch #490402.
* SF bug #488514: -Qnew needs workTim Peters2001-12-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Big Hammer to implement -Qnew as PEP 238 says it should work (a global option affecting all instances of "/"). pydebug.h, main.c, pythonrun.c: define a private _Py_QnewFlag flag, true iff -Qnew is passed on the command line. This should go away (as the comments say) when true division becomes The Rule. This is deliberately not exposed to runtime inspection or modification: it's a one-way one-shot switch to pretend you're using Python 3. ceval.c: when _Py_QnewFlag is set, treat BINARY_DIVIDE as BINARY_TRUE_DIVIDE. test_{descr, generators, zipfile}.py: fiddle so these pass under -Qnew too. This was just a matter of s!/!//! in test_generators and test_zipfile. test_descr was trickier, as testbinop() is passed assumptions that "/" is the same as calling a "__div__" method; put a temporary hack there to call "__truediv__" instead when the method name is "__div__" and 1/2 evaluates to 0.5. Three standard tests still fail under -Qnew (on Windows; somebody please try the Linux tests with -Qnew too! Linux runs a whole bunch of tests Windows doesn't): test_augassign test_class test_coercion I can't stay awake longer to stare at this (be my guest). Offhand cures weren't obvious, nor was it even obvious that cures are possible without major hackery. Question: when -Qnew is in effect, should calls to __div__ magically change into calls to __truediv__? See "major hackery" at tail end of last paragraph <wink>.
* Stop defining NDEBUG in Python.h, because it can interfere withTim Peters2001-12-041-5/+4
| | | | | extensions that #include Python.h. See (rejected) patch 487634 for more detail. I'll open a new bug report for the rest needed here.
* Fix SF bug #486144: Uninitialized __slot__ vrbl is None.Guido van Rossum2001-12-041-0/+4
| | | | | | | There's now a new structmember code, T_OBJECT_EX, which is used for all __slot__ variables (except __weakref__, which has special behavior anyway). This new code raises AttributeError when the variable is NULL rather than converting NULL to None.
* mysnprintf.c: Massive rewrite of PyOS_snprintf and PyOS_vsnprintf, toTim Peters2001-12-031-5/+0
| | | | | | | | | | | | | | | use wrappers on all platforms, to make this as consistent as possible x- platform (in particular, make sure there's at least one \0 byte in the output buffer). Also document more of the truth about what these do. getargs.c, seterror(): Three computations of remaining buffer size were backwards, thus telling PyOS_snprintf the buffer is larger than it actually is. This matters a lot now that PyOS_snprintf ensures there's a trailing \0 byte (because it didn't get the truth about the buffer size, it was storing \0 beyond the true end of the buffer). sysmodule.c, mywrite(): Simplify, now that PyOS_vsnprintf guarantees to produce a \0 byte.
* 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.
* Removed preprocessor gimmick trying to force use of snprintf emulationTim Peters2001-11-281-8/+6
| | | | before 2.2b1.
* Fix SF bug [ #476852 ] Some bad macros in abstract.hJeremy Hylton2001-11-281-2/+2
| | | | Change macros as requested by Guido
* Bumping version number.Barry Warsaw2001-11-161-2/+2
|
* Add PyObject_CheckReadBuffer(), which returns true if its argumentJeremy Hylton2001-11-091-0/+9
| | | | | | supports the single-segment readable buffer interface. Add documentation for this and other PyObject_XXXBuffer() calls.
* Make the CoreFoundation object _New and _Convert routines available to other ↵Jack Jansen2001-11-051-0/+24
| | | | modules. Idea by Donovan Preston, implementaion by me.
* PyObject_CallFunctionObArgs() ---> PyObject_CallFunctionObjArgs()Fred Drake2001-10-281-4/+4
| | | | PyObject_CallMethodObArgs() ---> PyObject_CallMethodObjArgs()
* SF patch #475657 (Dietmar Schwertberger)Guido van Rossum2001-10-271-3/+4
| | | | | | | | | | | | RISCOS/Makefile: include structseq and weakrefobject; changes to keep command line length below 2048 RISCOS/Modules/riscosmodule.c: typos from the stat structseq patch Include/pyport.h: don't re-#define __attribute__(__x) on RISC OS as it is already defined in c library
* SF bug #475327: type() produces incorrect error msgTim Peters2001-10-271-0/+1
| | | | | | | | | | | | | object.h: Added PyType_CheckExact macro. typeobject.c, type_new(): + Use the new macro. + Assert that the arguments have the right types rather than do incomplete runtime checks "sometimes". + If this isn't the 1-argument flavor() of type, and there aren't 3 args total, produce a "types() takes 1 or 3 args" msg before PyArg_ParseTupleAndKeywords produces a "takes exactly 3" msg.
* Added two new functions to conveniently call functions/methods from C.Fred Drake2001-10-261-5/+23
| | | | | | | PyObject_CallFunctionObArgs() and PyObject_CallMethodObArgs() have the advantage that no format strings need to be parsed. The CallMethod variant also avoids creating a new string object in order to retrieve a method from an object as well.
* Generalize dictionary() to accept a sequence of 2-sequences. At theTim Peters2001-10-261-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | outer level, the iterator protocol is used for memory-efficiency (the outer sequence may be very large if fully materialized); at the inner level, PySequence_Fast() is used for time-efficiency (these should always be sequences of length 2). dictobject.c, new functions PyDict_{Merge,Update}FromSeq2. These are wholly analogous to PyDict_{Merge,Update}, but process a sequence-of-2- sequences argument instead of a mapping object. For now, I left these functions file static, so no corresponding doc changes. It's tempting to change dict.update() to allow a sequence-of-2-seqs argument too. Also changed the name of dictionary's keyword argument from "mapping" to "x". Got a better name? "mapping_or_sequence_of_pairs" isn't attractive, although more so than "mosop" <wink>. abstract.h, abstract.tex: Added new PySequence_Fast_GET_SIZE function, much faster than going thru the all-purpose PySequence_Size. libfuncs.tex: - Document dictionary(). - Fiddle tuple() and list() to admit that their argument is optional. - The long-winded repetitions of "a sequence, a container that supports iteration, or an iterator object" is getting to be a PITA. Many months ago I suggested factoring this out into "iterable object", where the definition of that could include being explicit about generators too (as is, I'm not sure a reader outside of PythonLabs could guess that "an iterator object" includes a generator call). - Please check my curly braces -- I'm going blind <0.9 wink>. abstract.c, PySequence_Tuple(): When PyObject_GetIter() fails, leave its error msg alone now (the msg it produces has improved since PySequence_Tuple was generalized to accept iterable objects, and PySequence_Tuple was also stomping on the msg in cases it shouldn't have even before PyObject_GetIter grew a better msg).
* SF patch #474590 -- RISC OS supportGuido van Rossum2001-10-241-0/+4
|
* Check for HP/UX curses problems. Define _XOPEN_SOURCE_EXTENDED andMartin v. Löwis2001-10-241-0/+11
| | | | | | STRICT_SYSV_CURSES when compiling curses module on HP/UX. Generalize access to _flags on systems where WINDOW is opaque. Fixes bugs #432497, #422265, and the curses parts of #467145 and #473150.
generated by cgit v0.12 at 2024-11-14 16:32:01 (GMT)