[Patches] [ python-Patches-448305 ] Additions to the C API
noreply@sourceforge.net
noreply@sourceforge.net
Thu, 09 Aug 2001 14:37:32 -0700
Patches item #448305, was opened at 2001-08-05 19:11
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470
Category: core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: Additions to the C API
Initial Comment:
I'm not sure a PEP is required for this patch, but these functions are pre-requisiste for two other
PEP in the pipe...
I have not always had easy access to news posting, so I'll be the happier this can go through
without all the PEP overhead, otherwise, I'll try to follow up the PEP.
I'm submitting this as a PEP in the same time, to the Director of PEP Affairs, as indicated in the
PEP
meta PEP 000 (barry), with a reference to this patch (file attached).
Frederic Giacometti
---------------------------
PEP XXX: Additions to the C API
fred@arakne.com (Frederic Giacometti)
Abstract
This PEP defines a couple of C functions.
The first two functions are for raising exceptions with multiple arguments;
the third one is for calling a method when an arg tuple is given;
and the other ones programmatically define sys.path
and the optimization level in embedded python context,
before initialization of the global Python engine.
Copyright: This document is published under the Open Publication License.
Specification:
PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args)
Raise the exception created by applying args to exctype.
This is equivalent to the Python expression
raise apply( exctype, args).
Always set the error state and return NULL.
PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...)
This function is similar to PyErr_RaiseArgs(),
but defines the arguments using the same convention as
Py_BuildValue().
Always set the error state and return NULL.
PyObject* PyObject_CallMethodArgs( PyObject* o,
char const* method, PyObject* args)
Call the method named 'method' with arguments given by the tuple args,
using for args the same convention as PyObject_CallObject().
This is the equivalent of the Python expression
o.method( args).
Note that special method names, such as __add__(),
__getitem__(), and so on are not supported. The specific
abstract-object routines for these must be used.
void Py_SetPythonPath( char const* path)
This function should be called before
Py_Initialize()
is called for the first time, if it is called at all.
It defines the PYTHONPATH value to be used by the interpreter.
Calling Py_SetPythonPath() will override the
PYTHONPATH value from the environment.
The argument should be NULL, or point to a zero-terminated character string
which will not change for the duration of the program's execution.
char const* Py_GetPythonPath()
If Py_SetPythonPath()
was never called, getenv( "PYTHONPATH") is returned,
otherwise the argument of Py_SetPythonPath() is returned.
The returned string points into static storage.
void Py_SetOptimizeLevel( int level)
This function should be called before
Py_Initialize()
is called for the first time.
Legal optimization levels are listed below.
\begin{tableii}{c|l}{character}{Character}{Meaning}
\lineii{0}{No optimization (use \code{.pyc} files by default)}
\lineii{1}{Same as \code{python -O}}
\lineii{2}{Same as \code{python -OO}}
\end{tableii}
int Py_GetOptimizeLevel()
Return the interpreter optimization level.
Reference Implementation:
See attached patch (concatenation of 2 patch files).
----------------------------------------------------------------------
>Comment By: Frederic Giacometti (giacometti)
Date: 2001-08-09 14:37
Message:
Logged In: YES
user_id=93657
1) Patch for PyErr_Raise:
I manually edited the patch file, since I had the ImportNotFound changes with it.
The entire patch is in cdiff file attached to
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448488&group_id=5470
Meanwhile, I'm pasting below the missing section.
2) I'm going to make a quick search on the existing base for replacement opportunities.
3) CallMethodArgs vs. CallMethodArgs with keywords:
The main reason is that the implementation relies on the exsiting PyObject_CallObject function, with does
not take keyword args...
However, your remark is relevant, and two other functions would be needed to complete the call interface:
PyObject_CallObjectWithKW and PyObject_CallMethodArgsWithKW...
I'd say that use of keyword arg from the C API is unusual; since I've never needed them, I haven't
implemented them...
Index: Python/errors.c
===================================================================
RCS file: /cvs/python/Python/Python/errors.c,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 errors.c
*** Python/errors.c 2001/05/27 15:36:36 1.1.1.1
--- Python/errors.c 2001/06/05 16:11:16
***************
*** 514,519 ****
--- 514,571 ----
}
+ PyObject* PyErr_RaiseArgs( PyObject* exctype, PyObject* args)
+ {
+ PyObject* exception;
+ exception = PyObject_CallObject( exctype, args);
+ if (! exception) return NULL;
+ PyErr_SetObject( exctype, exception);
+ return NULL;
+ }
+
+ PyObject* PyErr_Raise( PyObject* exctype, char const* format, ...)
+ {
+ PyObject* args = NULL, *result = NULL;
+ va_list va;
+
+ va_start( va, format);
+ args = format ? Py_VaBuildValue( (char*)format, va) : PyTuple_New(0);
+ va_end(va);
+
+ if (! args) goto Finally;
+ if (! PyTuple_Check( args)) {
+ PyObject* newargs;
+ newargs = PyTuple_New( 1);
+ if (! newargs) goto Finally;
+ PyTuple_SET_ITEM( newargs, 0, args);
+ args = newargs;
+ }
+
+ result = PyErr_RaiseArgs( exctype, args);
+ Finally:
+ Py_XDECREF(args);
+ return result;
+ }
+
PyObject *
PyErr_NewException(char *name, PyObject *base, PyObject *dict)
{
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2001-08-07 22:16
Message:
Logged In: YES
user_id=21627
It seems that your patch is somewhat confused: It contains
fragments of the SetPythonPath code, but fails to include
the implementation of PyErr_Raise[Args].
I think the patch should also identify the places in the
code that could make use of the offered simplifications
(and change them to the new API), to get an impression of
how general this API is. I'm +1 on the _Raise functions
and -0 on the CallMethodArgs (why does it not support
keyword arguments?).
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=448305&group_id=5470