It's not the python bindings per se that are my concern, just the general confusion over terminology. C++ or Python, in either case, people might be liable to confuse whether ImageSpec::format refers to the pixel data type or the file format, and I find I have to clarify it every time I refer to it in the docs. Though you point out yet another ambiguity (though less severe) -- we also use "format" to mean formatting of strings.
But both you and Anders led off by saying that it doesn't really bother you, so maybe I'm overestimating the size of the problem. Unless others chime in and say "yes, this has always caused problems, please change it", perhaps I should just let it go. > On Dec 29, 2021, at 2:23 PM, Thomas Mansencal <[email protected]> > wrote: > > Hey Larry, > > Q1, Q2: It does not bother me as I don't really use it via the Python > bindings. > > Q3: As a Pythonista, I would certainly prefer "dtype" because this is indeed > what I use everydays. "format" is actually the method to format strings in > python, thus it feels strange but again, not a huge deal here. > > Cheers, > > Thomas Mansencal - colour-science.org <https://www.colour-science.org/> - > thomasmansencal.com <http://www.thomasmansencal.com/> > > On Thu, 30 Dec 2021 at 09:41, Larry Gritz <[email protected] > <mailto:[email protected]>> wrote: > Early on (and probably borrowing from prior software), I used > ImageSpec.format as the field describing the data type of the pixel values. > > I've long though that this was an unfortunate mistake, primarily because it > causes endless confusion about the difference between "data format" and "file > format", and awkward phrasing in the documentation. > > Question 1: Does anybody else care? Or is it fine? > > Question 2: If you care, would you like to see me slowly and deliberately > migrate to different terminology, both in the docs and what things are called > in code (functions, struct fields, named parameters, etc.)? Or is the pain of > any changes that would require client code to be edited worse than the > forever-tax of having chosen a confusing name? > > Question 3: If you think we should make changes, what is a more appropriate > name to use? NumPy (which I think is widely used by our constituency) uses > "dtype", so I believe that's a strong contender because of its existing > familiarity, relative clarity, lack of conflict with any other names or > concepts we use, and short name. Or "datatype"? Or something else? > (Suggestions welcome.) > > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > > > _______________________________________________ > Oiio-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
