> On Aug 29, 2016, at 06:08, Erik Bray <erik.m.b...@gmail.com> wrote: > > On Mon, Aug 29, 2016 at 3:05 PM, Erik Bray <erik.m.b...@gmail.com > <mailto:erik.m.b...@gmail.com>> wrote: >> On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert >> <python-id...@shalmirane.com> wrote: >>> On Mon, Aug 29, 2016 at 01:45:20PM +1000, Steven D'Aprano wrote: >>>> On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote: >>>>> On 2016-08-28 18:44, Ken Kundert wrote: >>>>>> When working with a general purpose programming language, the above >>>>>> numbers >>>>>> become: >>>>>> >>>>>> 780kpc -> 7.8e+05 >>>> [...] >>>> >>>> For the record, I don't know what kpc might mean. "kilo pico speed of >>>> light"? So I looked it up using units, and it is kilo-parsecs. That >>>> demonstrates that unless your audience is intimately familiar with the >>>> domain you are working with, adding units (especially units that aren't >>>> actually used for anything) adds confusion. >>>> >>>> Python is not a specialist application targetted at a single domain. It >>>> is a general purpose programming language where you can expect a lot of >>>> cross-domain people (e.g. a system administrator asked to hack on a >>>> script in a domain they know nothing about). >>> >>> I talked to astrophysicist about your comments, and what she said was: >>> 1. She would love it if Python had built in support for real numbers with SI >>> scale factors >>> 2. I told her about my library for reading and writing numbers with SI scale >>> factors, and she was much less enthusiastic because using it would require >>> convincing the rest of the group, which would be too much effort. >>> 3. She was amused by the "kilo pico speed of light" comment, but she was >>> adamant >>> that the fact that you, or some system administrator, does not understand >>> what kpc means has absolutely no affect on her desired to use SI scale >>> factors. Her comment: I did not write it for him. >>> 4. She pointed out that the software she writes and uses is intended either >>> for >>> herself of other astrophysicists. No system administrators involved. >> >> Astropy also has a very powerful units package--originally derived >> from pyunit I think but long since diverged and grown: >> >> http://docs.astropy.org/en/stable/units/index.html >> >> It was originally developed especially for astronomy/astrophysics use >> and has some pre-defined units that many other packages don't have, as >> well as support for logarithmic units like decibel and optional (and >> customizeable) unit equivalences (e.g. frequency/wavelength or >> flux/power). >> >> That said, its power extends beyond astronomy and I heard through last >> week's EuroScipy that even some biology people have been using it. >> There's been some (informal) talk about splitting it out from Astropy >> into a stand-alone package. This is tricky since almost everything in >> Astropy has been built around it (dimensional calculations are always >> used where possible), but not impossible. >> >> One of the other big advantages of astropy.units is the Quantity class >> representing scale+dimension values. This is deeply integrated into >> Numpy so that units can be attached to Numpy arrays, and all Numpy >> ufuncs can operate on them in a dimensionally meaningful way. The >> needs for this have driven a number of recent features in Numpy. This >> is work that, unfortunately, could never be integrated into the Python >> stdlib. > > I'll also add that syntactic support for units has rarely been an > issue in Astropy. The existing algebraic rules for units work fine > with Python's existing order of operations. It can be *nice* to be > able to write "1m" instead of "1 * m" but ultimately it doesn't add > much for clarity (and if really desired could be handled with a > preparser--something I've considered adding for Astropy sources (via > codecs).
I just want to add, as an astrophysicist who uses astropy.units: the astropy solution is pretty great, and I don’t mind the library overhead. I’d much rather have astropy.units, which does dimensional analysis, as well as handling SI prefixes for 2 reasons: 1. I don’t normally see or use SI prefixes without units, so bare SI prefixes are fairly worthless to me as a scientist. IF the units are going to be there, I’d much rather have a library that does a good job at dimensional analysis, and has taken my domain-specific concerns into account, for reasons fairly well covered in this thread. 2. I don’t find it cumbersome at all to use something like astropy.units which provides both the prefix and units for my code on input and output. The added syntactic weight of a single import, plus multiplication, is really not that big a burden, and makes it both clear what I am trying to write, and easy for the library to maintain this meaning when I use the variable later. e.g. from astropy.units import * distance = 10 * km If that multiplication symbol is really too much to handle, then I’d rather see python support implicit multiplication as suggested above (i.e. “10 km” is parsed as “10 * km") and domain-specific libraries can support SI prefixes and units. ~ Alex > > Best, > Erik > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org <mailto:Python-ideas@python.org> > https://mail.python.org/mailman/listinfo/python-ideas > <https://mail.python.org/mailman/listinfo/python-ideas> > Code of Conduct: http://python.org/psf/codeofconduct/ > <http://python.org/psf/codeofconduct/>
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
