[Python-ideas] discouraging direct use of the C-API

[M.-A. Lemburg]

On 07.05.2015 00:19, Eric Snow wrote:
> On Wed, May 6, 2015 at 3:41 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Python without the C extensions would hardly have had the
>> success it has. It is widely known as perfect language to
>> glue together different systems and provide integration.
>>
>> Deprecating the C API would mean that you deprecate all
>> those existing C extensions together with the C API.
> 
> As Donald noted, I'm not suggesting that the C-API be deprecated.  I
> was careful in calling it "discouraging direct use of the C-API". :)

Looks like that didn't work out when I read your suggestion :-)
I'd expect a big red warning on all C API pages to have
a similar effect on others.

>> This can hardly be in the interest of Python's quest for
>> world domination :-)
>>
>> BTW: What can be more drastic than deprecating the Python C API ?
>> There are certainly better ways to evolve an API than getting
>> rid of it.
> 
> I'd like to hear more on alternatives.  Lately all I've heard is how
> much better off we'd be if folks used CFFI or tools like Cython to
> write their extension modules.  Regardless of what it is, we should
> try to find *some* solution that puts us in a position that we can
> accomplish certain architectural changes, such as moving away from
> ref-counting.  Larry talked about it at the language summit.

C is pretty flexible when it comes to changing APIs gradually,
e.g. you can have macros adjusting signatures for you or small
wrapper functions fixing semantics, providing additional arguments,
etc.

I think it would be better to first investigate possible
changes to the C API before recommending putting a layer
between Python's C API and its C extensions.

Those layers are useful for people who don't want to dive into
the C API, but don't work well for those who know the C API
and how to use it to give them the best possible performance
or best possible integration with Python.

I haven't seen Larry's talk, just read a short summary of
things he mentioned in that talk. Those looked like a good
starting point for discussions. Perhaps we could have GSoC
students investigate some of these alternatives ?!

Removing the GIL and reference counting will break things,
but if there is a way we can reduce this breakage, I think
we should definitely go for that approach before saying
"oh, no, please don't use our C API".

Aside: The fact that we have so many nice C extensions out
there is proof that we have a good C API. Even though it is
not visible to most Python programmers, it forms a significant
part of Python's success.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 07 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/