Commit Graph

276 Commits

Author SHA1 Message Date
Neil Schemenauer
6c0f20088f Move call_trace(..., PyTrace_CALL, ...) call to top of eval_frame. That
way it's called each time a generator is resumed.  The tracing of normal
functions should be unaffected by this change.
2001-09-04 19:03:35 +00:00
Guido van Rossum
46add98758 Do the int inlining only if the type is really an int, not whenever
PyInt_Check() succeeds.  That returns true for subtypes of int, which
may override __add__ or __sub__.
2001-08-30 16:06:23 +00:00
Sjoerd Mullender
2f38f81fec Removed some unreachable break statements to silence SGI compiler. 2001-08-30 14:05:20 +00:00
Guido van Rossum
87780dfa97 When an inlined operation on two small ints causes overflow, don't
raise the exception here -- call the generic function (which may
convert the arguments to long and try again).
2001-08-23 02:58:07 +00:00
Guido van Rossum
50d756e262 Fix SF bug #443600:
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.
2001-08-18 17:43:36 +00:00
Tim Peters
e2c18e90da ceval, PyEval_MergeCompilerFlags: wasn't merging in the
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).
2001-08-17 20:47:47 +00:00
Martin v. Löwis
e3eb1f2b23 Patch #427190: Implement and use METH_NOARGS and METH_O. 2001-08-16 13:15:00 +00:00
Jeremy Hylton
910d7d46dc Remove much dead code from ceval.c
The descr changes moved the dispatch for calling objects from
call_object() in ceval.c to PyObject_Call() in abstract.c.
call_object() and the many functions it used in ceval.c were no longer
used, but were not removed.

Rename meth_call() as PyCFunction_Call() so that it can be called by
the CALL_FUNCTION opcode in ceval.c.

Also, fix error message that referred to PyEval_EvalCodeEx() by its
old name eval_code2().  (I'll probably refer to it by its old name,
too.)
2001-08-12 21:52:24 +00:00
Jeremy Hylton
b857ba261f Refactor future feature handling
Replace uses of PyCF_xxx with CO_xxx.

Replace individual feature slots in PyFutureFeatures with single
bitmask ff_features.

When flags must be transfered among the three parts of the interpreter
that care about them -- the pythonrun layer, the compiler, and the
future feature parser -- can simply or (|) the definitions.
2001-08-10 21:41:33 +00:00
Guido van Rossum
4668b000a1 Implement PEP 238 in its (almost) full glory.
This introduces:

- A new operator // that means floor division (the kind of division
  where 1/2 is 0).

