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

[Eric Snow]

On Tue, Mar 29, 2011 at 12:47 PM, Guido van Rossum <guido at python.org> wrote:

> On Tue, Mar 29, 2011 at 11:30 AM, Eric Snow <ericsnowcurrently at gmail.com>
> wrote:
> > 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.
>
> Well people already do this using ctypes...
>
> Haven't used them myself yet.  So you can use them to expose all of the
C-API?  Cool!


> > 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!
>
> Any or all of the above, probably, depending on the specific API
> you're considering...
>
> I figured as much. :(  Unless I have missed a doc somewhere, it seems like
it is a process of time to get a feel for what belongs in Python and what
doesn't.


> You seem to have ignored my suggestion to think about how this would
> work in other Python interpreters.
>
> I really am not sure.  It seems like there are already several modules in
the stdlib that are implementation specific, like dis.  This would fall in
that category.  But maybe we are trying to lock or eliminate that category?


> Also many of the C APIs have subtle reference count behavior -- you
> don't want to have to worry about refcounting bugs *in your Python
> code*.
>
> That is one that I definitely hadn't thought about.  I am totally with you
on that.  Chalk that up to one more obstacle, though I suppose you would
have to deal with it with a ctypes approach as well.

--
> --Guido van Rossum (python.org/~guido)
>

I don't want this discussion to be an abuse of people's time to the benefit
of my understanding, but I am finding these threads to be very insightful.
 So, thanks!

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110329/228c56f1/attachment.html>