Re: [PyOpenGL-Users] Cleanups and deprecations going forward...

[Chris B. <chr...@no...>]

On Sat, Jun 30, 2012 at 7:34 PM, Mike C. Fletcher
<mcf...@vr...> wrote:
>   * eliminate the interpretation of numbers as arrays, that is, if you
>     pass 3 to a function expecting an array of integers you will get a
>     pointer to address 3, rather than a pointer to an array with a
>     single value of 3

So a Python integer gets interpreted as a pointer? That feels prone to
error to me, though probably an error that would show itself pretty
quickly.

Maybe it's to wordy, but what about a "pointer" of "address" object,
so ratehr than passing in an integer, you'd pass in:

pointer(an_integer)

(or you could use a numpy scalar:

Then passing in a string integer could either wrap an array around it,
or raise an error.

And what about passing a float?

>       o this will make the Python and C APIs look a lot closer

sure, but Python doesn't have pointers -- so being explicit about that
would make more sense to me.

>         eliminate a common class of issues where someone can't see how
>         to pass offsets to modern array functions

with this method -- where would the address value come from anyway? I
guess in my case, I'd tend to want to use a numpy array, and an offset
could be expressed as a slice.

By the way, Cython does this pretty naturally, you can do:

cdef np.ndarray[double, ndim=1, mode="c"] an_array

call_a_function_that_takes_a_pointer( &input[i] )

which makes it very easy to do an offset.

Thanks for moving PyOpenGL forward.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...