Re: [Cython] Cython 0.15 release
On 20 July 2011 02:32, Robert Bradshaw wrote: > We're long overdue for a release, and this week would be a good one > for me to push one out. Hudson > https://sage.math.washington.edu:8091/hudson is looking in pretty good > shape, and though I know we've got a big pile of stuff currently in > progress, we've also got a big backlog of stuff to get out. I'd like > to finish looking at https://github.com/cython/cython/pull/38 , are > there any other changes that people want to urgently get in? Also, > I've started http://wiki.cython.org/ReleaseNotes-0.15 , feel free to > edit if you think anything should be highlighted. I think cpdef enum is a rather small but still very useful change for many people. > > - Robert > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.15 release
mark florisson, 20.07.2011 10:51: On 20 July 2011 02:32, Robert Bradshaw wrote: We're long overdue for a release, and this week would be a good one for me to push one out. Hudson https://sage.math.washington.edu:8091/hudson is looking in pretty good shape, and though I know we've got a big pile of stuff currently in progress, we've also got a big backlog of stuff to get out. I'd like to finish looking at https://github.com/cython/cython/pull/38 , are there any other changes that people want to urgently get in? Also, I've started http://wiki.cython.org/ReleaseNotes-0.15 , feel free to edit if you think anything should be highlighted. I think cpdef enum is a rather small but still very useful change for many people. Did we agree on the right syntax yet? We should be sure about that before adding a new syntax feature to the language that we won't be able to change later on. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.15 release
On 20 July 2011 11:26, Stefan Behnel wrote: > mark florisson, 20.07.2011 10:51: >> >> On 20 July 2011 02:32, Robert Bradshaw wrote: >>> >>> We're long overdue for a release, and this week would be a good one >>> for me to push one out. Hudson >>> https://sage.math.washington.edu:8091/hudson is looking in pretty good >>> shape, and though I know we've got a big pile of stuff currently in >>> progress, we've also got a big backlog of stuff to get out. I'd like >>> to finish looking at https://github.com/cython/cython/pull/38 , are >>> there any other changes that people want to urgently get in? Also, >>> I've started http://wiki.cython.org/ReleaseNotes-0.15 , feel free to >>> edit if you think anything should be highlighted. >> >> I think cpdef enum is a rather small but still very useful change for >> many people. > > Did we agree on the right syntax yet? We should be sure about that before > adding a new syntax feature to the language that we won't be able to change > later on. I think we settled on the syntax in the thread called Cython .pxd introspection: listing defined constants, when Trevor was working on it: http://mail.python.org/pipermail/cython-devel/2011-February/35.html It does look like the most sensible syntax to me, as cpdef is about exposing C/Cython-only stuff to Python. > Stefan > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.15 release
mark florisson, 20.07.2011 11:40: On 20 July 2011 11:26, Stefan Behnel wrote: mark florisson, 20.07.2011 10:51: On 20 July 2011 02:32, Robert Bradshaw wrote: We're long overdue for a release, and this week would be a good one for me to push one out. Hudson https://sage.math.washington.edu:8091/hudson is looking in pretty good shape, and though I know we've got a big pile of stuff currently in progress, we've also got a big backlog of stuff to get out. I'd like to finish looking at https://github.com/cython/cython/pull/38 , are there any other changes that people want to urgently get in? Also, I've started http://wiki.cython.org/ReleaseNotes-0.15 , feel free to edit if you think anything should be highlighted. I think cpdef enum is a rather small but still very useful change for many people. Did we agree on the right syntax yet? We should be sure about that before adding a new syntax feature to the language that we won't be able to change later on. I think we settled on the syntax in the thread called Cython .pxd introspection: listing defined constants, when Trevor was working on it: http://mail.python.org/pipermail/cython-devel/2011-February/35.html It does look like the most sensible syntax to me, as cpdef is about exposing C/Cython-only stuff to Python. Ok. Does the current implementation raise syntax errors where appropriate, in order to prevent the syntax from allowing to be applied in unwanted places? What about the "cdef extern: ... cpdef enum" case? Is that to be allowed? I know I'm being pedantic here, but these things matter. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.15 release
On 20 July 2011 11:47, Stefan Behnel wrote: > mark florisson, 20.07.2011 11:40: >> >> On 20 July 2011 11:26, Stefan Behnel wrote: >>> >>> mark florisson, 20.07.2011 10:51: On 20 July 2011 02:32, Robert Bradshaw wrote: > > We're long overdue for a release, and this week would be a good one > for me to push one out. Hudson > https://sage.math.washington.edu:8091/hudson is looking in pretty good > shape, and though I know we've got a big pile of stuff currently in > progress, we've also got a big backlog of stuff to get out. I'd like > to finish looking at https://github.com/cython/cython/pull/38 , are > there any other changes that people want to urgently get in? Also, > I've started http://wiki.cython.org/ReleaseNotes-0.15 , feel free to > edit if you think anything should be highlighted. I think cpdef enum is a rather small but still very useful change for many people. >>> >>> Did we agree on the right syntax yet? We should be sure about that before >>> adding a new syntax feature to the language that we won't be able to >>> change >>> later on. >> >> I think we settled on the syntax in the thread called Cython .pxd >> introspection: listing defined constants, when Trevor was working on >> it: >> http://mail.python.org/pipermail/cython-devel/2011-February/35.html >> >> It does look like the most sensible syntax to me, as cpdef is about >> exposing C/Cython-only stuff to Python. > > Ok. Does the current implementation raise syntax errors where appropriate, > in order to prevent the syntax from allowing to be applied in unwanted > places? What about the "cdef extern: ... cpdef enum" case? Is that to be > allowed? I don't know about the former, but I believe it will raise syntax errors whenever cdef enum would be invalid. I don't know if it checks whether there is a corresponding .pyx when it is cimported, perhaps Vitja can comment on that. Yes, especially cdef extern: cpdef enum is very useful (and implemented), when you want to expose C constants to Python. > I know I'm being pedantic here, but these things matter. > > Stefan > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython 0.15 release
2011/7/20 mark florisson : > On 20 July 2011 11:47, Stefan Behnel wrote: >> mark florisson, 20.07.2011 11:40: >>> >>> On 20 July 2011 11:26, Stefan Behnel wrote: mark florisson, 20.07.2011 10:51: > > On 20 July 2011 02:32, Robert Bradshaw wrote: >> >> We're long overdue for a release, and this week would be a good one >> for me to push one out. Hudson >> https://sage.math.washington.edu:8091/hudson is looking in pretty good >> shape, and though I know we've got a big pile of stuff currently in >> progress, we've also got a big backlog of stuff to get out. I'd like >> to finish looking at https://github.com/cython/cython/pull/38 , are >> there any other changes that people want to urgently get in? Also, >> I've started http://wiki.cython.org/ReleaseNotes-0.15 , feel free to >> edit if you think anything should be highlighted. > > I think cpdef enum is a rather small but still very useful change for > many people. Did we agree on the right syntax yet? We should be sure about that before adding a new syntax feature to the language that we won't be able to change later on. >>> >>> I think we settled on the syntax in the thread called Cython .pxd >>> introspection: listing defined constants, when Trevor was working on >>> it: >>> http://mail.python.org/pipermail/cython-devel/2011-February/35.html >>> >>> It does look like the most sensible syntax to me, as cpdef is about >>> exposing C/Cython-only stuff to Python. >> >> Ok. Does the current implementation raise syntax errors where appropriate, >> in order to prevent the syntax from allowing to be applied in unwanted >> places? What about the "cdef extern: ... cpdef enum" case? Is that to be >> allowed? > > I don't know about the former, but I believe it will raise syntax > errors whenever cdef enum would be invalid. I don't know if it checks > whether there is a corresponding .pyx when it is cimported, perhaps > Vitja can comment on that. > Actually I don't. My change simply allows cpdef enum and doesn't do context checking. So it's better to write some tests for this. > Yes, especially cdef extern: cpdef enum is very useful (and > implemented), when you want to expose C constants to Python. > Yes, this works, but I do worry about it https://github.com/vitek/cython/commit/471c41a7b37728b1b8844ea13d64b892530f403d I've changed CDefExternNode.generate_execution_code() to call body.generate_execution_code() And I'm not sure if it generates unwanted code. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] How to define C-consts in python module scope
On 19 July 2011 20:48, Robert Bradshaw wrote: > On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin wrote: >> On 19 July 2011 02:24, Vitja Makarov wrote: >>> 2011/7/18 Robert Bradshaw : Trevor King and I discussed this quite a while back, but every time I got around to looking at his code (I don't think he ever created a formal pull request) something came up. The idea was that we could support cpdef structs and extern functions as well. >>> >>> That's interesting, I think I shouldn't hurry with my pull request. >>> >>> 2011/7/19 Robert Bradshaw : On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing wrote: > My suggestion is > > cdef exposed enum: > ... I agree, public is an overloaded word. This meaning is analogous to its use for cdef class members. Perhaps we should use "api" for api generation, and public used for Python-level access, with cpdef being the preferred form for declaring Python-accessible types. >>> >>> It seems to me that cpdef is more cythonic but exposed could be used >>> in this case: >>> >>> cdef extern from "ev.h": >>> exposed enum: >>> EV_READ >>> EV_WRITE >>> >> >> And what about this? >> >> cdef extern from "ev.h": >> cpdef enum: >> EV_READ >> EV_WRITE > > Yep, exactly. > >> BTW, how is this supposed to work with *.pxd files? I think the values >> will be exposed just in the matching implementation .pyx file, and not >> with cimport, right? > > It would be an error unless there's an corresponding .pyx file (which > could be empty). The idea is that one could also define extern cpdef > functions and structs and wrappers would be provided. > It would be an error? What do you mean? if you cpdef enum in foo.pxd, and have foo.pyx, then the enumerations should be exposed in the 'foo' module. But then if you "cimport foo" in bar.pyx, that should succeed but the enumerations should not be exposed in the "bar" module... Am I missing something? -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169 ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] How to define C-consts in python module scope
On 20 July 2011 18:06, Lisandro Dalcin wrote: > On 19 July 2011 20:48, Robert Bradshaw wrote: >> On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin wrote: >>> On 19 July 2011 02:24, Vitja Makarov wrote: 2011/7/18 Robert Bradshaw : > Trevor King and I discussed this quite a while back, but every time I > got around to looking at his code (I don't think he ever created a > formal pull request) something came up. The idea was that we could > support cpdef structs and extern functions as well. > That's interesting, I think I shouldn't hurry with my pull request. 2011/7/19 Robert Bradshaw : > On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing > wrote: >> My suggestion is >> >> cdef exposed enum: >> ... > > I agree, public is an overloaded word. This meaning is analogous to > its use for cdef class members. Perhaps we should use "api" for api > generation, and public used for Python-level access, with cpdef being > the preferred form for declaring Python-accessible types. > It seems to me that cpdef is more cythonic but exposed could be used in this case: cdef extern from "ev.h": exposed enum: EV_READ EV_WRITE >>> >>> And what about this? >>> >>> cdef extern from "ev.h": >>> cpdef enum: >>> EV_READ >>> EV_WRITE >> >> Yep, exactly. >> >>> BTW, how is this supposed to work with *.pxd files? I think the values >>> will be exposed just in the matching implementation .pyx file, and not >>> with cimport, right? >> >> It would be an error unless there's an corresponding .pyx file (which >> could be empty). The idea is that one could also define extern cpdef >> functions and structs and wrappers would be provided. >> > > It would be an error? What do you mean? if you cpdef enum in foo.pxd, > and have foo.pyx, then the enumerations should be exposed in the 'foo' > module. But then if you "cimport foo" in bar.pyx, that should succeed > but the enumerations should not be exposed in the "bar" module... Am I > missing something? > I believe Robert confirmed what you said and added to that that it would be an error to have a cpdef extern enum in a .pxd without a corresponding .pyx file. > -- > Lisandro Dalcin > --- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169 > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] How to define C-consts in python module scope
On 20 July 2011 13:51, mark florisson wrote: > On 20 July 2011 18:06, Lisandro Dalcin wrote: >> On 19 July 2011 20:48, Robert Bradshaw wrote: >>> On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin wrote: On 19 July 2011 02:24, Vitja Makarov wrote: > 2011/7/18 Robert Bradshaw : >> Trevor King and I discussed this quite a while back, but every time I >> got around to looking at his code (I don't think he ever created a >> formal pull request) something came up. The idea was that we could >> support cpdef structs and extern functions as well. >> > > That's interesting, I think I shouldn't hurry with my pull request. > > 2011/7/19 Robert Bradshaw : >> On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing >> wrote: >>> My suggestion is >>> >>> cdef exposed enum: >>> ... >> >> I agree, public is an overloaded word. This meaning is analogous to >> its use for cdef class members. Perhaps we should use "api" for api >> generation, and public used for Python-level access, with cpdef being >> the preferred form for declaring Python-accessible types. >> > > It seems to me that cpdef is more cythonic but exposed could be used > in this case: > > cdef extern from "ev.h": > exposed enum: > EV_READ > EV_WRITE > And what about this? cdef extern from "ev.h": cpdef enum: EV_READ EV_WRITE >>> >>> Yep, exactly. >>> BTW, how is this supposed to work with *.pxd files? I think the values will be exposed just in the matching implementation .pyx file, and not with cimport, right? >>> >>> It would be an error unless there's an corresponding .pyx file (which >>> could be empty). The idea is that one could also define extern cpdef >>> functions and structs and wrappers would be provided. >>> >> >> It would be an error? What do you mean? if you cpdef enum in foo.pxd, >> and have foo.pyx, then the enumerations should be exposed in the 'foo' >> module. But then if you "cimport foo" in bar.pyx, that should succeed >> but the enumerations should not be exposed in the "bar" module... Am I >> missing something? >> > > I believe Robert confirmed what you said and added to that that it > would be an error to have a cpdef extern enum in a .pxd without a > corresponding .pyx file. > But what an "error" means? Cython is going to fail compilation? Suppose I develop a package, and at setup.py install time my package installs somewhere a .pxd full of definitions in such a way that third-party code can cimport it. Then, while writing the third party code, you cimport the my package .pxd, and obviously there is no .pyx for my package, as you are writing YOUR code. What's going to happen in this case? -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169 ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] How to define C-consts in python module scope
On 20 July 2011 20:04, Lisandro Dalcin wrote: > On 20 July 2011 13:51, mark florisson wrote: >> On 20 July 2011 18:06, Lisandro Dalcin wrote: >>> On 19 July 2011 20:48, Robert Bradshaw wrote: On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin wrote: > On 19 July 2011 02:24, Vitja Makarov wrote: >> 2011/7/18 Robert Bradshaw : >>> Trevor King and I discussed this quite a while back, but every time I >>> got around to looking at his code (I don't think he ever created a >>> formal pull request) something came up. The idea was that we could >>> support cpdef structs and extern functions as well. >>> >> >> That's interesting, I think I shouldn't hurry with my pull request. >> >> 2011/7/19 Robert Bradshaw : >>> On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing >>> wrote: My suggestion is cdef exposed enum: ... >>> >>> I agree, public is an overloaded word. This meaning is analogous to >>> its use for cdef class members. Perhaps we should use "api" for api >>> generation, and public used for Python-level access, with cpdef being >>> the preferred form for declaring Python-accessible types. >>> >> >> It seems to me that cpdef is more cythonic but exposed could be used >> in this case: >> >> cdef extern from "ev.h": >> exposed enum: >> EV_READ >> EV_WRITE >> > > And what about this? > > cdef extern from "ev.h": > cpdef enum: > EV_READ > EV_WRITE Yep, exactly. > BTW, how is this supposed to work with *.pxd files? I think the values > will be exposed just in the matching implementation .pyx file, and not > with cimport, right? It would be an error unless there's an corresponding .pyx file (which could be empty). The idea is that one could also define extern cpdef functions and structs and wrappers would be provided. >>> >>> It would be an error? What do you mean? if you cpdef enum in foo.pxd, >>> and have foo.pyx, then the enumerations should be exposed in the 'foo' >>> module. But then if you "cimport foo" in bar.pyx, that should succeed >>> but the enumerations should not be exposed in the "bar" module... Am I >>> missing something? >>> >> >> I believe Robert confirmed what you said and added to that that it >> would be an error to have a cpdef extern enum in a .pxd without a >> corresponding .pyx file. >> > > But what an "error" means? Cython is going to fail compilation? > Suppose I develop a package, and at setup.py install time my package > installs somewhere a .pxd full of definitions in such a way that > third-party code can cimport it. Then, while writing the third party > code, you cimport the my package .pxd, and obviously there is no .pyx > for my package, as you are writing YOUR code. What's going to happen > in this case? If you want to use cpdef in your .pxd, it means you want to expose those to Python. This means they must be importable from Python, which means you need an extension module that exposes the constants, which means you need a .pyx. So you ship a (possibly empty) .pyx file along with your .pxd. If you don't want to expose them to Python but only to Cython, don't use cpdef. This compile time error would be issued whenever a user does a cimport of a .pxd file that has a cpdef enum with no corresponding .pyx file, i.e. the pxd is unusable, you wouldn't ship it in the first place. > > -- > Lisandro Dalcin > --- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169 > ___ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] How to define C-consts in python module scope
On 20 July 2011 15:32, mark florisson wrote:
> On 20 July 2011 20:04, Lisandro Dalcin wrote:
>> On 20 July 2011 13:51, mark florisson wrote:
>>> On 20 July 2011 18:06, Lisandro Dalcin wrote:
On 19 July 2011 20:48, Robert Bradshaw
wrote:
> On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin
> wrote:
>> On 19 July 2011 02:24, Vitja Makarov wrote:
>>> 2011/7/18 Robert Bradshaw :
Trevor King and I discussed this quite a while back, but every time I
got around to looking at his code (I don't think he ever created a
formal pull request) something came up. The idea was that we could
support cpdef structs and extern functions as well.
>>>
>>> That's interesting, I think I shouldn't hurry with my pull request.
>>>
>>> 2011/7/19 Robert Bradshaw :
On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing
wrote:
> My suggestion is
>
> cdef exposed enum:
> ...
I agree, public is an overloaded word. This meaning is analogous to
its use for cdef class members. Perhaps we should use "api" for api
generation, and public used for Python-level access, with cpdef being
the preferred form for declaring Python-accessible types.
>>>
>>> It seems to me that cpdef is more cythonic but exposed could be used
>>> in this case:
>>>
>>> cdef extern from "ev.h":
>>> exposed enum:
>>> EV_READ
>>> EV_WRITE
>>>
>>
>> And what about this?
>>
>> cdef extern from "ev.h":
>> cpdef enum:
>> EV_READ
>> EV_WRITE
>
> Yep, exactly.
>
>> BTW, how is this supposed to work with *.pxd files? I think the values
>> will be exposed just in the matching implementation .pyx file, and not
>> with cimport, right?
>
> It would be an error unless there's an corresponding .pyx file (which
> could be empty). The idea is that one could also define extern cpdef
> functions and structs and wrappers would be provided.
>
It would be an error? What do you mean? if you cpdef enum in foo.pxd,
and have foo.pyx, then the enumerations should be exposed in the 'foo'
module. But then if you "cimport foo" in bar.pyx, that should succeed
but the enumerations should not be exposed in the "bar" module... Am I
missing something?
>>>
>>> I believe Robert confirmed what you said and added to that that it
>>> would be an error to have a cpdef extern enum in a .pxd without a
>>> corresponding .pyx file.
>>>
>>
>> But what an "error" means? Cython is going to fail compilation?
>> Suppose I develop a package, and at setup.py install time my package
>> installs somewhere a .pxd full of definitions in such a way that
>> third-party code can cimport it. Then, while writing the third party
>> code, you cimport the my package .pxd, and obviously there is no .pyx
>> for my package, as you are writing YOUR code. What's going to happen
>> in this case?
>
> If you want to use cpdef in your .pxd, it means you want to expose
> those to Python. This means they must be importable from Python, which
> means you need an extension module that exposes the constants, which
> means you need a .pyx. So you ship a (possibly empty) .pyx file along
> with your .pxd. If you don't want to expose them to Python but only to
> Cython, don't use cpdef. This compile time error would be issued
> whenever a user does a cimport of a .pxd file that has a cpdef enum
> with no corresponding .pyx file, i.e. the pxd is unusable, you
> wouldn't ship it in the first place.
>
So supose I want to write a small wrapper for dlopen(), then I do:
# dl.pxd
cdef from extern from "dlfcn.h":
cpdef enum: RTLD_GLOBAL
void * dlopen()(const char *filename, int flag);
# dl.pyx
def open(filename, mode):
cdef void *handle = c_dlopen(fiename,handle)
return handle
Then the "dl" module namespace contains "dlopen" and "RTLD_GLOBAL"
Now, suppose I code my setup.py to build the ext module and install
dl.pxd as package data.
Now a user runs "pip install dl" and installs my package. She wants to
reuse my .pxd (installed somewhere) for calling dlopen() in its own
Cython code:
# user.pyx
from dl cimport RTLD_GLOBAL, c_dlopen
dlopen("somelibrary.so", RTLD_GLOBAL)
So the user code is going to fail? Then I cannot take advantage of
cpdef enum for developing my "dl" module, I have to go back to
manually exposing the enumerations
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] How to define C-consts in python module scope
On 20 July 2011 21:13, Lisandro Dalcin wrote:
> On 20 July 2011 15:32, mark florisson wrote:
>> On 20 July 2011 20:04, Lisandro Dalcin wrote:
>>> On 20 July 2011 13:51, mark florisson wrote:
On 20 July 2011 18:06, Lisandro Dalcin wrote:
> On 19 July 2011 20:48, Robert Bradshaw
> wrote:
>> On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin
>> wrote:
>>> On 19 July 2011 02:24, Vitja Makarov wrote:
2011/7/18 Robert Bradshaw :
> Trevor King and I discussed this quite a while back, but every time I
> got around to looking at his code (I don't think he ever created a
> formal pull request) something came up. The idea was that we could
> support cpdef structs and extern functions as well.
>
That's interesting, I think I shouldn't hurry with my pull request.
2011/7/19 Robert Bradshaw :
> On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing
> wrote:
>> My suggestion is
>>
>> cdef exposed enum:
>> ...
>
> I agree, public is an overloaded word. This meaning is analogous to
> its use for cdef class members. Perhaps we should use "api" for api
> generation, and public used for Python-level access, with cpdef being
> the preferred form for declaring Python-accessible types.
>
It seems to me that cpdef is more cythonic but exposed could be used
in this case:
cdef extern from "ev.h":
exposed enum:
EV_READ
EV_WRITE
>>>
>>> And what about this?
>>>
>>> cdef extern from "ev.h":
>>> cpdef enum:
>>> EV_READ
>>> EV_WRITE
>>
>> Yep, exactly.
>>
>>> BTW, how is this supposed to work with *.pxd files? I think the values
>>> will be exposed just in the matching implementation .pyx file, and not
>>> with cimport, right?
>>
>> It would be an error unless there's an corresponding .pyx file (which
>> could be empty). The idea is that one could also define extern cpdef
>> functions and structs and wrappers would be provided.
>>
>
> It would be an error? What do you mean? if you cpdef enum in foo.pxd,
> and have foo.pyx, then the enumerations should be exposed in the 'foo'
> module. But then if you "cimport foo" in bar.pyx, that should succeed
> but the enumerations should not be exposed in the "bar" module... Am I
> missing something?
>
I believe Robert confirmed what you said and added to that that it
would be an error to have a cpdef extern enum in a .pxd without a
corresponding .pyx file.
>>>
>>> But what an "error" means? Cython is going to fail compilation?
>>> Suppose I develop a package, and at setup.py install time my package
>>> installs somewhere a .pxd full of definitions in such a way that
>>> third-party code can cimport it. Then, while writing the third party
>>> code, you cimport the my package .pxd, and obviously there is no .pyx
>>> for my package, as you are writing YOUR code. What's going to happen
>>> in this case?
>>
>> If you want to use cpdef in your .pxd, it means you want to expose
>> those to Python. This means they must be importable from Python, which
>> means you need an extension module that exposes the constants, which
>> means you need a .pyx. So you ship a (possibly empty) .pyx file along
>> with your .pxd. If you don't want to expose them to Python but only to
>> Cython, don't use cpdef. This compile time error would be issued
>> whenever a user does a cimport of a .pxd file that has a cpdef enum
>> with no corresponding .pyx file, i.e. the pxd is unusable, you
>> wouldn't ship it in the first place.
>>
>
> So supose I want to write a small wrapper for dlopen(), then I do:
>
> # dl.pxd
> cdef from extern from "dlfcn.h":
> cpdef enum: RTLD_GLOBAL
> void * dlopen()(const char *filename, int flag);
>
> # dl.pyx
> def open(filename, mode):
> cdef void *handle = c_dlopen(fiename,handle)
> return handle
>
> Then the "dl" module namespace contains "dlopen" and "RTLD_GLOBAL"
>
> Now, suppose I code my setup.py to build the ext module and install
> dl.pxd as package data.
>
> Now a user runs "pip install dl" and installs my package. She wants to
> reuse my .pxd (installed somewhere) for calling dlopen() in its own
> Cython code:
>
> # user.pyx
> from dl cimport RTLD_GLOBAL, c_dlopen
> dlopen("somelibrary.so", RTLD_GLOBAL)
>
>
> So the user code is going to fail? Then I cannot take advantage of
> cpdef enum for developing my "dl" module, I have to go back to
> manually exposing the enumerations
>
Why can't you ship both dl.pxd and dl.pyx as package data?
>
>
>
> --
> Lisandro Dalcin
> ---
> CIMEC (INTEC/CONICET-UNL)
> Predio CONICET-Santa Fe
> Colectora RN 168 Km 472, Paraje El Pozo
> 3000 Santa Fe, Argentina
> Tel: +54-342-4511594 (ext 1011)
> Te
Re: [Cython] How to define C-consts in python module scope
On 20 July 2011 16:27, mark florisson wrote:
> On 20 July 2011 21:13, Lisandro Dalcin wrote:
>> On 20 July 2011 15:32, mark florisson wrote:
>>> On 20 July 2011 20:04, Lisandro Dalcin wrote:
On 20 July 2011 13:51, mark florisson wrote:
> On 20 July 2011 18:06, Lisandro Dalcin wrote:
>> On 19 July 2011 20:48, Robert Bradshaw
>> wrote:
>>> On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin
>>> wrote:
On 19 July 2011 02:24, Vitja Makarov wrote:
> 2011/7/18 Robert Bradshaw :
>> Trevor King and I discussed this quite a while back, but every time I
>> got around to looking at his code (I don't think he ever created a
>> formal pull request) something came up. The idea was that we could
>> support cpdef structs and extern functions as well.
>>
>
> That's interesting, I think I shouldn't hurry with my pull request.
>
> 2011/7/19 Robert Bradshaw :
>> On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing
>> wrote:
>>> My suggestion is
>>>
>>> cdef exposed enum:
>>> ...
>>
>> I agree, public is an overloaded word. This meaning is analogous to
>> its use for cdef class members. Perhaps we should use "api" for api
>> generation, and public used for Python-level access, with cpdef being
>> the preferred form for declaring Python-accessible types.
>>
>
> It seems to me that cpdef is more cythonic but exposed could be used
> in this case:
>
> cdef extern from "ev.h":
> exposed enum:
> EV_READ
> EV_WRITE
>
And what about this?
cdef extern from "ev.h":
cpdef enum:
EV_READ
EV_WRITE
>>>
>>> Yep, exactly.
>>>
BTW, how is this supposed to work with *.pxd files? I think the values
will be exposed just in the matching implementation .pyx file, and not
with cimport, right?
>>>
>>> It would be an error unless there's an corresponding .pyx file (which
>>> could be empty). The idea is that one could also define extern cpdef
>>> functions and structs and wrappers would be provided.
>>>
>>
>> It would be an error? What do you mean? if you cpdef enum in foo.pxd,
>> and have foo.pyx, then the enumerations should be exposed in the 'foo'
>> module. But then if you "cimport foo" in bar.pyx, that should succeed
>> but the enumerations should not be exposed in the "bar" module... Am I
>> missing something?
>>
>
> I believe Robert confirmed what you said and added to that that it
> would be an error to have a cpdef extern enum in a .pxd without a
> corresponding .pyx file.
>
But what an "error" means? Cython is going to fail compilation?
Suppose I develop a package, and at setup.py install time my package
installs somewhere a .pxd full of definitions in such a way that
third-party code can cimport it. Then, while writing the third party
code, you cimport the my package .pxd, and obviously there is no .pyx
for my package, as you are writing YOUR code. What's going to happen
in this case?
>>>
>>> If you want to use cpdef in your .pxd, it means you want to expose
>>> those to Python. This means they must be importable from Python, which
>>> means you need an extension module that exposes the constants, which
>>> means you need a .pyx. So you ship a (possibly empty) .pyx file along
>>> with your .pxd. If you don't want to expose them to Python but only to
>>> Cython, don't use cpdef. This compile time error would be issued
>>> whenever a user does a cimport of a .pxd file that has a cpdef enum
>>> with no corresponding .pyx file, i.e. the pxd is unusable, you
>>> wouldn't ship it in the first place.
>>>
>>
>> So supose I want to write a small wrapper for dlopen(), then I do:
>>
>> # dl.pxd
>> cdef from extern from "dlfcn.h":
>> cpdef enum: RTLD_GLOBAL
>> void * dlopen()(const char *filename, int flag);
>>
>> # dl.pyx
>> def open(filename, mode):
>> cdef void *handle = c_dlopen(fiename,handle)
>> return handle
>>
>> Then the "dl" module namespace contains "dlopen" and "RTLD_GLOBAL"
>>
>> Now, suppose I code my setup.py to build the ext module and install
>> dl.pxd as package data.
>>
>> Now a user runs "pip install dl" and installs my package. She wants to
>> reuse my .pxd (installed somewhere) for calling dlopen() in its own
>> Cython code:
>>
>> # user.pyx
>> from dl cimport RTLD_GLOBAL, c_dlopen
>> dlopen("somelibrary.so", RTLD_GLOBAL)
>>
>>
>> So the user code is going to fail? Then I cannot take advantage of
>> cpdef enum for developing my "dl" module, I have to go back to
>> manually exposing the enumerations
>>
>
> Why can't you ship both dl.pxd and dl.pyx as package data?
>
This is like asking to provide a C
Re: [Cython] How to define C-consts in python module scope
On 20 July 2011 21:44, Lisandro Dalcin wrote:
> On 20 July 2011 16:27, mark florisson wrote:
>> On 20 July 2011 21:13, Lisandro Dalcin wrote:
>>> On 20 July 2011 15:32, mark florisson wrote:
On 20 July 2011 20:04, Lisandro Dalcin wrote:
> On 20 July 2011 13:51, mark florisson wrote:
>> On 20 July 2011 18:06, Lisandro Dalcin wrote:
>>> On 19 July 2011 20:48, Robert Bradshaw
>>> wrote:
On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin
wrote:
> On 19 July 2011 02:24, Vitja Makarov wrote:
>> 2011/7/18 Robert Bradshaw :
>>> Trevor King and I discussed this quite a while back, but every time
>>> I
>>> got around to looking at his code (I don't think he ever created a
>>> formal pull request) something came up. The idea was that we could
>>> support cpdef structs and extern functions as well.
>>>
>>
>> That's interesting, I think I shouldn't hurry with my pull request.
>>
>> 2011/7/19 Robert Bradshaw :
>>> On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing
>>> wrote:
My suggestion is
cdef exposed enum:
...
>>>
>>> I agree, public is an overloaded word. This meaning is analogous to
>>> its use for cdef class members. Perhaps we should use "api" for api
>>> generation, and public used for Python-level access, with cpdef
>>> being
>>> the preferred form for declaring Python-accessible types.
>>>
>>
>> It seems to me that cpdef is more cythonic but exposed could be used
>> in this case:
>>
>> cdef extern from "ev.h":
>> exposed enum:
>> EV_READ
>> EV_WRITE
>>
>
> And what about this?
>
> cdef extern from "ev.h":
> cpdef enum:
> EV_READ
> EV_WRITE
Yep, exactly.
> BTW, how is this supposed to work with *.pxd files? I think the values
> will be exposed just in the matching implementation .pyx file, and not
> with cimport, right?
It would be an error unless there's an corresponding .pyx file (which
could be empty). The idea is that one could also define extern cpdef
functions and structs and wrappers would be provided.
>>>
>>> It would be an error? What do you mean? if you cpdef enum in foo.pxd,
>>> and have foo.pyx, then the enumerations should be exposed in the 'foo'
>>> module. But then if you "cimport foo" in bar.pyx, that should succeed
>>> but the enumerations should not be exposed in the "bar" module... Am I
>>> missing something?
>>>
>>
>> I believe Robert confirmed what you said and added to that that it
>> would be an error to have a cpdef extern enum in a .pxd without a
>> corresponding .pyx file.
>>
>
> But what an "error" means? Cython is going to fail compilation?
> Suppose I develop a package, and at setup.py install time my package
> installs somewhere a .pxd full of definitions in such a way that
> third-party code can cimport it. Then, while writing the third party
> code, you cimport the my package .pxd, and obviously there is no .pyx
> for my package, as you are writing YOUR code. What's going to happen
> in this case?
If you want to use cpdef in your .pxd, it means you want to expose
those to Python. This means they must be importable from Python, which
means you need an extension module that exposes the constants, which
means you need a .pyx. So you ship a (possibly empty) .pyx file along
with your .pxd. If you don't want to expose them to Python but only to
Cython, don't use cpdef. This compile time error would be issued
whenever a user does a cimport of a .pxd file that has a cpdef enum
with no corresponding .pyx file, i.e. the pxd is unusable, you
wouldn't ship it in the first place.
>>>
>>> So supose I want to write a small wrapper for dlopen(), then I do:
>>>
>>> # dl.pxd
>>> cdef from extern from "dlfcn.h":
>>> cpdef enum: RTLD_GLOBAL
>>> void * dlopen()(const char *filename, int flag);
>>>
>>> # dl.pyx
>>> def open(filename, mode):
>>> cdef void *handle = c_dlopen(fiename,handle)
>>> return handle
>>>
>>> Then the "dl" module namespace contains "dlopen" and "RTLD_GLOBAL"
>>>
>>> Now, suppose I code my setup.py to build the ext module and install
>>> dl.pxd as package data.
>>>
>>> Now a user runs "pip install dl" and installs my package. She wants to
>>> reuse my .pxd (installed somewhere) for calling dlopen() in its own
>>> Cython code:
>>>
>>> # user.pyx
>>> from dl cimport RTLD_GLOBAL, c_dlopen
>>> dlopen("somelibrary.so", RTLD_GLOBAL)
>>>
>>>
>>> So the user code is going to fail? Then I cannot take advantage of
>>> cpdef enum f
Re: [Cython] How to define C-consts in python module scope
On Wed, Jul 20, 2011 at 12:53 PM, mark florisson wrote: > On 20 July 2011 21:44, Lisandro Dalcin wrote: >> On 20 July 2011 16:27, mark florisson wrote: >>> On 20 July 2011 21:13, Lisandro Dalcin wrote: On 20 July 2011 15:32, mark florisson wrote: > On 20 July 2011 20:04, Lisandro Dalcin wrote: >> On 20 July 2011 13:51, mark florisson wrote: >>> On 20 July 2011 18:06, Lisandro Dalcin wrote: On 19 July 2011 20:48, Robert Bradshaw wrote: > On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin > wrote: >> On 19 July 2011 02:24, Vitja Makarov wrote: >>> 2011/7/18 Robert Bradshaw : Trevor King and I discussed this quite a while back, but every time I got around to looking at his code (I don't think he ever created a formal pull request) something came up. The idea was that we could support cpdef structs and extern functions as well. >>> >>> That's interesting, I think I shouldn't hurry with my pull request. >>> >>> 2011/7/19 Robert Bradshaw : On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing wrote: > My suggestion is > > cdef exposed enum: > ... I agree, public is an overloaded word. This meaning is analogous to its use for cdef class members. Perhaps we should use "api" for api generation, and public used for Python-level access, with cpdef being the preferred form for declaring Python-accessible types. >>> >>> It seems to me that cpdef is more cythonic but exposed could be used >>> in this case: >>> >>> cdef extern from "ev.h": >>> exposed enum: >>> EV_READ >>> EV_WRITE >>> >> >> And what about this? >> >> cdef extern from "ev.h": >> cpdef enum: >> EV_READ >> EV_WRITE > > Yep, exactly. > >> BTW, how is this supposed to work with *.pxd files? I think the >> values >> will be exposed just in the matching implementation .pyx file, and >> not >> with cimport, right? > > It would be an error unless there's an corresponding .pyx file (which > could be empty). The idea is that one could also define extern cpdef > functions and structs and wrappers would be provided. > It would be an error? What do you mean? if you cpdef enum in foo.pxd, and have foo.pyx, then the enumerations should be exposed in the 'foo' module. But then if you "cimport foo" in bar.pyx, that should succeed but the enumerations should not be exposed in the "bar" module... Am I missing something? >>> >>> I believe Robert confirmed what you said and added to that that it >>> would be an error to have a cpdef extern enum in a .pxd without a >>> corresponding .pyx file. >>> >> >> But what an "error" means? Cython is going to fail compilation? >> Suppose I develop a package, and at setup.py install time my package >> installs somewhere a .pxd full of definitions in such a way that >> third-party code can cimport it. Then, while writing the third party >> code, you cimport the my package .pxd, and obviously there is no .pyx >> for my package, as you are writing YOUR code. What's going to happen >> in this case? > > If you want to use cpdef in your .pxd, it means you want to expose > those to Python. This means they must be importable from Python, which > means you need an extension module that exposes the constants, which > means you need a .pyx. So you ship a (possibly empty) .pyx file along > with your .pxd. If you don't want to expose them to Python but only to > Cython, don't use cpdef. This compile time error would be issued > whenever a user does a cimport of a .pxd file that has a cpdef enum > with no corresponding .pyx file, i.e. the pxd is unusable, you > wouldn't ship it in the first place. Alternatively it would be a runtime error when trying to import the objects. I suppose if cimport does not inject anything into the python namespace, then "cimport" could just work and "import" would work iff the module is available at runtime. So supose I want to write a small wrapper for dlopen(), then I do: # dl.pxd cdef from extern from "dlfcn.h": cpdef enum: RTLD_GLOBAL void * dlopen()(const char *filename, int flag); # dl.pyx def open(filename, mode): cdef void *handle = c_dlopen(fiename,handle) return handle Then the "dl" module namespace contains "dlopen" and "RTLD_GLOBAL" Now, suppose I code my setup.py to
Re: [Cython] How to define C-consts in python module scope
On 20 July 2011 23:24, Robert Bradshaw wrote: > On Wed, Jul 20, 2011 at 12:53 PM, mark florisson > wrote: >> On 20 July 2011 21:44, Lisandro Dalcin wrote: >>> On 20 July 2011 16:27, mark florisson wrote: On 20 July 2011 21:13, Lisandro Dalcin wrote: > On 20 July 2011 15:32, mark florisson wrote: >> On 20 July 2011 20:04, Lisandro Dalcin wrote: >>> On 20 July 2011 13:51, mark florisson wrote: On 20 July 2011 18:06, Lisandro Dalcin wrote: > On 19 July 2011 20:48, Robert Bradshaw > wrote: >> On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin >> wrote: >>> On 19 July 2011 02:24, Vitja Makarov >>> wrote: 2011/7/18 Robert Bradshaw : > Trevor King and I discussed this quite a while back, but every > time I > got around to looking at his code (I don't think he ever created a > formal pull request) something came up. The idea was that we could > support cpdef structs and extern functions as well. > That's interesting, I think I shouldn't hurry with my pull request. 2011/7/19 Robert Bradshaw : > On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing > wrote: >> My suggestion is >> >> cdef exposed enum: >> ... > > I agree, public is an overloaded word. This meaning is analogous > to > its use for cdef class members. Perhaps we should use "api" for > api > generation, and public used for Python-level access, with cpdef > being > the preferred form for declaring Python-accessible types. > It seems to me that cpdef is more cythonic but exposed could be used in this case: cdef extern from "ev.h": exposed enum: EV_READ EV_WRITE >>> >>> And what about this? >>> >>> cdef extern from "ev.h": >>> cpdef enum: >>> EV_READ >>> EV_WRITE >> >> Yep, exactly. >> >>> BTW, how is this supposed to work with *.pxd files? I think the >>> values >>> will be exposed just in the matching implementation .pyx file, and >>> not >>> with cimport, right? >> >> It would be an error unless there's an corresponding .pyx file (which >> could be empty). The idea is that one could also define extern cpdef >> functions and structs and wrappers would be provided. >> > > It would be an error? What do you mean? if you cpdef enum in foo.pxd, > and have foo.pyx, then the enumerations should be exposed in the 'foo' > module. But then if you "cimport foo" in bar.pyx, that should succeed > but the enumerations should not be exposed in the "bar" module... Am I > missing something? > I believe Robert confirmed what you said and added to that that it would be an error to have a cpdef extern enum in a .pxd without a corresponding .pyx file. >>> >>> But what an "error" means? Cython is going to fail compilation? >>> Suppose I develop a package, and at setup.py install time my package >>> installs somewhere a .pxd full of definitions in such a way that >>> third-party code can cimport it. Then, while writing the third party >>> code, you cimport the my package .pxd, and obviously there is no .pyx >>> for my package, as you are writing YOUR code. What's going to happen >>> in this case? >> >> If you want to use cpdef in your .pxd, it means you want to expose >> those to Python. This means they must be importable from Python, which >> means you need an extension module that exposes the constants, which >> means you need a .pyx. So you ship a (possibly empty) .pyx file along >> with your .pxd. If you don't want to expose them to Python but only to >> Cython, don't use cpdef. This compile time error would be issued >> whenever a user does a cimport of a .pxd file that has a cpdef enum >> with no corresponding .pyx file, i.e. the pxd is unusable, you >> wouldn't ship it in the first place. > > Alternatively it would be a runtime error when trying to import the > objects. I suppose if cimport does not inject anything into the python > namespace, then "cimport" could just work and "import" would work iff > the module is available at runtime. > > So supose I want to write a small wrapper for dlopen(), then I do: > > # dl.pxd > cdef from extern from "dlfcn.h": > cpdef enum: RTLD_GLOBAL > void * dlopen()(const char *filename, int flag); > > # dl.pyx >
Re: [Cython] How to define C-consts in python module scope
On Wed, Jul 20, 2011 at 2:53 PM, mark florisson wrote: > On 20 July 2011 23:24, Robert Bradshaw wrote: >> On Wed, Jul 20, 2011 at 12:53 PM, mark florisson >> wrote: >>> On 20 July 2011 21:44, Lisandro Dalcin wrote: On 20 July 2011 16:27, mark florisson wrote: > On 20 July 2011 21:13, Lisandro Dalcin wrote: >> On 20 July 2011 15:32, mark florisson wrote: >>> On 20 July 2011 20:04, Lisandro Dalcin wrote: On 20 July 2011 13:51, mark florisson wrote: > On 20 July 2011 18:06, Lisandro Dalcin wrote: >> On 19 July 2011 20:48, Robert Bradshaw >> wrote: >>> On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin >>> wrote: On 19 July 2011 02:24, Vitja Makarov wrote: > 2011/7/18 Robert Bradshaw : >> Trevor King and I discussed this quite a while back, but every >> time I >> got around to looking at his code (I don't think he ever created >> a >> formal pull request) something came up. The idea was that we >> could >> support cpdef structs and extern functions as well. >> > > That's interesting, I think I shouldn't hurry with my pull > request. > > 2011/7/19 Robert Bradshaw : >> On Mon, Jul 18, 2011 at 4:34 PM, Greg Ewing >> wrote: >>> My suggestion is >>> >>> cdef exposed enum: >>> ... >> >> I agree, public is an overloaded word. This meaning is analogous >> to >> its use for cdef class members. Perhaps we should use "api" for >> api >> generation, and public used for Python-level access, with cpdef >> being >> the preferred form for declaring Python-accessible types. >> > > It seems to me that cpdef is more cythonic but exposed could be > used > in this case: > > cdef extern from "ev.h": > exposed enum: > EV_READ > EV_WRITE > And what about this? cdef extern from "ev.h": cpdef enum: EV_READ EV_WRITE >>> >>> Yep, exactly. >>> BTW, how is this supposed to work with *.pxd files? I think the values will be exposed just in the matching implementation .pyx file, and not with cimport, right? >>> >>> It would be an error unless there's an corresponding .pyx file >>> (which >>> could be empty). The idea is that one could also define extern cpdef >>> functions and structs and wrappers would be provided. >>> >> >> It would be an error? What do you mean? if you cpdef enum in foo.pxd, >> and have foo.pyx, then the enumerations should be exposed in the >> 'foo' >> module. But then if you "cimport foo" in bar.pyx, that should succeed >> but the enumerations should not be exposed in the "bar" module... Am >> I >> missing something? >> > > I believe Robert confirmed what you said and added to that that it > would be an error to have a cpdef extern enum in a .pxd without a > corresponding .pyx file. > But what an "error" means? Cython is going to fail compilation? Suppose I develop a package, and at setup.py install time my package installs somewhere a .pxd full of definitions in such a way that third-party code can cimport it. Then, while writing the third party code, you cimport the my package .pxd, and obviously there is no .pyx for my package, as you are writing YOUR code. What's going to happen in this case? >>> >>> If you want to use cpdef in your .pxd, it means you want to expose >>> those to Python. This means they must be importable from Python, which >>> means you need an extension module that exposes the constants, which >>> means you need a .pyx. So you ship a (possibly empty) .pyx file along >>> with your .pxd. If you don't want to expose them to Python but only to >>> Cython, don't use cpdef. This compile time error would be issued >>> whenever a user does a cimport of a .pxd file that has a cpdef enum >>> with no corresponding .pyx file, i.e. the pxd is unusable, you >>> wouldn't ship it in the first place. >> >> Alternatively it would be a runtime error when trying to import the >> objects. I suppose if cimport does not inject anything into the python >> namespace, then "cimport" could just work and "import" would work iff >> the module is available at runt
Re: [Cython] Cython 0.15 release
On Wed, Jul 20, 2011 at 2:47 AM, Stefan Behnel wrote: > mark florisson, 20.07.2011 11:40: >> >> On 20 July 2011 11:26, Stefan Behnel wrote: >>> >>> mark florisson, 20.07.2011 10:51: On 20 July 2011 02:32, Robert Bradshaw wrote: > > We're long overdue for a release, and this week would be a good one > for me to push one out. Hudson > https://sage.math.washington.edu:8091/hudson is looking in pretty good > shape, and though I know we've got a big pile of stuff currently in > progress, we've also got a big backlog of stuff to get out. I'd like > to finish looking at https://github.com/cython/cython/pull/38 , are > there any other changes that people want to urgently get in? Also, > I've started http://wiki.cython.org/ReleaseNotes-0.15 , feel free to > edit if you think anything should be highlighted. I think cpdef enum is a rather small but still very useful change for many people. >>> >>> Did we agree on the right syntax yet? We should be sure about that before >>> adding a new syntax feature to the language that we won't be able to >>> change >>> later on. >> >> I think we settled on the syntax in the thread called Cython .pxd >> introspection: listing defined constants, when Trevor was working on >> it: >> http://mail.python.org/pipermail/cython-devel/2011-February/35.html >> >> It does look like the most sensible syntax to me, as cpdef is about >> exposing C/Cython-only stuff to Python. > > Ok. Does the current implementation raise syntax errors where appropriate, > in order to prevent the syntax from allowing to be applied in unwanted > places? What about the "cdef extern: ... cpdef enum" case? Is that to be > allowed? > > I know I'm being pedantic here, but these things matter. In any case, it sounds like there's enough uncertainty to not rush this into the release. - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] How to define C-consts in python module scope
Hi, I think we're getting way off course with this discussion. The following is a good way to get back into a useful direction. Robert Bradshaw, 20.07.2011 23:24: it would be a runtime error when trying to import the objects. I suppose if cimport does not inject anything into the python namespace, then "cimport" could just work and "import" would work iff the module is available at runtime. +1 Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] How to define C-consts in python module scope
On 20 July 2011 23:41, Stefan Behnel wrote: > Hi, > > I think we're getting way off course with this discussion. The following is > a good way to get back into a useful direction. > > Robert Bradshaw, 20.07.2011 23:24: >> >> it would be a runtime error when trying to import the >> objects. I suppose if cimport does not inject anything into the python >> namespace, then "cimport" could just work and "import" would work iff >> the module is available at runtime. > > +1 > +1, too... That was my whole point! -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169 ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Strange cimport behaviour
2011/7/16 Lars Buitinck : > 2011/7/15 Vitja Makarov : >> I've found strange bug. In my example cimport misses "fcntl.h" include: >> >> ((c2f2e12...)) vitja@vitja-laptop:~/work/cython-vitek/zzz$ cat ./fff.pyx >> cimport posix.unistd >> cimport posix.fcntl >> >> print posix.fcntl.O_RDWR > > Fascinating; I can reproduce the error (on Scientific Linux 5.5), but > it goes away when I reverse the order of the includes. > What's about this issue? Is that easy to fix before release or it's better to create a ticket? -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Strange cimport behaviour
On Wed, Jul 20, 2011 at 9:27 PM, Vitja Makarov wrote: > 2011/7/16 Lars Buitinck : >> 2011/7/15 Vitja Makarov : >>> I've found strange bug. In my example cimport misses "fcntl.h" include: >>> >>> ((c2f2e12...)) vitja@vitja-laptop:~/work/cython-vitek/zzz$ cat ./fff.pyx >>> cimport posix.unistd >>> cimport posix.fcntl >>> >>> print posix.fcntl.O_RDWR >> >> Fascinating; I can reproduce the error (on Scientific Linux 5.5), but >> it goes away when I reverse the order of the includes. >> > > What's about this issue? Is that easy to fix before release or it's > better to create a ticket? I'm not sure what we can do here--we make sure to emit the #include statements in the same order as they are encountered in the Cython sources because C is sensitive to this kind of thing, but we can't really "fix" C. I suppose we could cimport posix.fcntl from within posix.unistd to force an ordering. - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Strange cimport behaviour
2011/7/21 Robert Bradshaw : > On Wed, Jul 20, 2011 at 9:27 PM, Vitja Makarov > wrote: >> 2011/7/16 Lars Buitinck : >>> 2011/7/15 Vitja Makarov : I've found strange bug. In my example cimport misses "fcntl.h" include: ((c2f2e12...)) vitja@vitja-laptop:~/work/cython-vitek/zzz$ cat ./fff.pyx cimport posix.unistd cimport posix.fcntl print posix.fcntl.O_RDWR >>> >>> Fascinating; I can reproduce the error (on Scientific Linux 5.5), but >>> it goes away when I reverse the order of the includes. >>> >> >> What's about this issue? Is that easy to fix before release or it's >> better to create a ticket? > > I'm not sure what we can do here--we make sure to emit the #include > statements in the same order as they are encountered in the Cython > sources because C is sensitive to this kind of thing, but we can't > really "fix" C. I suppose we could cimport posix.fcntl from within > posix.unistd to force an ordering. > That's not C bug. That's cython bug. Actualy fcntl.h isn't included at all. That seems to be a problem with cimport and packages. As I said "from posix cimport unistd, fcntl" works just fine. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Strange cimport behaviour
On Wed, Jul 20, 2011 at 9:40 PM, Vitja Makarov wrote: > 2011/7/21 Robert Bradshaw : >> On Wed, Jul 20, 2011 at 9:27 PM, Vitja Makarov >> wrote: >>> 2011/7/16 Lars Buitinck : 2011/7/15 Vitja Makarov : > I've found strange bug. In my example cimport misses "fcntl.h" include: > > ((c2f2e12...)) vitja@vitja-laptop:~/work/cython-vitek/zzz$ cat ./fff.pyx > cimport posix.unistd > cimport posix.fcntl > > print posix.fcntl.O_RDWR Fascinating; I can reproduce the error (on Scientific Linux 5.5), but it goes away when I reverse the order of the includes. >>> >>> What's about this issue? Is that easy to fix before release or it's >>> better to create a ticket? >> >> I'm not sure what we can do here--we make sure to emit the #include >> statements in the same order as they are encountered in the Cython >> sources because C is sensitive to this kind of thing, but we can't >> really "fix" C. I suppose we could cimport posix.fcntl from within >> posix.unistd to force an ordering. >> > > That's not C bug. That's cython bug. Actualy fcntl.h isn't included at all. > That seems to be a problem with cimport and packages. > > As I said "from posix cimport unistd, fcntl" works just fine. I thought you meant that cimport posix.fcntl cimport posix.unistd worked but cimport posix.unistd cimport posix.fcntl didn't. I'm seeing the bug now. (There are of course cases where one does care about import order.) - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
