On 8/23/07, Marcus von Appen <[EMAIL PROTECTED]> wrote: > On, Thu Aug 23, 2007, Brian Fisher wrote: > > What I should have said is it lets you "do less". If there is not > > benefit to me to create the object as a user of the library, then why > > make me create it? Basically let me have less to think about and read, > > unless giving me more to think about and read helps me. > > That's what's done with explicitly wrapping it up in my opinion. It > helps to clarify what such an access in contrast to sf[x] does. > I like the idea of designing the interface to be explicit even if it's more wordy, but I disagree that idea applies at the moment.
I don't see that constructing the PixelArray object around the surface does anything to clarify ambiguous indexing as it is right now. All it really does is move the ambiguity from one place to the other. What I mean is, between these two: sf = Surface() thing = sf[0] and: sf = Surface() pa = PixelArray(sf) thing = pa[0] both sf[x] and pa[x] basically have the same issue... neither situation makes it easier to understand what "thing" becomes > > [claimed logical fallacy for saying other modules have this problem] > > I never said (or wrote that) and never meant that either. What I wanted > to say is: if there could be doubts, clarify anything in the docs. > ah - I understand now. I was just trying to say that I think we should make the code as readable/understandable without docs as we know how to, regardless of if it will be clarified in docs > So what's the better interface then? The one, that clearly states what > it does, or the second, that (especially for the surface case) depends > on user recognition? > If the user always recognizes things correctly, then I'd say the simpler/smaller api that depends on user recognition is better. I can see your point that [] access on a surface is ambiguous though > > [PixelAccessor might be better than PixelArray] > > The naming might not be perfect, especially in regard to the long-term > naming of surfarray.arrayXX and surfarray.pixelsXX. PixelAccessor > however let's me assume linear access, not a 2D access ;-). I'll discuss > that with Rene. Alternative namings are welcome. > PixelAccessor2d ? It would be similar to the surfarray stuff which says dimensionality of the array, right? > The C buffer interface just returns a pointer to the internal buffer, it > does not construct any python object, thus no locking would be possible > as we do not exactly know, at which time the object will be released. > Instead the user code would have to take care of it. > I know the C buffer interface just returns the pointer, which is why I was saying [] access could return a python extension object. Such a behavior would be analogous to the PixelArray thing. > I've given you several, not all of them being THE reason why, but in my > opinion with sufficient weight. I only can rely on the experience I made > for now and this is what tells me, that such an implementation is better > for several reasons (as discussed so far). > For what it's worth, when you said explicitness was one of your rationales for the PixelArray object, that seems like a good reason to me. ... I do wonder about the question Lenard brought up about whether it would be bad to trust python's garbage collector to clean up your objects at the right time. It was my understanding that python always had ref-counting on, so objects would always be deleted the moment they went out of scope if they weren't in a cycle, and only then was it's cleanup time indeterminate.
