summaryrefslogtreecommitdiffstats
path: root/Python
Commit message (Collapse)AuthorAgeFilesLines
* PyErr_NormalizeException()Jeremy Hylton2001-09-261-1/+12
| | | | | | | | | | | | | | | | | | If a new exception occurs while an exception instance is being created, try harder to make sure there is a traceback. If the original exception had a traceback associated with it and the new exception does not, keep the old exception. Of course, callers to PyErr_NormalizeException() must still be prepared to have tb set to NULL. XXX This isn't an ideal solution, but it's better than no traceback at all. It occurs if, for example, the exception occurs when the call to the constructor fails before any Python code is executed. Guido suggests that it there is Python code that was about to be executed -- but wasn't, say, because it was called with the wrong number of arguments -- then we should point at the first line of the code object anyway.
* Prevent a NULL pointer from being pushed onto the stack.Jeremy Hylton2001-09-261-1/+5
| | | | | | | | | | | | It's possible for PyErr_NormalizeException() to set the traceback pointer to NULL. I'm not sure how to provoke this directly from Python, although it may be possible. The error occurs when an exception is set using PyErr_SetObject() and another exception occurs while PyErr_NormalizeException() is creating the exception instance. XXX As a result of this change, it's possible for an exception to occur but sys.last_traceback to be left undefined. Not sure if this is a problem.
* Don't swap the arguments to PyFrame_BlockSetup when recreating the recentlyThomas Wouters2001-09-241-2/+2
| | | | | | | | | popped frame-block. What an embarrassing bug! Especially for Jeremy, since he accepted the patch :-) This fixes SF bugs #463359 and #462937, and possibly other, *very* obscure bugs with very deeply nested loops that continue the loop and then break out of it or raise an exception.
* Add optional docstrings to member descriptors. For backwardsGuido van Rossum2001-09-204-213/+235
| | | | | | | | | | | | | | | 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.
* Add support for restricting access based on restricted execution mode.Guido van Rossum2001-09-171-5/+16
| | | | | | Renamed the 'readonly' field to 'flags' and defined some new flag bits: READ_RESTRICTED and WRITE_RESTRICTED, as well as a shortcut RESTRICTED that means both.
* Supply code objects a new-style tp_members slot and tp_getattr impl.Jeremy Hylton2001-09-141-16/+34
| | | | | The chief effects are to make dir() do something useful and supply them with an __class__.
* Get rid of builtin_open() entirely (the C code and docstring, not theTim Peters2001-09-131-20/+3
| | | | | builtin function); Guido pointed out that it could be just another name in the __builtin__ dict for the file constructor now.
* _PyBuiltin_Init(): For clarity, macroize this purely repetitive code.Tim Peters2001-09-131-49/+25
|
* Admit that we'll never add the args for a "call" event to the profileFred Drake2001-09-131-3/+0
| | | | | | and trace functions; this now declares that None will be passed for the "call" event. This closes SF bug/suggestion #460315.
* SF bug [#460467] file objects should be subclassable.Tim Peters2001-09-131-22/+13
| | | | Preliminary support. What's here works, but needs fine-tuning.
* build_class(): one more (hopefully the last) step on the way toGuido van Rossum2001-09-121-14/+21
| | | | | | | | | backwards compatibility. When using the class of the first base as the metaclass, use its __class__ attribute in preference over its ob_type slot. This ensures that we can still use classic classes as metaclasse, as shown in the original "Metaclasses" essay. This also makes all the examples in Demo/metaclasses/ work again (maybe these should be turned into a test suite?).
* Replaced PyMac_FullPath by PyMac_FullPathname, which has an extra 'length'Jack Jansen2001-09-101-1/+41
| | | | | | parameter for the return string (as unix pathnames are not limited by the 255 char pstring limit). Implemented the function for MachO-Python, where it returns unix pathnames.
* Improve threading on Solaris, according to SF patch #460269, submittedGuido van Rossum2001-09-101-3/+8
| | | | | | | | | | by bbrox@bbrox.org / lionel.ulmer@free.fr. This adds a configure check and if all goes well turns on the PTHREAD_SCOPE_SYSTEM thread attribute for new threads. This should remove the need to add tiny sleeps at the start of threads to allow other threads to be scheduled.
* Fix core dump in PyArg_ParseTuple() with Unicode arguments.Jeremy Hylton2001-09-101-15/+17
| | | | | | | | | Reported by Fredrik Lundh on python-dev. The conversimple() code that handles Unicode arguments and converts them to the default encoding now calls converterr() with the original Unicode argument instead of the NULL returned by the failed encoding attempt.
* SF bug [#458941] Looks like a unary minus bug.Tim Peters2001-09-071-16/+49
| | | | | | | | | | com_factor(): when a unary minus is attached to a float or imaginary zero, don't optimize the UNARY_MINUS opcode away: the const dict can't distinguish between +0.0 and -0.0, so ended up treating both like the first one added to it. Optimizing UNARY_PLUS away isn't a problem. (BTW, I already uploaded the 2.2a3 Windows installer, and this isn't important enough to delay the release.)
* Rename 'getset' to 'property'.Guido van Rossum2001-09-061-2/+2
|
* Patch #455231: Support ELF properly on OpenBSD.Martin v. Löwis2001-09-051-1/+1
|
* builtin_execfile(): initialize another local that the GCC on leroyGuido van Rossum2001-09-051-1/+1
| | | | found it necessary to warn about.
* At Guido's suggestion, here's a new C API function, PyObject_Dir(), likeTim Peters2001-09-041-137/+1
| | | | __builtin__.dir(). Moved the guts from bltinmodule.c to object.c.
* Move call_trace(..., PyTrace_CALL, ...) call to top of eval_frame. ThatNeil Schemenauer2001-09-041-35/+35
| | | | | way it's called each time a generator is resumed. The tracing of normal functions should be unaffected by this change.
* builtin_dir(): Treat classic classes like types. Use PyDict_Keys insteadTim Peters2001-09-041-17/+20
| | | | | | | | | | | | | | of PyMapping_Keys because we know we have a real dict. Tolerate that objects may have an attr named "__dict__" that's not a dict (Py_None popped up during testing). test_descr.py, test_dir(): Test the new classic-class behavior; beef up the new-style class test similarly. test_pyclbr.py, checkModule(): dir(C) is no longer a synonym for C.__dict__.keys() when C is a classic class (looks like the same thing that burned distutils! -- should it be *made* a synoym again? Then it would be inconsistent with new-style class behavior.).
* Make dir() wordier (see the new docstring). The new behavior is a mixedTim Peters2001-09-031-53/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | bag. It's clearly wrong for classic classes, at heart because a classic class doesn't have a __class__ attribute, and I'm unclear on whether that's feature or bug. I'll repair this once I find out (in the meantime, dir() applied to classic classes won't find the base classes, while dir() applied to a classic-class instance *will* find the base classes but not *their* base classes). Please give the new dir() a try and see whether you love it or hate it. The new dir([]) behavior is something I could come to love. Here's something to hate: >>> class C: ... pass ... >>> c = C() >>> dir(c) ['__doc__', '__module__'] >>> The idea that an instance has a __doc__ attribute is jarring (of course it's really c.__class__.__doc__ == C.__doc__; likewise for __module__). OTOH, the code already has too many special cases, and dir(x) doesn't have a compelling or clear purpose when x isn't a module.
* Added glue routine for PyMac_BuildFSSpec, PyMac_GetFSRef and PyMac_BuildFSRef.Jack Jansen2001-09-011-0/+4
| | | | Moved the declarations to pymactoolbox.h.
* Add warning mode for classic division, almost exactly as specified inGuido van Rossum2001-08-311-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PEP 238. Changes: - add a new flag variable Py_DivisionWarningFlag, declared in pydebug.h, defined in object.c, set in main.c, and used in {int,long,float,complex}object.c. When this flag is set, the classic division operator issues a DeprecationWarning message. - add a new API PyRun_SimpleStringFlags() to match PyRun_SimpleString(). The main() function calls this so that commands run with -c can also benefit from -Dnew. - While I was at it, I changed the usage message in main() somewhat: alphabetized the options, split it in *four* parts to fit in under 512 bytes (not that I still believe this is necessary -- doc strings elsewhere are much longer), and perhaps most visibly, don't display the full list of options on each command line error. Instead, the full list is only displayed when -h is used, and otherwise a brief reminder of -h is displayed. When -h is used, write to stdout so that you can do `python -h | more'. Notes: - I don't want to use the -W option to control whether the classic division warning is issued or not, because the machinery to decide whether to display the warning or not is very expensive (it involves calling into the warnings.py module). You can use -Werror to turn the warnings into exceptions though. - The -Dnew option doesn't select future division for all of the program -- only for the __main__ module. I don't know if I'll ever change this -- it would require changes to the .pyc file magic number to do it right, and a more global notion of compiler flags. - You can usefully combine -Dwarn and -Dnew: this gives the __main__ module new division, and warns about classic division everywhere else.
* When re-writing a factor containing a unary negation of a literal, onlyFred Drake2001-08-301-0/+3
| | | | | affect nodes without another operator. This was causing negated exponentiations to drop the exponentiation. This closes SF bug #456756.
* Do the int inlining only if the type is really an int, not wheneverGuido van Rossum2001-08-301-6/+9
| | | | | PyInt_Check() succeeds. That returns true for subtypes of int, which may override __add__ or __sub__.
* fix for part of bug #453523: disable unmarshalling of code objects inMichael W. Hudson2001-08-301-1/+7
| | | | restricted execution mode.
* Removed unreachable goto statement to silence SGI compiler.Sjoerd Mullender2001-08-301-1/+0
|
* Removed some unreachable break statements to silence SGI compiler.Sjoerd Mullender2001-08-301-3/+0
|
* Add a new function imp.lock_held(), and use it to skip test_threaded_importTim Peters2001-08-301-0/+19
| | | | when that test is doomed to deadlock.
* SF bug [#456252] Python should never stomp on [u]intptr_t.Tim Peters2001-08-291-2/+2
| | | | | | | | | | | pyport.h: typedef a new Py_intptr_t type. DELICATE ASSUMPTION: That HAVE_UINTPTR_T implies intptr_t is available as well as uintptr_t. If that turns out not to be true, things must get uglier (C99 wants both, so I think it's an assumption we're *likely* to get away with). thread_nt.h, PyThread_start_new_thread: MS _beginthread is documented as returning unsigned long; no idea why uintptr_t was being used. Others: Always use Py_[u]intptr_t, never [u]intptr_t directly.
* GUSI on the Mac creates threads with a default stack size of 20KB, which isJack Jansen2001-08-291-1/+21
| | | | | not enough for Python. Increased the stacksize to a (somewhat arbitrary) 64KB.
* marshal.c r_long64: When reading a TYPE_INT64 value on a box with 32-bitTim Peters2001-08-291-12/+24
| | | | ints, convert to PyLong (rather than throwing away the high-order 32 bits).
* The "O!" format code should implement an isinstance() testGuido van Rossum2001-08-281-1/+1
| | | | rather than a type equality test.
* If an integer constant can't be generated from an integer literalJeremy Hylton2001-08-271-5/+2
| | | | because of overflow, generate a long instead.
* Refer to the toolbox modules by their official name (Carbon.AE), not the ↵Jack Jansen2001-08-271-59/+59
| | | | internal name (_AE). This can slow things down (once) but it's the only way I can get things to work on OSX, OS9 dynamically loaded and OS9 frozen.
* PyErr_Format(): Factor out most of this code intoBarry Warsaw2001-08-241-114/+1
| | | | | PyString_FromFormat() since it's much more generally useful than just for exceptions.
* Add 'super' builtin type.Guido van Rossum2001-08-241-0/+3
|
* Add new built-in type 'getset' (PyGetSet_Type).Guido van Rossum2001-08-231-0/+3
| | | | This implements the 'getset' class from test_binop.py.
* Mac toolbox modules have gotten an _ prepended to their name.Jack Jansen2001-08-231-58/+58
|
* When an inlined operation on two small ints causes overflow, don'tGuido van Rossum2001-08-231-32/+24
| | | | | raise the exception here -- call the generic function (which may convert the arguments to long and try again).
* Introduce OverflowWarning -- to be issued when short int operationsGuido van Rossum2001-08-231-0/+7
| | | | are overflowing and a long int operation is substituted.
* Fix SF bug [ #450245 ] Error in parsing future stmtsJeremy Hylton2001-08-201-3/+18
| | | | | | | | | Check return value from future_parse() in for loop for file_input to accomodate multiple future statements on separate lines. Add several comments explaining how the code works. Remove out-dated XXX comment.
* Fix SF bug #443600:Guido van Rossum2001-08-181-15/+46
| | | | | | | | Change to get/set/del slice operations so that if the object doesn't support slicing, *or* if either of the slice arguments is not an int or long, we construct a slice object and call the get/set/del item operation instead. This makes it possible to design classes that support slice arguments of non-integral types.
* Fix for bug [#452230] future division isn't propagated.Tim Peters2001-08-171-1/+8
| | | | | | | builtin_eval wasn't merging in the compiler flags from the current frame; I suppose we never noticed this before because future division is the first future-feature that can affect expressions (nested_scopes and generators had only statement-level effects).
* A fiddled version of the rest of Michael Hudson's SF patchTim Peters2001-08-171-8/+26
| | | | | #449043 supporting __future__ in simulated shells which implements PEP 264.
* ceval, PyEval_MergeCompilerFlags: wasn't merging in theTim Peters2001-08-171-6/+3
| | | | | | | | | | | | | | CO_FUTURE_DIVISION flag. Redid this to use Jeremy's PyCF_MASK #define instead, so we dont have to remember to fiddle individual feature names here again. pythonrun.h: Also #define a PyCF_MASK_OBSOLETE mask. This isn't used yet, but will be as part of the PEP 264 implementation (compile() mustn't raise an error just because old code uses a flag name that's become obsolete; a warning may be appropriate, but not an error; so compile() has to know about obsolete flags too, but nobody is going to remember to update compile() with individual obsolete flag names across releases either -- i.e., this is the flip side of PyEval_MergeCompilerFlags's oversight).
* Patch #445762: Support --disable-unicodeMartin v. Löwis2001-08-177-14/+80
| | | | | | | | - Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled - check for Py_USING_UNICODE in all places that use Unicode functions - disables unicode literals, and the builtin functions - add the types.StringTypes list - remove Unicode literals from most tests.
* Patch #427190: Implement and use METH_NOARGS and METH_O.Martin v. Löwis2001-08-163-168/+138
|
* Oops. Two fixes for SF bug #422004 are not needed. :-)Guido van Rossum2001-08-161-1/+0
|
generated by cgit v0.12 at 2024-11-15 23:44:20 (GMT)