From stefan_ml at behnel.de Sun May 3 11:29:05 2015 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 03 May 2015 11:29:05 +0200 Subject: [Cython] fixing jedi typing support with Jedi 0.9 Message-ID: <5545EA61.2070800@behnel.de> Hi, due to changes in Jedi 0.9 [1], the automatic jedi typing support is now broken. Since I remember there being some interest in automatic static Python code typing, I'm asking here if anyone's interested in fixing it, or really maintaining it. The latest Jedi release is aiming towards better integration with external tools, so there should be way to implement this in a cleaner way than what I hacked up last year. The current code is here: https://github.com/cython/cython/blob/master/Tools/jedi-typer.py The new intended starting point (instead of jedi.Script) seems to be jedi.names() for static code analysis, which then returns a list of "Definition" objects. http://jedi.jedidjah.ch/en/latest/docs/plugin-api-classes.html Anyone interested? Please keep further discussion on the cython-devel mailing list (not cython-users). Stefan [1] http://jedi.jedidjah.ch/ From michael at ensslin.cc Thu May 7 15:13:13 2015 From: michael at ensslin.cc (=?UTF-8?B?TWljaGFlbCBFbsOfbGlu?=) Date: Thu, 07 May 2015 15:13:13 +0200 Subject: [Cython] Misleading error message when assigning function pointers with differing except* declarations Message-ID: <554B64E9.6070503@ensslin.cc> Hi, consider the following example: $ cat demo.pyx cdef void (*foo)() cdef void bar() except*: pass foo = bar $ cython demo.pyx Error compiling Cython file: ------------------------------------------------------------ ... cdef void (*foo)() cdef void bar() except*: pass foo = bar ^ ------------------------------------------------------------ demo.pyx:6:9: Cannot assign type 'void (void)' to 'void (*)(void)' this is all expected behavior, but the error message is entirely misleading; it should be something like demo.pyx:6:9: Function pointers have incompatible 'except *' declarations. Note that the same error message also occurs when the pointer is declared except*, and the function isn't. ~ mic_e -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From michael at ensslin.cc Fri May 8 14:37:23 2015 From: michael at ensslin.cc (=?UTF-8?B?TWljaGFlbCBFbsOfbGlu?=) Date: Fri, 08 May 2015 14:37:23 +0200 Subject: [Cython] Cython generates invalid C code for some generator expressions in cdef functions Message-ID: <554CAE03.3000601@ensslin.cc> Take the following example: $ cat t2.pyx cdef void read_callback(): foo = b"asdf" bar = (c for c in foo) $ cython t2.pyx $ gcc -I/usr/include/python3.4m t2.c t2.c: In function ?__pyx_f_2t2_read_callback?: t2.c:778:12: error: ?None? undeclared (first use in this function) return None; ^ t2.c:778:12: note: each undeclared identifier is reported only once for each function it appears in t2.c:778:5: warning: ?return? with a value, in function returning void return None; ^ Note that the error does not occur for bar = (c for c in b"asdf") or bar = [c for c in b"asdf"] ~ mic_e -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From stefan_ml at behnel.de Fri May 15 14:13:25 2015 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 15 May 2015 14:13:25 +0200 Subject: [Cython] PEP 448 implemented: unpacking generalisations Message-ID: <5555E2E5.7060007@behnel.de> Hi, I implemented PEP 448 in the latest master branch. It extends Python's unpacking syntax to allow things like d = {**kw, 1: 2, 3: 4, **morekw} s = {1, 2, 3, *args, *extra} t = (1, *x, *y, *z) head, *tail = [*x, *y] func(**kw1, **kw2) https://www.python.org/dev/peps/pep-0448/ For function calls, you'll get an error for duplicate keys, but not for dicts and sets, where the last entry prevails. I'd be happy to see some feedback. The code it generates is already pretty good and I've added a whole bunch of tests, but it definitely needs some user side testing. If you find anything that doesn't work, please send a pull request that adds a test to one of the pep448_*.pyx test files in the tests directory. Stefan From stefan_ml at behnel.de Thu May 21 09:53:52 2015 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 21 May 2015 09:53:52 +0200 Subject: [Cython] a C++ wrapping wishlist Message-ID: <555D8F10.9030003@behnel.de> Someone wrote a list of shortcomings after wrapping some C++ code: http://blog.marcus-brinkmann.de/2014/07/31/cython-trouble/ A couple of these issues are due to misunderstandings (specifically the "imports" section) or now-fixed bugs (post is almost a year old), but it seems that some of them are still valid and might be low-hanging fruit. Stefan From jdemeyer at cage.ugent.be Thu May 21 14:21:09 2015 From: jdemeyer at cage.ugent.be (Jeroen Demeyer) Date: Thu, 21 May 2015 14:21:09 +0200 Subject: [Cython] Broken link to CEP 516 Message-ID: <555DCDB5.30907@cage.ugent.be> At http://docs.cython.org/src/reference/compilation.html#compiler-directives there are two links to "CEP 516" but they are broken. Jeroen. From stefan_ml at behnel.de Thu May 21 19:59:46 2015 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 21 May 2015 19:59:46 +0200 Subject: [Cython] Broken link to CEP 516 In-Reply-To: <555DCDB5.30907@cage.ugent.be> References: <555DCDB5.30907@cage.ugent.be> Message-ID: <555E1D12.3000005@behnel.de> Jeroen Demeyer schrieb am 21.05.2015 um 14:21: > http://docs.cython.org/src/reference/compilation.html#compiler-directives > there are two links to "CEP 516" but they are broken. Thanks. The problem seems to be an incorrect redirect to "github.../wikienhancements/" instead of "github.../wiki/enhancements/". I don't know how the setup is done here, but Robert should know. Stefan From stefan_ml at behnel.de Thu May 21 21:29:15 2015 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 21 May 2015 21:29:15 +0200 Subject: [Cython] Misleading error message when assigning function pointers with differing except* declarations In-Reply-To: <554B64E9.6070503@ensslin.cc> References: <554B64E9.6070503@ensslin.cc> Message-ID: <555E320B.3060500@behnel.de> Michael En?lin schrieb am 07.05.2015 um 15:13: > consider the following example: > > $ cat demo.pyx > cdef void (*foo)() > > cdef void bar() except*: > pass > > foo = bar > > > > $ cython demo.pyx > > Error compiling Cython file: > ------------------------------------------------------------ > ... > cdef void (*foo)() > > cdef void bar() except*: > pass > > foo = bar > ^ > ------------------------------------------------------------ > > demo.pyx:6:9: Cannot assign type 'void (void)' to 'void (*)(void)' > > this is all expected behavior, but the error message is entirely > misleading; it should be something like > > demo.pyx:6:9: Function pointers have incompatible 'except *' declarations. Thanks for the report. I think displaying "except *" as part of the function type would make this clear enough, i.e. you'd get Cannot assign type 'void (void) except *' to 'void (*)(void)' https://github.com/cython/cython/commit/937f83149eaf979850faa25f62857e29726c11a6 Stefan From stefan_ml at behnel.de Thu May 21 22:02:56 2015 From: stefan_ml at behnel.de (Stefan Behnel) Date: Thu, 21 May 2015 22:02:56 +0200 Subject: [Cython] Cython generates invalid C code for some generator expressions in cdef functions In-Reply-To: <554CAE03.3000601@ensslin.cc> References: <554CAE03.3000601@ensslin.cc> Message-ID: <555E39F0.50305@behnel.de> Michael En?lin schrieb am 08.05.2015 um 14:37: > Take the following example: > > > $ cat t2.pyx > cdef void read_callback(): > foo = b"asdf" > bar = (c for c in foo) > > > > $ cython t2.pyx > > > > $ gcc -I/usr/include/python3.4m t2.c > t2.c: In function ?__pyx_f_2t2_read_callback?: > t2.c:778:12: error: ?None? undeclared (first use in this function) > return None; > ^ > t2.c:778:12: note: each undeclared identifier is reported only once for > each function it appears in > t2.c:778:5: warning: ?return? with a value, in function returning void > return None; > ^ > > > Note that the error does not occur for > > bar = (c for c in b"asdf") > > or > > bar = [c for c in b"asdf"] Thanks for the report. This should fix it: https://github.com/cython/cython/commit/f8b952c16dc569e50642d426e328d2d0fe0f53aa Stefan From insertinterestingnamehere at gmail.com Thu May 21 22:22:54 2015 From: insertinterestingnamehere at gmail.com (Ian Henriksen) Date: Thu, 21 May 2015 20:22:54 +0000 Subject: [Cython] a C++ wrapping wishlist In-Reply-To: <555D8F10.9030003@behnel.de> References: <555D8F10.9030003@behnel.de> Message-ID: On Thu, May 21, 2015 at 2:13 AM Stefan Behnel wrote: > Someone wrote a list of shortcomings after wrapping some C++ code: > > http://blog.marcus-brinkmann.de/2014/07/31/cython-trouble/ > > A couple of these issues are due to misunderstandings (specifically the > "imports" section) or now-fixed bugs (post is almost a year old), but it > seems that some of them are still valid and might be low-hanging fruit. > > Stefan > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel That's a very well-thought-out list. Overloading assignment and defining custom type coercions would be useful features to have. An idiomatic way of writing signatures for variadic templates and letting functions returning references be used as left-values are two other things that would be very nice to see. Thanks! -Ian Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdemeyer at cage.ugent.be Sat May 23 10:47:10 2015 From: jdemeyer at cage.ugent.be (Jeroen Demeyer) Date: Sat, 23 May 2015 10:47:10 +0200 Subject: [Cython] Pull request #374 (api mangling prefix) merged in Sage Message-ID: <55603E8E.2080803@cage.ugent.be> This has been merged in Sage's version of Cython: https://github.com/cython/cython/pull/374 The change looks quite innocent, so I so little reason to not merge it in Cython master. From robertwb at math.washington.edu Sun May 24 07:29:34 2015 From: robertwb at math.washington.edu (Robert Bradshaw) Date: Sat, 23 May 2015 22:29:34 -0700 Subject: [Cython] Broken link to CEP 516 In-Reply-To: <555E1D12.3000005@behnel.de> References: <555DCDB5.30907@cage.ugent.be> <555E1D12.3000005@behnel.de> Message-ID: On Thu, May 21, 2015 at 10:59 AM, Stefan Behnel wrote: > Jeroen Demeyer schrieb am 21.05.2015 um 14:21: >> http://docs.cython.org/src/reference/compilation.html#compiler-directives >> there are two links to "CEP 516" but they are broken. > > Thanks. The problem seems to be an incorrect redirect to > "github.../wikienhancements/" instead of "github.../wiki/enhancements/". > > I don't know how the setup is done here, but Robert should know. It's now an apache redirect. The above URL is fixes, as well as the / to - translation for, e.g. http://wiki.cython.org/enhancements/division From robertwb at gmail.com Sun May 24 08:19:02 2015 From: robertwb at gmail.com (Robert Bradshaw) Date: Sat, 23 May 2015 23:19:02 -0700 Subject: [Cython] a C++ wrapping wishlist In-Reply-To: References: <555D8F10.9030003@behnel.de> Message-ID: On Thu, May 21, 2015 at 1:22 PM, Ian Henriksen wrote: > > On Thu, May 21, 2015 at 2:13 AM Stefan Behnel wrote: >> >> Someone wrote a list of shortcomings after wrapping some C++ code: >> >> http://blog.marcus-brinkmann.de/2014/07/31/cython-trouble/ >> >> A couple of these issues are due to misunderstandings (specifically the >> "imports" section) or now-fixed bugs (post is almost a year old), but it >> seems that some of them are still valid and might be low-hanging fruit. Indeed. > That's a very well-thought-out list. Overloading assignment and > defining custom type coercions would be useful features to have. This is, however, a slippery slope. > An idiomatic way of writing signatures for variadic templates and Yes, template support certainly has a lot to be desired. > letting functions returning references be used as left-values are > two other things that would be very nice to see. Letting arbitrary expressions be lvalues would be a major change to the Python API... From andrea at andreabedini.com Sun May 24 07:49:27 2015 From: andrea at andreabedini.com (Andrea Bedini) Date: Sun, 24 May 2015 15:49:27 +1000 Subject: [Cython] Broken link to CEP 516 In-Reply-To: References: <555DCDB5.30907@cage.ugent.be> <555E1D12.3000005@behnel.de> Message-ID: <1432446567.4075971.276734033.21827D15@webmail.messagingengine.com> Hi there, Just a tip. It would be better if you could make apache respond with 301 Moved Permanently rather than with 302 Found. This way users and search engines can update their links. I can be done by specifying the http response code on the redirect directive, like: Redirect 301 /retiredpage.html http://www.xyz.com/newpage.html my 2c, Andrea On Sun, 24 May 2015, at 03:29 PM, Robert Bradshaw wrote: > On Thu, May 21, 2015 at 10:59 AM, Stefan Behnel > wrote: > > Jeroen Demeyer schrieb am 21.05.2015 um 14:21: > >> http://docs.cython.org/src/reference/compilation.html#compiler-directives > >> there are two links to "CEP 516" but they are broken. > > > > Thanks. The problem seems to be an incorrect redirect to > > "github.../wikienhancements/" instead of "github.../wiki/enhancements/". > > > > I don't know how the setup is done here, but Robert should know. > > It's now an apache redirect. The above URL is fixes, as well as the / > to - translation for, e.g. > http://wiki.cython.org/enhancements/division > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel -- Andrea Bedini @andreabedini http://www.andreabedini.com From robertwb at gmail.com Sun May 24 09:34:18 2015 From: robertwb at gmail.com (Robert Bradshaw) Date: Sun, 24 May 2015 00:34:18 -0700 Subject: [Cython] Broken link to CEP 516 In-Reply-To: <1432446567.4075971.276734033.21827D15@webmail.messagingengine.com> References: <555DCDB5.30907@cage.ugent.be> <555E1D12.3000005@behnel.de> <1432446567.4075971.276734033.21827D15@webmail.messagingengine.com> Message-ID: Yes, for sure. (I'm sure it used to be a 301...). Thanks for noticing; fixed. On Sat, May 23, 2015 at 10:49 PM, Andrea Bedini wrote: > Hi there, > > Just a tip. It would be better if you could make apache respond with 301 > Moved Permanently rather than with 302 Found. This way users and search > engines can update their links. > > I can be done by specifying the http response code on the redirect > directive, like: > > Redirect 301 /retiredpage.html http://www.xyz.com/newpage.html > > my 2c, > Andrea > > On Sun, 24 May 2015, at 03:29 PM, Robert Bradshaw wrote: >> On Thu, May 21, 2015 at 10:59 AM, Stefan Behnel >> wrote: >> > Jeroen Demeyer schrieb am 21.05.2015 um 14:21: >> >> http://docs.cython.org/src/reference/compilation.html#compiler-directives >> >> there are two links to "CEP 516" but they are broken. >> > >> > Thanks. The problem seems to be an incorrect redirect to >> > "github.../wikienhancements/" instead of "github.../wiki/enhancements/". >> > >> > I don't know how the setup is done here, but Robert should know. >> >> It's now an apache redirect. The above URL is fixes, as well as the / >> to - translation for, e.g. >> http://wiki.cython.org/enhancements/division >> _______________________________________________ >> cython-devel mailing list >> cython-devel at python.org >> https://mail.python.org/mailman/listinfo/cython-devel > > > -- > Andrea Bedini > @andreabedini > http://www.andreabedini.com > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel From jomaroceguedag at gmail.com Wed May 27 04:17:40 2015 From: jomaroceguedag at gmail.com (Jesus-Omar Ocegueda-Gonzalez) Date: Tue, 26 May 2015 21:17:40 -0500 Subject: [Cython] Exporting inline functions from a pyx. Message-ID: Dear Cython developers, thanks for the awesome compiler!, we recently faced an issue exporting inline functions defined in a .pyx. According to this: http://docs.cython.org/src/tutorial/pxd_files.html the full inline definition (not just the declaration) should be in the pxd. However, if we put the definition in the .pyx and just its declaration header in the .pxd, Cython declares a pointer to the inline function similar to: static CYTHON_INLINE double (*__function_name)(...); /*proto*/ but this causes a compilation error in some platforms (but successfully compiles in others) because variables cannot be declare as inline. You can find a log with the compilation errors here: http://nipy.bic.berkeley.edu/builders/dipy-py2.7-osx-10.8/builds/362/steps/shell_5/logs/stdio I guess it should be possible to detect when a function is inline and in that case remove the CYTHON_INLINE from the pointer declaration, or at least consistently fail in all platforms. Is this a known issue? Thank you very much! With warm regards, -Omar. -- "Cada quien es due?o de lo que calla y esclavo de lo que dice" -Proverbio chino. "We all are owners of what we keep silent and slaves of what we say" -Chinese proverb. http://www.cimat.mx/~omar -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertwb at gmail.com Thu May 28 20:16:13 2015 From: robertwb at gmail.com (Robert Bradshaw) Date: Thu, 28 May 2015 11:16:13 -0700 Subject: [Cython] Exporting inline functions from a pyx. In-Reply-To: References: Message-ID: On Tue, May 26, 2015 at 7:17 PM, Jesus-Omar Ocegueda-Gonzalez wrote: > Dear Cython developers, > thanks for the awesome compiler!, we recently faced an issue exporting > inline functions defined in a .pyx. According to this: > http://docs.cython.org/src/tutorial/pxd_files.html > the full inline definition (not just the declaration) should be in the pxd. > However, if we put the definition in the .pyx and just its declaration > header in the .pxd, Yes, it sounds like there's a bug here, but is there a reason you're doing this? > Cython declares a pointer to the inline function > similar to: > > static CYTHON_INLINE double (*__function_name)(...); /*proto*/ > > but this causes a compilation error in some platforms (but successfully > compiles in others) because variables cannot be declare as inline. You can > find a log with the compilation errors here: > http://nipy.bic.berkeley.edu/builders/dipy-py2.7-osx-10.8/builds/362/steps/shell_5/logs/stdio > > I guess it should be possible to detect when a function is inline and in > that case remove the CYTHON_INLINE from the pointer declaration, or at least > consistently fail in all platforms. Is this a known issue? > > Thank you very much! > With warm regards, > -Omar. > -- > "Cada quien es due?o de lo que calla y esclavo de lo que dice" > -Proverbio chino. > "We all are owners of what we keep silent and slaves of what we say" > -Chinese proverb. > > http://www.cimat.mx/~omar > > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel > From jomaroceguedag at gmail.com Thu May 28 20:33:30 2015 From: jomaroceguedag at gmail.com (Jesus-Omar Ocegueda-Gonzalez) Date: Thu, 28 May 2015 13:33:30 -0500 Subject: [Cython] Exporting inline functions from a pyx. In-Reply-To: References: Message-ID: It was a mistake. I just wanted to export a function from the .pyx, and I did not consider the fact that inline functions should be treated differently (the standard procedure for me was just to add the declaration in the .pxd, the inline thingy looked inoffensive =) ). The inconvenient was that in my local machine, and the reviewers' everything worked ok, but we started getting a lot of compilation errors in other platforms after my pull request was merged. On Thu, May 28, 2015 at 1:16 PM, Robert Bradshaw wrote: > On Tue, May 26, 2015 at 7:17 PM, Jesus-Omar Ocegueda-Gonzalez > wrote: > > Dear Cython developers, > > thanks for the awesome compiler!, we recently faced an issue exporting > > inline functions defined in a .pyx. According to this: > > http://docs.cython.org/src/tutorial/pxd_files.html > > the full inline definition (not just the declaration) should be in the > pxd. > > However, if we put the definition in the .pyx and just its declaration > > header in the .pxd, > > Yes, it sounds like there's a bug here, but is there a reason you're doing > this? > > > Cython declares a pointer to the inline function > > similar to: > > > > static CYTHON_INLINE double (*__function_name)(...); /*proto*/ > > > > but this causes a compilation error in some platforms (but successfully > > compiles in others) because variables cannot be declare as inline. You > can > > find a log with the compilation errors here: > > > http://nipy.bic.berkeley.edu/builders/dipy-py2.7-osx-10.8/builds/362/steps/shell_5/logs/stdio > > > > I guess it should be possible to detect when a function is inline and in > > that case remove the CYTHON_INLINE from the pointer declaration, or at > least > > consistently fail in all platforms. Is this a known issue? > > > > Thank you very much! > > With warm regards, > > -Omar. > > -- > > "Cada quien es due?o de lo que calla y esclavo de lo que dice" > > -Proverbio chino. > > "We all are owners of what we keep silent and slaves of what we say" > > -Chinese proverb. > > > > http://www.cimat.mx/~omar > > > > _______________________________________________ > > cython-devel mailing list > > cython-devel at python.org > > https://mail.python.org/mailman/listinfo/cython-devel > > > _______________________________________________ > cython-devel mailing list > cython-devel at python.org > https://mail.python.org/mailman/listinfo/cython-devel > -- "Cada quien es due?o de lo que calla y esclavo de lo que dice" -Proverbio chino. "We all are owners of what we keep silent and slaves of what we say" -Chinese proverb. http://www.cimat.mx/~omar -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan_ml at behnel.de Sat May 30 09:28:37 2015 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sat, 30 May 2015 09:28:37 +0200 Subject: [Cython] PEP 492 implemented (async/await) Message-ID: <556966A5.3030901@behnel.de> Hi, I invested a couple of days implementing PEP 492 in Cython. https://www.python.org/dev/peps/pep-0492/ It turned out nicely, so it's now merged into master to become part of Cython 0.23. I also spent some time testing and debugging it against Python 3.5 so that Yury Selivanov could adapt their side for interoperability. The second beta of 3.5 will be released tomorrow and it should "just work". Testing is very welcome. Note that the language feature is available in Cython for all Python versions (2.6+), but usage from Python code with async/await is obviously limited to Python 3.5 where this syntax is available. My guess is that one of the next asyncio (and trollius) backport package releases will add support as well, so that you could run Cython coroutines on top of asyncio also in older Python releases. It's mostly about dropping some explicit type checks here and there or replacing them with ABC isinstance checks. Have fun, Stefan From stefan_ml at behnel.de Sun May 31 07:46:05 2015 From: stefan_ml at behnel.de (Stefan Behnel) Date: Sun, 31 May 2015 07:46:05 +0200 Subject: [Cython] Exporting inline functions from a pyx. In-Reply-To: References: Message-ID: <556AA01D.4070605@behnel.de> Jesus-Omar Ocegueda-Gonzalez schrieb am 27.05.2015 um 04:17: > we recently faced an issue exporting > inline functions defined in a .pyx. According to this: > http://docs.cython.org/src/tutorial/pxd_files.html > the full inline definition (not just the declaration) should be in the pxd. > However, if we put the definition in the .pyx and just its declaration > header in the .pxd, Cython declares a pointer to the inline function > similar to: > > static CYTHON_INLINE double (*__function_name)(...); /*proto*/ > > but this causes a compilation error in some platforms (but successfully > compiles in others) because variables cannot be declare as inline. Thanks for the report, I agree that this looks like a bug. I'm not entirely sure what the best fix is. We could make it an error if an external function declaration in a .pxd file is declared "inline", or we could just ignore the modifier for external functions on the import side. The first case would be more correct, but we'd end up with different declarations in the .pyx and .pxd files. That might be difficult to explain to users that run into this problem, as they would first have to understand that they can still declare their function "inline" in the .pyx file, just not in the .pxd. Just copying the function header over in order to export it will make your code fail to compile. But the second case might also not be without surprises ("why doesn't my 'inline' declaration work here?"), and it leaks implementation details into the .pxd. I'm thus leaning towards the first. I guess it just depends on coming up with a clear error message. (Well, after detecting this case in the first place...) Stefan From robertwb at gmail.com Sun May 31 08:19:11 2015 From: robertwb at gmail.com (Robert Bradshaw) Date: Sat, 30 May 2015 23:19:11 -0700 Subject: [Cython] Exporting inline functions from a pyx. In-Reply-To: <556AA01D.4070605@behnel.de> References: <556AA01D.4070605@behnel.de> Message-ID: On Sat, May 30, 2015 at 10:46 PM, Stefan Behnel wrote: > Jesus-Omar Ocegueda-Gonzalez schrieb am 27.05.2015 um 04:17: >> we recently faced an issue exporting >> inline functions defined in a .pyx. According to this: >> http://docs.cython.org/src/tutorial/pxd_files.html >> the full inline definition (not just the declaration) should be in the pxd. >> However, if we put the definition in the .pyx and just its declaration >> header in the .pxd, Cython declares a pointer to the inline function >> similar to: >> >> static CYTHON_INLINE double (*__function_name)(...); /*proto*/ >> >> but this causes a compilation error in some platforms (but successfully >> compiles in others) because variables cannot be declare as inline. > > Thanks for the report, I agree that this looks like a bug. I'm not entirely > sure what the best fix is. We could make it an error if an external > function declaration in a .pxd file is declared "inline", or we could just > ignore the modifier for external functions on the import side. > > The first case would be more correct, but we'd end up with different > declarations in the .pyx and .pxd files. That might be difficult to explain > to users that run into this problem, as they would first have to understand > that they can still declare their function "inline" in the .pyx file, just > not in the .pxd. Just copying the function header over in order to export > it will make your code fail to compile. > > But the second case might also not be without surprises ("why doesn't my > 'inline' declaration work here?"), and it leaks implementation details into > the .pxd. I'm thus leaning towards the first. I guess it just depends on > coming up with a clear error message. (Well, after detecting this case in > the first place...) The first also has the disadvantage that one can't create an inline function that is exported as an imported function elsewhere...