On Thu, Dec 19, 2013 at 2:07 AM, Maciej Fijalkowski wrote:
> On Thu, Dec 19, 2013 at 3:17 AM, Gregory P. Smith wrote:
> >
> >
> >
> > On Tue, Dec 17, 2013 at 8:43 AM, Stefan Krah
> wrote:
> >>
> >> Maciej Fijalkowski wrote:
> >> > I would like to discuss on the language summit a potential inclu
Gregory P. Smith wrote:
> Ubuntu compiles their Python with FDO (feedback directed optimization /
> profile
> guided optimization) enabled. All distros should do this if they don't
> already.
> It's generally 20% interpreter speedup. Our makefile already supports it but
> it
> isn't the default
On Thu, Dec 19, 2013 at 3:17 AM, Gregory P. Smith wrote:
>
>
>
> On Tue, Dec 17, 2013 at 8:43 AM, Stefan Krah wrote:
>>
>> Maciej Fijalkowski wrote:
>> > I would like to discuss on the language summit a potential inclusion
>> > of cffi[1] into stdlib. This is a project Armin Rigo has been workin
On Tue, Dec 17, 2013 at 8:43 AM, Stefan Krah wrote:
> Maciej Fijalkowski wrote:
> > I would like to discuss on the language summit a potential inclusion
> > of cffi[1] into stdlib. This is a project Armin Rigo has been working
> > for a while, with some input from other developers.
>
> I've trie
On 18 Dec 2013 06:21, "Maciej Fijalkowski" wrote:
>
> On Tue, Dec 17, 2013 at 7:21 PM, Brett Cannon wrote:
> > Maybe someone from PyPy should bring this up as an official topic at the
> > language summit to figure out the blockers (again). Or it can join
regex on
> > the list of "module discussed
On Tue, Dec 17, 2013 at 7:21 PM, Brett Cannon wrote:
> Maybe someone from PyPy should bring this up as an official topic at the
> language summit to figure out the blockers (again). Or it can join regex on
> the list of "module discussed for addition at the language summit but never
> quite pushed
Maybe someone from PyPy should bring this up as an official topic at the
language summit to figure out the blockers (again). Or it can join regex on
the list of "module discussed for addition at the language summit but never
quite pushed to commitment". =)
On Tue, Dec 17, 2013 at 11:43 AM, Stefan
Maciej Fijalkowski wrote:
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib. This is a project Armin Rigo has been working
> for a while, with some input from other developers.
I've tried cffi (admittedly only in a toy script) and find it very nice
to
Hi Stefan,
On Sat, Mar 2, 2013 at 10:10 AM, Stefan Behnel wrote:
> You say that "the API is fairly stable". What about the implementation?
> Will users want to install a new version next to the stdlib one in a couple
> of months,
I think that the implementation is fairly stable as well. The onl
Hi,
looks like no-one's taken over the role of the Advocatus Diaboli yet. =)
Maciej Fijalkowski, 26.02.2013 16:13:
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib. This is a project Armin Rigo has been working
> for a while, with some input from oth
Hi Gregory,
On Sat, Mar 2, 2013 at 8:40 AM, Gregory P. Smith wrote:
>
> On Wed, Feb 27, 2013 at 7:57 AM, Eli Bendersky wrote:
>> So would you say that the main use of the API level is provide an
>> alternative for writing C API code to interface to C libraries. IOW, it's in
>> competition with S
On Wed, Feb 27, 2013 at 7:57 AM, Eli Bendersky wrote:
>
> > I read the cffi docs once again and went through some of the examples. I
>> > want to divide this to two topics.
>> >
>> > One is what you call the "ABI" level. IMHO, it's hands down superior to
>> > ctypes. Your readdir demo demonstrat
Armin Rigo:
> Maybe. Feel like adding an issue to
> https://bitbucket.org/cffi/cffi/issues, with references?
OK, issue #62 added.
> This looks
> like a Windows-specific extension, which means that I don't
> automatically know about it.
While SAL is Windows-specific, gcc supports some si
Le Thu, 28 Feb 2013 10:06:00 +0100,
Armin Rigo a écrit :
>
> Yes, you're right, and the 32-bit Windows platform is still important.
> However, it only works on 32-bit. On typical 64-bit Posix
> environments, if you don't declare argtypes/restype, you usually end
> up very quickly with confusion
Le Thu, 28 Feb 2013 10:57:50 +1300,
Greg Ewing a écrit :
> Antoine Pitrou wrote:
> > We have to find sufficiently silly species of snakes, though.
>
> Glancing through http://en.wikipedia.org/wiki/List_of_snakes,
> we have:
>
> Wart snakes
> Java wart snakes
> Pipe snakes
> Stiletto snakes
> Rub
On 28 February 2013 09:06, Armin Rigo wrote:
> And I think
> that even on 64-bit Windows, passing 0 as a NULL pointer is buggy,
> because it will pass a 32-bit 0. (It may be that it doesn't actually
> make a difference and works anyway, but I'm not sure.) Similarly, a
> function that returns a p
On Thu, Feb 28, 2013 at 10:27 AM, Paul Moore wrote:
> On 27 February 2013 23:18, Armin Rigo wrote:
>> from cffi import FFI
>> ffi = FFI()
>> ffi.cdef("""
>> int MessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);
>> """)
>> lib = ffi.dlopen("USER32.DLL")
>> lib.MessageBox(ff
Hi Paul,
On Thu, Feb 28, 2013 at 9:27 AM, Paul Moore wrote:
> Presumably ffi.NULL isn't needed and I can use 0? (After all, 0 and NULL are
> equivalent in C, so that's
> not a correctness issue).
Indeed. I created
https://bitbucket.org/cffi/cffi/issue/61/convert-0-to-a-null-pointer.
In C, NULL
On 27 February 2013 23:18, Armin Rigo wrote:
> from cffi import FFI
> ffi = FFI()
> ffi.cdef("""
> int MessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);
> """)
> lib = ffi.dlopen("USER32.DLL")
> lib.MessageBox(ffi.NULL, "Hello, world!", "Title", 0)
Yeah, that's loads bette
Hi Neil,
On Thu, Feb 28, 2013 at 12:34 AM, Neil Hodgson wrote:
>Wouldn't it be better to understand the SAL annotations like _In_opt so
> that spurious NULLs (for example) produce a good exception from cffi instead
> of failing inside the system call?
Maybe. Feel like adding an issue to
h
Armin Rigo:
> So the general answer to your question is: we google MessageBox and
> copy that line from the microsoft site, and manually remove the
> unnecessary WINAPI and _In_opt declarations:
Wouldn't it be better to understand the SAL annotations like _In_opt so that
spurious NULLs (for e
Hi Paul,
On Wed, Feb 27, 2013 at 9:31 PM, Paul Moore wrote:
> from ctypes import windll
> MessageBox = windll.User32.MessageBoxW
> MessageBox(0, "Hello, world!", "Title", 0)
You are right that it's a bit cumbersome in cffi up to and including
0.5, but in the cffi trunk all standard Windows types
On 2/27/2013 3:31 PM, Paul Moore wrote:
from ctypes import windll
MessageBox = windll.User32.MessageBoxW
MessageBox(0, "Hello, world!", "Title", 0)
> Note - I wrote this from memory,
Gee, that is pretty easy. Worked perfectly
--
Terry Jan Reedy
___
Antoine Pitrou wrote:
We have to find sufficiently silly species of snakes, though.
Glancing through http://en.wikipedia.org/wiki/List_of_snakes,
we have:
Wart snakes
Java wart snakes
Pipe snakes
Stiletto snakes
Rubber boas
Dog-faced water snakes
Shovel-nosed snakes
Hook-nosed snakes
Leaf-nose
On 27 February 2013 19:26, Paul Moore wrote:
> On 27 February 2013 19:08, Armin Rigo wrote:
>> That's not correct: you can't indeed give the calling convention, but
>> it is not needed for the common case. What is not supported is only
>> Python-defined callbacks using the Windows-specific conve
On Wed, Feb 27, 2013 at 4:18 AM, Ronald Oussoren wrote:
>
> On 27 Feb, 2013, at 10:06, Maciej Fijalkowski wrote:
>
>> On Wed, Feb 27, 2013 at 9:29 AM, Ronald Oussoren
>> wrote:
>>>
>>> On 26 Feb, 2013, at 16:13, Maciej Fijalkowski wrote:
>>>
Hello.
I would like to discuss on the
On 27 February 2013 19:08, Armin Rigo wrote:
> That's not correct: you can't indeed give the calling convention, but
> it is not needed for the common case. What is not supported is only
> Python-defined callbacks using the Windows-specific convention --- as
> documented, there is a workaround fo
Hi Paul,
On Wed, Feb 27, 2013 at 7:24 PM, Paul Moore wrote:
> On 27 February 2013 11:53, Maciej Fijalkowski wrote:
>> I think it means you can't use the ABI version and specify the calling
>> convention. It's a reasonable bug report (the calling convention on
>> API version works though)
>
> Tha
On 27 February 2013 18:50, Brett Cannon wrote:
>> One other use case for the ABI level over the API level - the ABI
>> level (no C extension) can be used across Python versions, where the
>> API level needs a separate compiled extension per Python version. This
>> can be a big deal on Windows at l
On Wed, Feb 27, 2013 at 1:28 PM, Paul Moore wrote:
> 27 February 2013 18:24, Paul Moore wrote:
> > On 27 February 2013 11:53, Maciej Fijalkowski wrote:
> >> I think it means you can't use the ABI version and specify the calling
> >> convention. It's a reasonable bug report (the calling convent
27 February 2013 18:24, Paul Moore wrote:
> On 27 February 2013 11:53, Maciej Fijalkowski wrote:
>> I think it means you can't use the ABI version and specify the calling
>> convention. It's a reasonable bug report (the calling convention on
>> API version works though)
>
> That would be a deal-
On 27 February 2013 11:53, Maciej Fijalkowski wrote:
> I think it means you can't use the ABI version and specify the calling
> convention. It's a reasonable bug report (the calling convention on
> API version works though)
That would be a deal-breaker for my use case of quick scripts working
wit
On Wed, Feb 27, 2013 at 5:57 PM, Eli Bendersky wrote:
>
>> > I read the cffi docs once again and went through some of the examples. I
>> > want to divide this to two topics.
>> >
>> > One is what you call the "ABI" level. IMHO, it's hands down superior to
>> > ctypes. Your readdir demo demonstrate
> > I read the cffi docs once again and went through some of the examples. I
> > want to divide this to two topics.
> >
> > One is what you call the "ABI" level. IMHO, it's hands down superior to
> > ctypes. Your readdir demo demonstrates this very nicely. I would
> definitely
> > want to see this
On Tue, Feb 26, 2013 at 11:29 PM, Ronald Oussoren wrote:
>
> On 26 Feb, 2013, at 16:13, Maciej Fijalkowski wrote:
>
> > Hello.
> >
> > I would like to discuss on the language summit a potential inclusion
> > of cffi[1] into stdlib.
>
> The API in general looks nice, but I do have some concens w.r
Hi Guido,
On Tue, Feb 26, 2013 at 8:24 PM, Guido van Rossum wrote:
> From a software engineering perspective, 10 years is indistinguishable
> from infinity, so I don't care what happens 10 years from now -- as
> long as you don't blame me. :-)
I can't resist: around today it is the 10th annivers
On 27 February 2013 10:31, Antoine Pitrou wrote:
> Le Wed, 27 Feb 2013 12:15:05 +1300,
> Greg Ewing a écrit :
> > Antoine Pitrou wrote:
> > > Or we'll go straight to 5.
> > > (or switch to date-based numbering :-))
> >
> > We could go the Apple route and start naming them after
> > species of sn
On 2013-02-27, at 14:31 , Antoine Pitrou wrote:
> Le Wed, 27 Feb 2013 12:15:05 +1300,
> Greg Ewing a écrit :
>> Antoine Pitrou wrote:
>>> Or we'll go straight to 5.
>>> (or switch to date-based numbering :-))
>>
>> We could go the Apple route and start naming them after
>> species of snake.
>
>
Le Wed, 27 Feb 2013 12:15:05 +1300,
Greg Ewing a écrit :
> Antoine Pitrou wrote:
> > Or we'll go straight to 5.
> > (or switch to date-based numbering :-))
>
> We could go the Apple route and start naming them after
> species of snake.
We have to find sufficiently silly species of snakes, though
On Wed, Feb 27, 2013 at 7:00 PM, Maciej Fijalkowski wrote:
> On Wed, Feb 27, 2013 at 6:53 AM, Eli Bendersky wrote:
>> 2. Using a function called "verify" to create stuff. This may sound like a
>> naming bikeshed, but it's not. It ties in to the question - why is this
>> needed?
>
> We welcome a b
On Wed, Feb 27, 2013 at 2:39 PM, Nick Coghlan wrote:
> On Wed, Feb 27, 2013 at 7:06 PM, Maciej Fijalkowski wrote:
>>> 3. Cffi basicly contains a (limited) C parser, and those are notoriously
>>> hard to get exactly right. Luckily cffi only needs to interpret
>>> declarations and not the full la
On Wed, Feb 27, 2013 at 7:06 PM, Maciej Fijalkowski wrote:
>> 3. Cffi basicly contains a (limited) C parser, and those are notoriously
>> hard to get exactly right. Luckily cffi only needs to interpret declarations
>> and not the full language, but even so this can be a risk of subtle bugs.
>
>
On Wed, Feb 27, 2013 at 1:45 PM, Richard Oudkerk wrote:
> On 27/02/2013 9:21am, Maciej Fijalkowski wrote:
>>>
>>> >That's somehting that will have to be resolved before cffi can be
>>> > included in the stdlib, fat binaries are supported by CPython and are used
>>> > the binary installers.
>>> >
>
On 27/02/2013 9:21am, Maciej Fijalkowski wrote:
>That's somehting that will have to be resolved before cffi can be included in
the stdlib, fat binaries are supported by CPython and are used the binary
installers.
>
>Ronald
if cpython supports it and you can load it using dlopen, it does work
t
On Wed, Feb 27, 2013 at 11:18 AM, Ronald Oussoren
wrote:
>
> On 27 Feb, 2013, at 10:06, Maciej Fijalkowski wrote:
>
>> On Wed, Feb 27, 2013 at 9:29 AM, Ronald Oussoren
>> wrote:
>>>
>>> On 26 Feb, 2013, at 16:13, Maciej Fijalkowski wrote:
>>>
Hello.
I would like to discuss on th
On 27 Feb, 2013, at 10:06, Maciej Fijalkowski wrote:
> On Wed, Feb 27, 2013 at 9:29 AM, Ronald Oussoren
> wrote:
>>
>> On 26 Feb, 2013, at 16:13, Maciej Fijalkowski wrote:
>>
>>> Hello.
>>>
>>> I would like to discuss on the language summit a potential inclusion
>>> of cffi[1] into stdlib.
On Wed, Feb 27, 2013 at 9:29 AM, Ronald Oussoren wrote:
>
> On 26 Feb, 2013, at 16:13, Maciej Fijalkowski wrote:
>
>> Hello.
>>
>> I would like to discuss on the language summit a potential inclusion
>> of cffi[1] into stdlib.
>
> The API in general looks nice, but I do have some concens w.r.t. i
On Wed, Feb 27, 2013 at 6:53 AM, Eli Bendersky wrote:
>
> * Work either at the level of the ABI (Application Binary Interface)
>>
>> or the API (Application Programming Interface). Usually, C libraries
>> have a specified C API but often not an ABI (e.g. they may document a
>> “struct” as having a
On Wed, Feb 27, 2013 at 3:39 AM, Terry Reedy wrote:
> On 2/26/2013 10:13 AM, Maciej Fijalkowski wrote:
>
>> I would like to discuss on the language summit a potential inclusion
>> of cffi[1] into stdlib.
>
>
> How does it compare in terms of speed. One reason ctypes has not replaces
> hand-tuned s
On 26 Feb, 2013, at 16:13, Maciej Fijalkowski wrote:
> Hello.
>
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib.
The API in general looks nice, but I do have some concens w.r.t. including cffi
in the stdlib.
1. Why is cffi completely separate
* Work either at the level of the ABI (Application Binary Interface)
> or the API (Application Programming Interface). Usually, C libraries
> have a specified C API but often not an ABI (e.g. they may document a
> “struct” as having at least these fields, but maybe more). (ctypes
> works at the AB
On 2/26/2013 10:13 AM, Maciej Fijalkowski wrote:
I would like to discuss on the language summit a potential inclusion
of cffi[1] into stdlib.
How does it compare in terms of speed. One reason ctypes has not
replaces hand-tuned swig is that it apparently is much slower. I know
that someone, f
Antoine Pitrou wrote:
Or we'll go straight to 5.
(or switch to date-based numbering :-))
We could go the Apple route and start naming them after
species of snake.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
On Tue, 26 Feb 2013 14:21:03 -0500
Brett Cannon wrote:
> On Tue, Feb 26, 2013 at 2:12 PM, Guido van Rossum wrote:
>
> > Generally speaking, deferring something to Python 4 means "never".
> >
>
> Does that mean your aversion to double digit version numbers (i.e. 3.10) is
> gone or you expect to
With 1.5 years per release, it'd be 10 years before we'd hit 3.10.
>From a software engineering perspective, 10 years is indistinguishable
from infinity, so I don't care what happens 10 years from now -- as
long as you don't blame me. :-)
On Tue, Feb 26, 2013 at 11:21 AM, Brett Cannon wrote:
>
>
On Tue, Feb 26, 2013 at 2:12 PM, Guido van Rossum wrote:
> Generally speaking, deferring something to Python 4 means "never".
>
Does that mean your aversion to double digit version numbers (i.e. 3.10) is
gone or you expect to freeze Python in carbonite by then?
-Brett
>
> On Tue, Feb 26, 2013
Generally speaking, deferring something to Python 4 means "never".
On Tue, Feb 26, 2013 at 11:06 AM, R. David Murray wrote:
> On Tue, 26 Feb 2013 18:14:26 +, Paul Moore wrote:
>> BTW, I assume that the intention is that both cffi and ctypes remain
>> available indefinitely? Nobody's looking
On Tue, 26 Feb 2013 18:14:26 +, Paul Moore wrote:
> BTW, I assume that the intention is that both cffi and ctypes remain
> available indefinitely? Nobody's looking to deprecate ctypes?
I would expect that ctypes would be deprecated eventually simply because
there aren't very many people inter
On Tue, Feb 26, 2013 at 8:14 PM, Paul Moore wrote:
> On 26 February 2013 16:34, Eli Bendersky wrote:
>> I'm cautiously +0.5 because I'd really like to see a strong comparison case
>> being made vs. ctypes. I've used ctypes many times and it was easy and
>> effortless (well, except the segfaults w
On 26 February 2013 18:34, Maciej Fijalkowski wrote:
>> One point which I *think* is correct, but which I don't see noted
>> anywhere. Am I right that cffi needs a C compiler involved in the
>> process, at least somewhere? If that's the case, then it is not a
>> suitable option for at least one us
On 26 February 2013 16:34, Eli Bendersky wrote:
> I'm cautiously +0.5 because I'd really like to see a strong comparison case
> being made vs. ctypes. I've used ctypes many times and it was easy and
> effortless (well, except the segfaults when wrong argument types are
> declared :-). I'll be real
+1
On Tue, Feb 26, 2013 at 12:14 PM, Maciej Fijalkowski wrote:
> On Tue, Feb 26, 2013 at 7:07 PM, Eli Bendersky wrote:
> >
> >
> >
> > On Tue, Feb 26, 2013 at 8:39 AM, Maciej Fijalkowski
> > wrote:
> >>
> >> On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky
> wrote:
> >> >
> >> > On Tue, Feb 26,
On Tue, Feb 26, 2013 at 7:07 PM, Eli Bendersky wrote:
>
>
>
> On Tue, Feb 26, 2013 at 8:39 AM, Maciej Fijalkowski
> wrote:
>>
>> On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky wrote:
>> >
>> > On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan
>> > wrote:
>> >>
>> >> On Wed, Feb 27, 2013 at 1:13 AM,
On Tue, Feb 26, 2013 at 8:39 AM, Maciej Fijalkowski wrote:
> On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky wrote:
> >
> > On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan
> wrote:
> >>
> >> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski
> >> wrote:
> >> > Hello.
> >> >
> >> > I would like to
On Wed, Feb 27, 2013 at 2:39 AM, Maciej Fijalkowski wrote:
> On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky wrote:
>>
>> On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan wrote:
>>>
>>> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski
>>> wrote:
>>> > Hello.
>>> >
>>> > I would like to discuss o
Hi,
On Tue, Feb 26, 2013 at 5:38 PM, Maciej Fijalkowski wrote:
>> Do you intend to actually maintain it inside the CPython repository?
>
> Once we put it in, yes, of course. Me Armin and Alex.
Yes, I confirm. :-)
Armin
___
Python-Dev mailing list
Pyth
On Tue, Feb 26, 2013 at 6:32 PM, Antoine Pitrou wrote:
> Le Tue, 26 Feb 2013 17:13:44 +0200,
> Maciej Fijalkowski a écrit :
>> Hello.
>>
>> I would like to discuss on the language summit a potential inclusion
>> of cffi[1] into stdlib. This is a project Armin Rigo has been working
>> for a while,
On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky wrote:
>
> On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan wrote:
>>
>> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski
>> wrote:
>> > Hello.
>> >
>> > I would like to discuss on the language summit a potential inclusion
>> > of cffi[1] into stdli
On Tue, Feb 26, 2013 at 8:26 AM, Maciej Fijalkowski wrote:
> On Tue, Feb 26, 2013 at 5:42 PM, Nick Coghlan wrote:
> > On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski
> wrote:
> >> Hello.
> >>
> >> I would like to discuss on the language summit a potential inclusion
> >> of cffi[1] into stdli
On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan wrote:
> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski
> wrote:
> > Hello.
> >
> > I would like to discuss on the language summit a potential inclusion
> > of cffi[1] into stdlib.
>
> I think cffi is well worth considering as a possible inclusi
Le Tue, 26 Feb 2013 17:13:44 +0200,
Maciej Fijalkowski a écrit :
> Hello.
>
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib. This is a project Armin Rigo has been working
> for a while, with some input from other developers. It seems that the
> main
On Tue, Feb 26, 2013 at 4:13 PM, Maciej Fijalkowski wrote:
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib. This is a project Armin Rigo has been working
> for a while, with some input from other developers. It seems that the
> main reason why people
On Tue, Feb 26, 2013 at 5:42 PM, Nick Coghlan wrote:
> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski wrote:
>> Hello.
>>
>> I would like to discuss on the language summit a potential inclusion
>> of cffi[1] into stdlib.
>
> I think cffi is well worth considering as a possible inclusion for
A big +1 from me for cffi in the stdlib it's a great library.
I just recently started using it to make bindings to a C library. I
looked at the ctypes library, but haven't actually used it, because
the docs confused me but with cffi I was able to get somewhere just
by a liberal use of copy/paste f
On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski wrote:
> Hello.
>
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib.
I think cffi is well worth considering as a possible inclusion for
Python 3.4. (In particular, I'm a fan of the fact it just uses
Hello.
I would like to discuss on the language summit a potential inclusion
of cffi[1] into stdlib. This is a project Armin Rigo has been working
for a while, with some input from other developers. It seems that the
main reason why people would prefer ctypes over cffi these days is
"because it's i
76 matches
Mail list logo
