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

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

(this seems to have gone off-list -- putting it back on)

On Mon, Jul 2, 2012 at 11:37 AM, Gordon Wrigley
<gor...@gm...> wrote:
> A bunch of these functions have a pointer argument and an old and new style
> of use, old style you pass a pointer to the data, new style you pass an
> integer index into preloaded data. The current API turns an integer argument
> into a one element list, which is rather awkward for new style use.

OK -- so is the proposal that the "pass an integer index into
preloaded data" be translated into python as passing an python integer
as an index into preloaded data, then yes, this sure seems the obvious
thing to so. I thought the integer would be interpreted as the value
of a reference, not as an index. My mis-understanding, I guess.

I guess I need an example or two to understand.

Perhpas I'm also confused by the term "array" in python, there is:

a list
a tuple
an array.array
a numpy ndarray

... and who knows what else.

They are all different things. Which were we talking about with:

"""
eliminate the interpretation of numbers as arrays
"""

-CHB

> On Jul 2, 2012 6:41 PM, "Chris Barker" <chr...@no...> wrote:
>>
>> 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...
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users



-- 

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...