Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
Stefan Behnel wrote: Given that Cython has "cpdef" already, why not just use that? That seems like a reasonable idea. -- Greg ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
On Sun, Feb 20, 2011 at 1:26 AM, Stefan Behnel wrote: > W. Trevor King, 20.02.2011 00:31: >> >> On Sat, Feb 19, 2011 at 02:04:16PM -0800, Robert Bradshaw wrote: >>> >>> On Sat, Feb 19, 2011 at 1:45 PM, W. Trevor King wrote: It is unclear to me what `cdef public struct` means. I think it should mean "Python bindings can alter this struct's definition", which doesn't make sense. >>> >>> I think it should mean "this struct is accessible from Python (as X)" >> >> Wouldn't that be "cdef readonly struct X"? > > The problem here is that "public" is used differently in different contexts > - usually "exported at the C level" in this kind of context, with the quirk > of meaning "modifiable at the Python level" for cdef class attributes. > > The potentially clearer "cpdef" means "overridable at the Python level" as > well as "visible at the Python level", so it doesn't quite match the second > meaning by itself. > > Structs won't be overridable at the Python level, I guess, so cpdef isn't > quite right. The intention here isn't to export them at the C level either, > so "public" isn't right. > > We could tweak the "cpdef" meaning into "cdef thing mapped to the Python > level, and overridable if supported in the given context", which would lead > to broader applicability. Then we could allow That's what I was thinking. > cpdef readonly struct ... > > I think that's a lot clearer than adding to the double meaning of "public". > I would also prefer if Python accessible cdef class attributes were defined > using "cpdef". We could potentially make that the preferred way in the > future? We could allow it, but -1 to disallowing "cdef class" - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
Robert Bradshaw, 21.02.2011 19:11: On Sun, Feb 20, 2011 at 1:26 AM, Stefan Behnel wrote: W. Trevor King, 20.02.2011 00:31: On Sat, Feb 19, 2011 at 02:04:16PM -0800, Robert Bradshaw wrote: On Sat, Feb 19, 2011 at 1:45 PM, W. Trevor King wrote: It is unclear to me what `cdef public struct` means. I think it should mean "Python bindings can alter this struct's definition", which doesn't make sense. I think it should mean "this struct is accessible from Python (as X)" Wouldn't that be "cdef readonly struct X"? The problem here is that "public" is used differently in different contexts - usually "exported at the C level" in this kind of context, with the quirk of meaning "modifiable at the Python level" for cdef class attributes. The potentially clearer "cpdef" means "overridable at the Python level" as well as "visible at the Python level", so it doesn't quite match the second meaning by itself. Structs won't be overridable at the Python level, I guess, so cpdef isn't quite right. The intention here isn't to export them at the C level either, so "public" isn't right. We could tweak the "cpdef" meaning into "cdef thing mapped to the Python level, and overridable if supported in the given context", which would lead to broader applicability. Then we could allow That's what I was thinking. cpdef readonly struct ... I think that's a lot clearer than adding to the double meaning of "public". I would also prefer if Python accessible cdef class attributes were defined using "cpdef". We could potentially make that the preferred way in the future? We could allow it, but -1 to disallowing "cdef class" With "preferred way", I was suggesting that we could *deprecate* cdef public int x cdef readonly object y for cdef class properties in favour of cpdef int x cpdef readonly object y and change the documentation accordingly etc., so that at least new users get used to the new way. The old way would likely continue to be supported until Cython 2.0 or so, for the holy cow's sake... Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
On 21 February 2011 15:26, Stefan Behnel wrote: > Robert Bradshaw, 21.02.2011 19:11: >> >> On Sun, Feb 20, 2011 at 1:26 AM, Stefan Behnel wrote: >>> >>> W. Trevor King, 20.02.2011 00:31: On Sat, Feb 19, 2011 at 02:04:16PM -0800, Robert Bradshaw wrote: > > On Sat, Feb 19, 2011 at 1:45 PM, W. Trevor King wrote: >> >> It is unclear to me what `cdef public struct` means. I think it >> should mean "Python bindings can alter this struct's definition", >> which doesn't make sense. > > I think it should mean "this struct is accessible from Python (as X)" Wouldn't that be "cdef readonly struct X"? >>> >>> The problem here is that "public" is used differently in different >>> contexts >>> - usually "exported at the C level" in this kind of context, with the >>> quirk >>> of meaning "modifiable at the Python level" for cdef class attributes. >>> >>> The potentially clearer "cpdef" means "overridable at the Python level" >>> as >>> well as "visible at the Python level", so it doesn't quite match the >>> second >>> meaning by itself. >>> >>> Structs won't be overridable at the Python level, I guess, so cpdef isn't >>> quite right. The intention here isn't to export them at the C level >>> either, >>> so "public" isn't right. >>> >>> We could tweak the "cpdef" meaning into "cdef thing mapped to the Python >>> level, and overridable if supported in the given context", which would >>> lead >>> to broader applicability. Then we could allow >> >> That's what I was thinking. >> >>> cpdef readonly struct ... >>> >>> I think that's a lot clearer than adding to the double meaning of >>> "public". >>> I would also prefer if Python accessible cdef class attributes were >>> defined >>> using "cpdef". We could potentially make that the preferred way in the >>> future? >> >> We could allow it, but -1 to disallowing "cdef class" > > With "preferred way", I was suggesting that we could *deprecate* > > cdef public int x > cdef readonly object y > > for cdef class properties in favour of > > cpdef int x > cpdef readonly object y > > and change the documentation accordingly etc., so that at least new users > get used to the new way. +1 > The old way would likely continue to be supported > until Cython 2.0 or so, for the holy cow's sake... > But with a deprecation warning, right? -- 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] [cython-users] Cython .pxd introspection: listing defined constants
On Mon, Feb 21, 2011 at 10:26 AM, Stefan Behnel wrote: > Robert Bradshaw, 21.02.2011 19:11: >> >> On Sun, Feb 20, 2011 at 1:26 AM, Stefan Behnel wrote: >>> >>> W. Trevor King, 20.02.2011 00:31: On Sat, Feb 19, 2011 at 02:04:16PM -0800, Robert Bradshaw wrote: > > On Sat, Feb 19, 2011 at 1:45 PM, W. Trevor King wrote: >> >> It is unclear to me what `cdef public struct` means. I think it >> should mean "Python bindings can alter this struct's definition", >> which doesn't make sense. > > I think it should mean "this struct is accessible from Python (as X)" Wouldn't that be "cdef readonly struct X"? >>> >>> The problem here is that "public" is used differently in different >>> contexts >>> - usually "exported at the C level" in this kind of context, with the >>> quirk >>> of meaning "modifiable at the Python level" for cdef class attributes. >>> >>> The potentially clearer "cpdef" means "overridable at the Python level" >>> as >>> well as "visible at the Python level", so it doesn't quite match the >>> second >>> meaning by itself. >>> >>> Structs won't be overridable at the Python level, I guess, so cpdef isn't >>> quite right. The intention here isn't to export them at the C level >>> either, >>> so "public" isn't right. >>> >>> We could tweak the "cpdef" meaning into "cdef thing mapped to the Python >>> level, and overridable if supported in the given context", which would >>> lead >>> to broader applicability. Then we could allow >> >> That's what I was thinking. >> >>> cpdef readonly struct ... >>> >>> I think that's a lot clearer than adding to the double meaning of >>> "public". >>> I would also prefer if Python accessible cdef class attributes were >>> defined >>> using "cpdef". We could potentially make that the preferred way in the >>> future? >> >> We could allow it, but -1 to disallowing "cdef class" > > With "preferred way", I was suggesting that we could *deprecate* > > cdef public int x > cdef readonly object y > > for cdef class properties in favour of > > cpdef int x > cpdef readonly object y Oh, you were talking about members. For sure. > and change the documentation accordingly etc., so that at least new users > get used to the new way. The old way would likely continue to be supported > until Cython 2.0 or so, for the holy cow's sake... :) This kind of thing is much easier to fix than, say, fallout from http://trac.cython.org/cython_trac/ticket/654 - Robert ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
Stefan Behnel wrote: With "preferred way", I was suggesting that we could *deprecate* cdef public int x cdef readonly object y for cdef class properties in favour of cpdef int x cpdef readonly object y I think I've just realised one of the reasons for my gut dislike of the "cpdef" keyword -- it looks too similar to "def". At first glance, it's hard to spot the difference between the cdef and cpdef versions of two otherwise identical declarations. I think this is too subtle for something that makes such a big difference to semantics. It's often important that Python code is not allowed to mess with an object's internal state, so making it possible should require something more obvious. -- Greg ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
Greg Ewing, 21.02.2011 22:12: Stefan Behnel wrote: With "preferred way", I was suggesting that we could *deprecate* cdef public int x cdef readonly object y for cdef class properties in favour of cpdef int x cpdef readonly object y I think I've just realised one of the reasons for my gut dislike of the "cpdef" keyword -- it looks too similar to "def". At first glance, it's hard to spot the difference between the cdef and cpdef versions of two otherwise identical declarations. I think this is too subtle for something that makes such a big difference to semantics. It's often important that Python code is not allowed to mess with an object's internal state, so making it possible should require something more obvious. Hmm, I don't know. Maybe I'm just used to it already, but I don't find it hard to spot at all. The same argument could be brought up against "cdef" vs. "def" (between which the semantic difference is *huge*), and I hope you don't find that hard to spot. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] [cython-users] Cython .pxd introspection: listing defined constants
Stefan Behnel wrote: The same argument could be brought up against "cdef" vs. "def" (between which the semantic difference is *huge*) There are a couple of differences: - 'cdef' and 'def' look very different (at least to me) because they *start* with a different letter. Whereas 'cdef' and 'cpdef' both start and end with the same letter, maknig tehm mcuh eazier to conufse. - There is much less semantic overlap betwen 'def' and 'cdef'. If you use the wrong one, you usually find out about it fairly quickly one way or another -- you get a syntax error (e.g. 'def struct'), or something doesn't work the way you expected (e.g. a function you thought you had exposed doesn't show up in Python). It's possible to accidentally expose a function, but only if you declare it with an implicit return type, which I never do when writing what I intend to be a C function (this could perhaps be made illegal to further reduce the chances of such an error). Mistaken use of 'cpdef' on a C attribute, on the other hand, would very often pass silently. -- Greg ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
