On Wed, Feb 27, 2013 at 7:06 PM, Maciej Fijalkowski <fij...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
