On May 15, 2008, at 1:49 AM, Dag Sverre Seljebotn wrote:
>
>>> ("cdef object s = arr.shape" should work though, but I consider that
>>> GSoC-stuff, not something you can fake at this stage.)
>>
>> Doesn't that work now?
>
> Well, it works because the C-version is called "dimensions". But "cdef
> object s = arr.strides" does not work ("Cannot convert
> 'numpy.Py_intptr_t *' to Python object"); so it's "namespace-fragile"
> behaviour.
>
>> No, I'm seeing things going the other way. obj.attr is viewed as a
>> cdef attribute (if it exists) any only as a python attribute if it is
>> used in a python context and can't be coerced. (One would implement
>> the shape property to return the appropriate object.) The "raw
>> access" is always available (assuming obj is typed correctly) and
>> there is no need or motivation for a separate API.
>
> Yes, I can see the benefits.
>
> And again my problem is that this can only really work if raw C API is
> similar to the Python API. And since this is a /language design/
> issue,
> I think that is too big an assumption for something to build it so
> heavily into the language core. (But, it is a matter of taste; and it
> has a certain appeal that might change my mind after thinking more
> about
> it.)
You are right that this is a language design issue. If library
authors want completely separate API and names for C and Python, they
are still free to do so. Right now they are forced to do so, which I
think is a deficiency.
>
> Consider a "FsAsObj" extension class:
>
>>>> a = FsAsObj()
>>>> print a.usr.include
> <FsAsObj path="/usr/include/">
>
> On the other hand, you might have something like an "fshandle"
> attribute
> in the extension class, C-side (not meant for Python users to see). So
> perhaps you'd like to do:
>
> cdef FsAsObj d = FsAsObj()
> d = d.usr.include
> call_native_c_function(d.fshandle)
>
> Then I do
>
> $ sudo mkdir /fshandle
>
> and want to access it... *grin*
As contrived as this is, it doesn't contradict the model above at all.
> (ok, contrived, but again, this is
> language design, and for good language design issues the criteria for
> stability and lack of exceptions and ad-hoc-ness should be pretty
> high.
> Let's see if we can find a (new, creative) way to satisfy us both...
+1
>
> I'll sign off this discussion now though, perhaps I'm convinced
> after a
> week of it sinking in.
>
> --
> Dag Sverre
>
> _______________________________________________
> Cython-dev mailing list
> [email protected]
> http://codespeak.net/mailman/listinfo/cython-dev
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
