On May 7, 2009, at 2:47 AM, Dag Sverre Seljebotn wrote: > That whole explanation was a mess, as my daughter waked up from her > sleep > at the time before I could improve it :-)
Don't worry, I *totally* understand. :-) >> b = a >> >> actually do? Construct a new Python object, then copy by value into >> it, and assign to be? So >> >> a is b >> >> is now False? > > I'll just forget about earlier explanations. > > But what I am advocating is to just have a regular Python reference > transfer, no C++ operators involved. [...] > I am agreeing with Stefan that this is probably orthogonal. It is > something you might want to support for C structs as well, so that > > cdef CWidget a, b > b = a > a.show_caption = True # also changes b > > would hold, i.e. an ability to give C structs Python semantics. > This would > especially be useful given the recent method-on-struct idea, as > > b = a > a.set_value(3) # does not modify b > > is a "new" wierd exception from Python semantics. This has very little advantage over just creating a simple cdef class... if one doesn't mind the overhead (which is usually the reason to go with structs in the first place). This is almost sounding like a proposal to do cdef managed CWidget which would be an object wrapping a CWidget. > I still believe it should be discussed now because > a) it heavily impacts how one thinks about C++ operators Yes. > b) it is a way to solve the construction/destruction problem with C+ > + classes I'm not sure it does. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
