On 2 November 2010 20:02, Stefan Behnel <[email protected]> wrote:
> Robert Bradshaw, 02.11.2010 07:17:
>> On Sun, Oct 31, 2010 at 8:44 PM, Brett Calcott wrote:
>>> cdef class PythonVector2d:
>>>    cdef Vector obj
>>>    properties:
>>>       public obj.x as x
>>>       public obj.y as y
<--- snip -->
> For this case, I'd prefer a version entirely without body, maybe even
>
>     property x = obj.x
>
> although the "as" version would also work. However, it's not so clear from
> the above that both setter and getter get generated, and how you would get
> only the getter for read-only access, for example. And why not have a
> "delattr" as well? May make sense in some cases.
>

The proposal I made above would handle getter/setter differences using
the syntax that is already established.

properties:
  public obj.x as x
  readonly obj.y as y

I went for a body as it means not repeating the word property over and
over, and it allows renaming. I'm not seeing how delattr would make
sense yet.

> Personally, I think that the current way of coding this isn't all that
> cumbersome but a lot more explicit. And it makes you think a bit more about
> the implications of mapping a C++ class field directly to a Python property
> without value checking etc.
>

I've got structures with something like 10 members that I want to
directly map. I think it starts to look cumbersome then. The proposal
is really just extending an already existing option: you can automate
access to float/int etc using public and readonly of stuff declared in
your extension class. If a c++ library exposes structure members (ie,
they aren't private/protected), and you declare this in your extension
class, providing the same sort of access doesn't seem too much of a
stretch (of course, I have no idea how hard this would be to
implement!)

I should add: I like manually wrapping a c++ library with cython, as I
can make things more pythonic in the process. The automated swig way
of doing things fails to do this.
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to