As you are the BDFL, principal contributor and OIIO is your baby, I reckon that if OIIO has a good deprecation mechanism and that it bothers you, you should make the change with the plan of adopting the new name for 3.x.
I know how one can feel about those things, naming stuff properly is still the hardest thing in software development :) My 2 cts! Thomas On Thu, 30 Dec 2021 at 2:36 PM, Larry Gritz <[email protected]> wrote: > 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]> 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] >> >> >> >> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> 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 > -- Thomas Mansencal - colour-science.org <https://www.colour-science.org> - thomasmansencal.com <http://www.thomasmansencal.com>
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
