Re: [pygame] PixelArray question

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

On 8/23/07, Marcus von Appen <mva@xxxxxxxxxxxx> 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.