- The "future division" statement ("from __future__ import division)
  which changes the meaning of the / operator to implement "true
  division" (where 1/2 is 0.5).

- New overloadable operators __truediv__ and __floordiv__.

- New slots in the PyNumberMethods struct for true and floor division,
  new abstract APIs for them, new opcodes, and so on.

I emphasize that without the future division statement, the semantics
of / will remain unchanged until Python 3.0.

Not yet implemented are warnings (default off) when / is used with int
or long arguments.

This has been on display since 7/31 as SF patch #443474.

Flames to /dev/null.
2001-08-08 05:00:18 +00:00
Tim Peters
6d6c1a35e0 Merge of descr-branch back into trunk. 2001-08-02 04:15:00 +00:00
Tim Peters
5ba5866281 Part way to allowing "from __future__ import generators" to communicate
that info to code dynamically compiled *by* code compiled with generators
enabled.  Doesn't yet work because there's still no way to tell the parser
that "yield" is OK (unlike nested_scopes, the parser has its fingers in
this too).
Replaced PyEval_GetNestedScopes by a more-general
PyEval_MergeCompilerFlags.  Perhaps I should not have?  I doubted it was
*intended* to be part of the public API, so just did.
2001-07-16 02:29:45 +00:00
Neil Schemenauer
f8c7c20ba5 GC for generator objects. 2001-07-12 13:27:49 +00:00
Fred Drake
9e3ad78444 This change adjusts the profiling/tracing support so that the common
path (with no profile/trace function) through eval_code2() and
eval_frame() avoids several checks.

In the common cases of calls, returns, and exception propogation,
eval_code2() and eval_frame() used to test two values in the
thread-state: the profiling function and the tracing function.  With
this change, a flag is set in the thread-state if either of these is
active, allowing a single check to suffice when both are NULL.  This
also simplifies the code needed when either function is in use but is
already active (to avoid profiling/tracing the profiler/tracer); the
flag is set to 0 when the profile/trace code is entered, allowing the
same check to suffice for "already in the tracer" for call/return/
exception events.
2001-07-03 23:39:52 +00:00
Fred Drake
5755ce693d Revise the interface to the profiling and tracing support for the
Python interpreter.

This change adds two new C-level APIs:  PyEval_SetProfile() and
PyEval_SetTrace().  These can be used to install profile and trace
functions implemented in C, which can operate at much higher speeds
than Python-based functions.  The overhead for calling a C-based
profile function is a very small fraction of a percent of the overhead
involved in calling a Python-based function.

The machinery required to call a Python-based profile or trace
function been moved to sysmodule.c, where sys.setprofile() and
sys.setprofile() simply become users of the new interface.

As a side effect, SF bug #436058 is fixed; there is no longer a
_PyTrace_Init() function to declare.
2001-06-27 19:19:46 +00:00
Tim Peters
e77f2e2798 gen_getattr: make the gi_running and gi_frame members discoverable (but
not writable -- too dangerous!) from Python code.
2001-06-26 22:24:51 +00:00
Tim Peters
d8e1c9e177 Add "gi_" (generator-iterator) prefix to names of genobject members.
Makes it much easier to find references via dumb editor search (former
"frame" in particular was near-hopeless).
2001-06-26 20:58:58 +00:00
Tim Peters
ad1a18b78e Change the semantics of "return" in generators, as discussed on the
Iterators list and Python-Dev; e.g., these all pass now:

def g1():
    try:
        return
    except:
        yield 1
assert list(g1()) == []

def g2():
    try:
        return
    finally:
        yield 1
assert list(g2()) == [1]

def g3():
    for i in range(3):
        yield None
    yield None
assert list(g3()) == [None] * 4

compile.c:  compile_funcdef and com_return_stmt:  Just van Rossum's patch
to compile the same code for "return" regardless of function type (this
goes back to the previous scheme of returning Py_None).

ceval.c:  gen_iternext:  take a return (but not a yield) of Py_None as
meaning the generator is exhausted.
2001-06-23 06:19:16 +00:00
Tim Peters
5eb4b87ae6 gen_iternext(): Don't assume that the current thread state's frame is
not NULL.  I don't think it can be NULL from Python code, but if using
generators via the C API I expect a NULL frame is possible.
2001-06-23 05:47:56 +00:00
Tim Peters
8c96369513 PyFrameObject: rename f_stackbottom to f_stacktop, since it points to
the next free valuestack slot, not to the base (in America, stacks push
and pop at the top -- they mutate at the bottom in Australia <winK>).
eval_frame():  assert that f_stacktop isn't NULL upon entry.
frame_delloc():  avoid ordered pointer comparisons involving f_stacktop
when f_stacktop is NULL.
2001-06-23 05:26:56 +00:00
Tim Peters
d6d010b874 Teach the UNPACK_SEQUENCE opcode how to tease an iterable object into
giving up the goods.
NEEDS DOC CHANGES
2001-06-21 02:49:55 +00:00
Neil Schemenauer
2b13ce8317 Try to avoid creating reference cycles involving generators. Only keep a
reference to f_back when its really needed.  Do a little whitespace
normalization as well.  This whole file is a big war between tabs and spaces
but now is probably not the time to reindent everything.
2001-06-21 02:41:10 +00:00
Tim Peters
6302ec63fc gen_iternext(): repair subtle refcount problem.
NeilS, please check!  This came from staring at your genbug.py, but I'm
not sure it plugs all possible holes.  Without this, I caught a
frameobject refcount going negative, and it was also the cause (in debug
build) of _Py_ForgetReference's attempt to forget an object with already-
NULL _ob_prev and _ob_next pointers -- although I'm still not entirely
sure how!  Part of the difficulty is that frameobjects are stored on a
free list that gets recycled very quickly, so if there's a stray pointer
to one of them it never looks like an insane frameobject (never goes
trough the free() mangling MS debug forces, etc).
2001-06-20 06:57:32 +00:00
Neil Schemenauer
43afb24c30 Remove unused code. 2001-06-20 00:39:28 +00:00
Tim Peters
5ca576ed0a Merging the gen-branch into the main line, at Guido's direction. Yay!
Bugfix candidate in inspect.py:  it was referencing "self" outside of
a method.
2001-06-18 22:08:13 +00:00