[Python-Dev] cffi in stdlib

Maciej Fijalkowski fijall at gmail.com
Wed Feb 27 13:44:12 CET 2013


On Wed, Feb 27, 2013 at 2:39 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Wed, Feb 27, 2013 at 7:06 PM, Maciej Fijalkowski <fijall at gmail.com> 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.
>>
>> It seems to work.
>
> C itself shouldn't be *too* bad - it's trying to parse C++ that is
> truly insane (which is why Dave Beazley explicitly warned Maciej and
> Armin away from that based on his experience with SWIG).
>
> Looking at pycparsing more closely though, there may be a problem with
> the C preprocessing step on Windows. While on Linux it uses the system
> "cpp", for Windows it currently bundles a copy of the LCC
> preprocessor, which may pose licensing challenges
> (https://github.com/drh/lcc/blob/master/CPYRIGHT). However, this
> concern may not be applicable to cffi: given cffi's requirement for a
> full external C compiler to actually *create* the C extension modules
> during development, and the ability to retrieve everything necessary
> directly from the created C extension when no C compiler is available,
> it seems there would be no reason to ever need the bundled C
> preprocessor. So we simply don't ship it, and the LCC license becomes
> irrelevant.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

cffi does not use preprocessor


More information about the Python-Dev mailing list