[sage-support] Re: Doc-testing cdef'd methods
On Dec 1, 2008, at 10:52 AM, Craig Citro wrote: >> Question for all: is there a good reason for writing cdef >> functions? Or >> should we make all cython functions cpdef? Python convention >> seems to >> be to expose the internals of the class, but just mark (with "_" or >> "__") the functions that are considered internal and may change >> without >> warning. >> > > There are definitely some cases where you have to -- for instance, if > the return type of your function is something like "int *", you're not > going to be able to cpdef that. (Or, if you can, it's news to me.) I'm > sure there are other reasons -- Rob will probably chime in with some > as I'm typing this message. :) Not only the return type, but also the arguments can't be pointers or other more complicated C types for cpdef functions. There is also a bit of overhead (typically one or two pointer compares) for cpdef functions (as opposed to simple cdef functions) but unless you're doing something very simple it's usually negligible. > That said, there are a *huge* number of functions that do just need > "cdef" turned into "cpdef" in the sage library. Yep, for sure. > >> I'm facing the doctesting dilemma brought up here with some other >> cdef >> functions in another class. >> > > Yeah, I agree that seeing "def _doctest_this_cdef_function" and > writing a little wrapper can be annoying, but I just don't think > there's another way around it in some cases. > > -cc > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Doc-testing cdef'd methods
> Question for all: is there a good reason for writing cdef functions? Or > should we make all cython functions cpdef? Python convention seems to > be to expose the internals of the class, but just mark (with "_" or > "__") the functions that are considered internal and may change without > warning. > There are definitely some cases where you have to -- for instance, if the return type of your function is something like "int *", you're not going to be able to cpdef that. (Or, if you can, it's news to me.) I'm sure there are other reasons -- Rob will probably chime in with some as I'm typing this message. :) That said, there are a *huge* number of functions that do just need "cdef" turned into "cpdef" in the sage library. > I'm facing the doctesting dilemma brought up here with some other cdef > functions in another class. > Yeah, I agree that seeing "def _doctest_this_cdef_function" and writing a little wrapper can be annoying, but I just don't think there's another way around it in some cases. -cc --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Doc-testing cdef'd methods
Simon King wrote: > Dear Robert, > > On Nov 29, 7:43 pm, Robert Bradshaw <[EMAIL PROTECTED]> > wrote: >> You can't call cdef functions from the Python interpreter. You can >> write a test function, e.g. "_test_mulint." > > Good idea! > > On the other hand, after writing "I wouldn't like to make the method > public", I asked myself *why* I wouldn't. Dunno. > So, I made it 'cpdef', and then the doc test works. Question for all: is there a good reason for writing cdef functions? Or should we make all cython functions cpdef? Python convention seems to be to expose the internals of the class, but just mark (with "_" or "__") the functions that are considered internal and may change without warning. I'm facing the doctesting dilemma brought up here with some other cdef functions in another class. Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Doc-testing cdef'd methods
Dear Robert, On Nov 29, 7:43 pm, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > You can't call cdef functions from the Python interpreter. You can > write a test function, e.g. "_test_mulint." Good idea! On the other hand, after writing "I wouldn't like to make the method public", I asked myself *why* I wouldn't. Dunno. So, I made it 'cpdef', and then the doc test works. Cheers Simon --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: Doc-testing cdef'd methods
On Nov 29, 2008, at 9:01 AM, Simon King wrote: > Dear Sage supporters, > > sorry if this is the wrong list. > I have some cdefined methods of an extension class. How can I doc-test > them? > > In more detail, having the following method definition of an extension > class MTX, the doc test would fail with an attribute error. > cdef MTX _mulInt_(self, long right) > r""" > EXAMPLES: > sage: from mtx import MTX > sage: M=MTX(some data) > sage: M._mulInt_(4) > expected output > """ > > So, what else can I do? Would cpdef work? But I wouldn't like to make > that method public. > Is it possible to do "cdef MTX M=MTX(some data)" in the example, so > that _mulInt_ was available? > > Searching the Cython manual for "test" didn't provide me with an > answer. You can't call cdef functions from the Python interpreter. You can write a test function, e.g. "_test_mulint." - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
