On Mon, 4 Apr 2022 at 14:13, Ricky Teachey <ri...@teachey.org> wrote: > This is really similar to what pint does already (except it uses the > multiplication syntax if course). > > What does that idea bring other than being able to say: > > 5.0m > > (m registered in a previously run module) > > .... instead of: > > 5.0*m > > (m an object imported in a previously run module) > > ?
A large amount of clarity, readability, and namespacing (you don't have to pollute your global namespace with a large number of single-letter names, since these tokens will ONLY have meaning when immediately following an int or float literal). > Makes sense to me. > >> (Also, I don't really see a lot of point in making feet-and-inches >> minorly less complicated, given that people should be trying to use >> metric anyway.) > > > They're almost all I use professionally. I graduated college in 2010 and have > almost never used centimeters or millimeters since then. "Shoulds" aside, > feet and inches are not going away and any unit system needs to make them > first class and easy to use or it will be extremely painful for large chunks > of progressional engineers. > > But 5ft+4in is fine. Yeah - if it were clunkier than that, I would be more sympathetic to the "feet and inches are important" crowd, but the cost is a single addition operator. (Though there's still the question of what unit "5ft+4in" is - is it fractional feet or a large number of inches? Or is it a number of meters? But that's something a library can decide.) > I like and think I understand most of what you're saying here. I think much > of this has been thought through and solved by the pint library, and some > others. Having a "slot" to natively associate a unit tag with numerical > values, and syntax support with defined semantics, could be a big win. > Leaving the "now let's make decisions about behavior" part to 3rd parties > makes sense to me. > > But what superpower does bringing the notion of tagging things into the > native language bring for us if all the tag does is call a function that > returns a thing? > > It almost just sounds like a postfix function call syntax to me. Ultimately, EVERYTHING can be seen as just a function call in disguise. Why do we have subscripting when we could just have a method to return the Nth item from a list? Etcetera. What this brings is not a superpower, but simple clarity. We have imaginary literals because they make code more readable; in theory, we could just have a variable called "j" (or "i" if you prefer) which you multiply by something and add something, and that's your complex number. But it's cleaner to write "3+4j". If this were accepted, I would fully expect that libraries like pint would adopt it, so this example: >>> 3 * ureg.meter + 4 * ureg.cm <Quantity(3.04, 'meter')> could look like this: >>> 3m + 4cm <Quantity(3.04, 'meter')> with everything behaving the exact same after that point. Which would YOU prefer to write in your source code, assuming they have the same run-time behaviour? ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JGFMNB3Z635ZG6IHLOJ3JK5COFSDDGMA/ Code of Conduct: http://python.org/psf/codeofconduct/
