[Pyrex] Why were .pxd files invented?

[Leif Strand]

The dependency-generation feature is completely orthogonal to the .pxd 
issue. Even if you decide to keep separate, manually-edited .pxd files, 
you still might want -Mx options to generate the Makefile 
interdependencies between Pyrex modules automatically (based upon the 
'cinclude' statements).

With generated .pxd files, you could still clearly separate interface & 
implementation, but do it syntactically inside the .pyx file, similar to 
a Pascal module (as I briefly mentioned in my original post):

#--- Shrubbing.pyx ---

cdef class Shrubbery:

    cinterface:  # from this the .pxd would be generated
        cdef int width
        cdef int length

        cdef trim(self):
            self.width = self.width - 1

    # end of cinterface

    def __new__(self, int w, int l):
        self.width = w
        self.length = l

#--- snip ---

One advantage of this is that a class could have 'private' cdef methods 
(declared outside the 'cinterface' block).

I don't object to any of the concerns you have raised -- working within 
a 'make' environment is an important concern. But there might be ways to 
achieve this without placing a burden upon the programmer.

What bugs me is having to toggle between two separate files while 
editing a class, keeping function prototypes in sync, etc. (one of the 
many things that make C/C++ programming so unpleasant). If I want to add 
an argument to the 'trim' method, I should be able to make the change in 
once place! If my programming environment forces me to do otherwise, it 
is evident that mundane implementation issues have compromised the 
language design.

--Leif



Greg Ewing wrote:

> Leif Strand wrote:
>
>> And forcing the programmer to manually maintain the depedencies in 
>> the Makefile isn't error-prone?
>
>
> No, because if the .pxd and .pyx get out of step,
> the Pyrex compiler will notice and complain. It
> may be slightly more work for the programmer, but
> it won't lead to undetected errors.
>
>> The trick is to add the -M* flags to the regular compile line.
>
>
> You're right, it could be done that way. But I
> still prefer to have the interface clearly separated,
> because it makes it obvious when I'm changing it.
> If I'm distributing a Pyrex module, I don't want
> to be accidentally making changes that will affect
> all its users.
>
> Possibly I could do what the Oberon compiler did,
> and not automatically write out the generated
> interface, but just check and warn when it differs
> from the previous one, and require a compiler
> option to write out a new interface. I can't see
> that fitting very well into a makefile-driven
> workflow, however.
>
> I'll keep the issue in mind for the future, but
> I don't intend to change it in the near term.
> What I have at the moment works, and I'm loathe
> to make any major changes to the compiler without
> very careful thought.
>