Stefan Behnel wrote:
> Stefan Behnel wrote:
>> we've already discussed a couple of times how to provide type information
>> for pure Python source code. It was generally agreed that it's difficult
>> to do so inside of the function body and easier to do for function
>> signatures if we use Py3 annotations. I don't remember any good ideas how
>> to provide type information for classes, i.e. how to make them extension
>> types.

Someone must have mentioned this?:

@cython.cdef
class A:
    ...

@cython.cdef
def func(): ...

Just mentioning it as a possibility.

>> Now I wonder if it wouldn't be enough to allow .pxd files to override the
>> normal "def" and "class" statements in the source (maybe only for .py
>> files), so that a "class" that is implemented in the .py file becomes a
>> "cdef class" declared in the .pxd file. Same for "def" functions.
>>
>> We might even be able to handle this completely in the parser, so that the
>> rest of the compiler only sees the types as defined in the .pxd file.
>> Additionally supporting the "private" modifier in such a .pxd file could
>> then turn normal "def" functions into module-local (static) C functions.
> 
> I found this now:
> 
> http://wiki.cython.org/enhancements/overlaypythonmodules
> 
> While it comes close in how it works, it doesn't quite catch the idea
> above. Sounds like the proposal needs a little extension.

Yes, it is similar, but the purpose was providing typing information for 
other modules (even interpreted modules), while the purpose here is 
providing typing information

I think the idea is an interesting one, and I can think of cases where 
you would like to write pure python and supply Cython-specific info in 
another file.

It kind of goes against another idea we've toyed with earlier which is 
auto-generating pxd files from pyx files (perhaps only stuff declared 
"public" or so) so that one doesn't have to edit two seperate files.

But these are two different user types, so to speak, so both could be 
supported.

However it also depends on people not reassigning to the given symbol at 
run-time. I find that this area is a bit unclear at the moment and this 
would make it even less clear (suddenly you shouldn't reassign a 
function with a run-time wrapper because of something in another 
file...) But rather than elaborating on that I am going to post a 
proposal of my own soon.

-- 
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to