[Python-ideas] {Python-ideas] C-API exposure

[Eric Snow]

Certainly neither the new builtins nor the "pure" Python extrapolations
would be portable.  And I wasn't suggesting that they be exposed in the
builtins module, but rather in their own module.  By nature they would be
implementation specific.  However, they would be as insightful as poking
around the C-API is (which I found to be very), but in Python.

As far as Cython goes, I am not terribly familiar with it.  However, I think
it is a sort of opposite.  Cython seems to push Python down into C.  The
C-API builtins would push the C into Python (that doesn't sound good).

Regardless, I think doing this would take too much work to be worth it.  But
I did want to get the idea out there.  I starting thinking about this when I
was messing around with exec_closure.    While it has proven superfluous,
working on it exposed me to all the pieces in the C-API that do not have
counterparts in Python.  Things like cell objects.  There are things in
there that you can emulate, but not in an explicit way (like
PyEval_EvalCodeEx).

It seems like as time has gone by, more of the internals have been exposed,
like the AST module, the types module, metaclasses, the dis module, and
others.  Certainly these are not run-of-the-mill modules, and neither would
this be.  Those others have come about as needs have presented.  I expect
that will continue to be the case.  The idea here was to skip to the chase
and just expose the whole API.

One of my key questions is, what are the dangers in doing so?  Security?
 Risk of fostering hacks?  More people relying on implementation specific
details?  Enabling code that is incongrous with the Python vision?  These
are questions to which I am trying to find answers as I dive into the
python-dev world.  I appreciate the feedback by the way!

-eric


On Tue, Mar 29, 2011 at 11:53 AM, Guido van Rossum <guido at python.org> wrote:

> On Tue, Mar 29, 2011 at 10:47 AM, Eric Snow <ericsnowcurrently at gmail.com>
> wrote:
> > As I have been toying around with a few things, I have noticed that the
> > C-API provides a lot more functionality than is exposed in Python.  Much
> of
> > the functionality can be reproduced one way or another.  However, I was
> > wondering if it would be feasible (and tractable) to expose every bit of
> the
> > C-API in python.
>
> > If it happened, then everything in there could be written in pure python
> > relative to all the other exposed pieces.  This would allow easier
> > prototyping of new language features.  It would not be practical from a
> > performance standpoint for most stuff, but it would help people
> understand
> > how python works underneath.  As well, exposing all the pieces would
> provide
> > a way to test the C-API completely from pure python.
>
> > While I see several good things, I also see the size of the task.  Just
> > exposing the C-API would be a feat.  On top of that, emulating the
> innards
> > of each piece in pure python using the other exposed pieces would be a
> big
> > job.  Would it be worth it?  Would it expose things we actually don't
> want
> > exposed?
>
> > I think it would be really cool, but half the time that is a good warning
> > sign.
>
> Well, would it really be pure Python? You should carefully consider
> how portable that "pure Python" code you propose to write would be to
> alternate Python implementations like Jython, IronPython or PyPy.
>
> It also sounds like you're about to independently discover Cython.
>
> Finally, can you be specific? Do you have some examples of C-APIs that
> could be exposed? What would be gained?
>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110329/272fabdf/attachment.html>