<br><div class="gmail_quote">On Sat, Aug 27, 2011 at 8:57 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Sat, Aug 27, 2011 at 3:14 PM, Dan Stromberg <<a href="mailto:drsalists@gmail.com">drsalists@gmail.com</a>> wrote:<br>
> IMO, we really, really need some common way of accessing C libraries that<br>
> works for all major Python variants.<br>
<br>
</div>We have one. It's called writing an extension module.<br></blockquote><div><br>And yet Cext's are full of CPython-isms.<br><br>I've said in the past that Python has been lucky in that it had only a single implementation for a long time, but still managed to escape becoming too defined by the idiosyncrasies of that implementation - that's quite impressive, and is probably our best indication that Python has had leadership with foresight. In the language proper, I'd say I still believe this, but Cext's are sadly not a good example.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
ctypes is a crutch because it doesn't realistically have access to the<br>
header files.</blockquote><div><br>Well, actually, header files are pretty easy to come by. I bet you've installed them yourself many times. In fact, you've probably even automatically brought some of them in via a package management system of one form or another without getting your hands dirty.<br>
<br>As a thought experiment, imagine having a ctypes configuration system that looks around a computer for .h's and .so's (etc) with even 25% of the effort expended by GNU autoconf. Instead of building the results into a bunch of .o's, the results are saved in a .ct file or something. If you build-in some reasonable default locations to look in, plus the equivalent of some -I's and -L's (and maybe -rpath's) as needed, you probably end up with a pretty comparable system.<br>
<br>(typedef's might be a harder problem - that's particularly worth discussing, IMO - your chance to nip this in the bud with a reasoned explanation why they can't be handled well!)<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
It's a fine crutch for PyPy, which doesn't have much of<br>
an alternative.</blockquote><div><br>Wait - a second ago I thought I was to believe that C extension modules were the one true way of interfacing with C code across all major implementations? Are we perhaps saying that CPython is "the" major implementation, and that we want it to stay that way?<br>
<br>I personally feel that PyPy has arrived as a major implementation. The backup program I've been writing in my spare time runs great on PyPy (and the CPython's from 2.5.x, and pretty well on Jython). And PyPy has been maturing very rapidly ('just wish they'd do 3.x!).<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> It's also a fine crutch for people who need something<br>
to run *now*. It's a horrible strategy for the standard library.<br></blockquote><div><br>I guess I'm coming to see this as dogma.<br><br>If ctypes is augmented with type information and/or version information and where to find things, wouldn't it Become safe and convenient? Or do you have other concerns?<br>
<br>Make a list of things that can go wrong with ctypes modules. Now make a list of things that can wrong with C extension modules. Aren't they really pretty similar - missing .so, .so in a weird place, and especially: .so with a changed interface? C really isn't a very safe language - not like <a href="http://en.wikipedia.org/wiki/Turing_%28programming_language%29">http://en.wikipedia.org/wiki/Turing_%28programming_language%29</a> or something. Perhaps it's a little easier to mess things up with ctypes today (a recompile doesn't fix, or at least detect, as many problems), but isn't it at least worth Thinking about how that situation could be improved?<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If you have a better proposal please do write it up. But so far you<br>
are mostly exposing your ignorance and insisting dramatically that you<br>
be educated.<font color="#888888"><br></font></blockquote><div><br>I'm not sure why you're trying to avoid having a discussion. I think it's premature to dive into a proposal before getting other people's thoughts. Frankly, 100 people tend to think better than one - at least, if the 100 people feel like they can talk.<br>
<br>I'm -not- convinced ctypes are the way forward. I just want to talk about it - for now. ctypes have some significant advantages - if we can find a way to eliminate and/or ameliorate their disadvantages, they might be quite a bit nicer than Cext's.<br>
<br></div></div>