On 12/2/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I'd love to see this idea explored; it sounds like it might well be
the right solution. (It's also an extension of the "separate tool for
conversion" idea that I floated earlier.)
One requirement: it should be possible to resume development and the
preprocessor at any time. I don't like tools that generate code once
which you then continue to develop manually. (Numeric Python's history
has a good anti-pattern example of this.)
So you are basically saying you want the preprocessor step to be lightweight
enough that you always develop with the file before the preprocessor is run
instead of with some generated file, right?
Regardless, one could take a Pyrex bent on this and having Python-like
method declarations but have C as the code body::
class SomeType() {
def __str__(self:PyObject) -> PyObject {
...
}
def fxn(self:PySomeTypeObject, arg1:int, arg2:PyObject,
arg3=NULL:char*) -> PyObject {
...
}
}
That should be enough information to fill in the struct fields and
auto-generate the ParseTuple() call and variable names properly. It also
shouldn't be too expensive to parse and thus would allow developers to work
directly with this file and not any generated C code file.
Question is whether this is what you and /F had in mind and if you want to
go so far as to use Python-like syntax (I only used curly braces to make it
blatently obvious it was not actual Python code) or if I am misunderstanding
what you two are suggesting.
-Brett
On 12/2/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Marcin 'Qrczak' Kowalczyk wrote:
>
> > "Guido van Rossum" <[EMAIL PROTECTED]> writes:
> >
> >> - Can't we require a C99 compiler and use C99 struct initialization?
> >> Then the table lines could look like
> >>
> >> tp_new = Noddy_new,
> >> tp_init = Noddy_init,
> >
> > The C99 syntax is:
> >
> > .tp_new = Noddy_new,
> > .tp_init = Noddy_init,
>
> I'm beginning to wonder if a preprocessor isn't the right way to get
> around both the syntax issues related to type objects, and also a bunch
> of other issues that keep cropping up if you're doing serious extension
> development (better code generation for ParseTuple is one of those). a
> preprocessor would also give us more leeway to tweak the Python/C glue
> layer in future releases.
>
> if done right, the preprocessor would only be required during module
> development; not by people building C extensions.
>
> </F>
>
> _______________________________________________
> Python-3000 mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/brett%40python.org
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
