> Much of this discussion is based on a misconception. Units and SI scale
> factors
> are very useful in software that describes or interacts with the real world,
> but
> primarily on input and output. They are not normally used for internal
> calculations. The idea that one carries units
Back in my original post, I pointed out that engineers and scientists in their
modern day workflows are expected to have basic programming language skills,
and are expected to use those skills when pre-packaged software solutions leave
gaps in their workflows, but they are explicitly told that
On Mon, Apr 4, 2022 at 3:53 AM Chris Angelico wrote:
> The 160 units would be more likely to have collisions though. Also,
> the base and derived SI units will be used with magnitude prefixes,
>
The supposed 160 are far fewer than I use on a daily (or at least weekly)
basis. Yes, all the rest
On Mon, Apr 4, 2022, 2:17 AM Brian McCall
> For instance, I don't think there would be much uproar if "teaspoons"
were left out of any kind of implementation.
Apparently someone other than you does the cooking in you household!
___
Python-ideas mailing
On 2022-04-04 01:19:13, pyt...@shalmirane.com wrote:
> This implies that it is only necessary to provide a package for
> reading and writing physical quantities, and indeed such a package
> exists: QuantiPhy. QuantiPhy came out of the ideas that were raised
> the last time this topic was
Much of this discussion is based on a misconception. Units and SI scale
factors
are very useful in software that describes or interacts with the real world,
but
primarily on input and output. They are not normally used for internal
calculations. The idea that one carries units on variables
On Mon, 4 Apr 2022 at 16:56, Ben Rudiak-Gould wrote:
> I feel like one of the biggest sticking points in this thread is that people
> are arguing for a new kind of global scope just for units, and the sole
> reason seems to be that they want short names for them.
>
> The register_numeric_suffix
On Mon, 4 Apr 2022 at 16:41, Brian McCall
wrote:
>
> How something is used is not the same as how it is defined. I might use my
> car key to open my mail, but if I ask someone if they've seen my letter
> opener, they're probably not going to be able to help me find my car keys.
>
+1 QOTW!
>
Now do it for NumPy arrays
___
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
The C++ way is custom literals (it's where this thread originated)
https://mail.python.org/archives/list/python-ideas@python.org/thread/MFZ52D32YTPYIQVUEZJWW3DUYQUBR5R7/
One problem I am seeing is a misunderstanding between standard, well-defined
units, and technical lingo - for which I am not
On 4/04/22 9:45 am, Ethan Furman wrote:
Well, if we're spit-balling ideas, what about:
63_lbs
77_km/hr
I'm not convinced there's a need for new syntax here.
63*lbs
77*km/hr
With appropriate definitions of lbs, km and hr these
can be made to construct numbers with attached
> The trouble is that SI isn't the only set of units out there. And
> particularly if you support SI derived units, there will be
> innumerable collisions of abbreviations with other systems. Unless
> you're going to mandate *in the language* that SI units are the only
> ones permitted (and thus
On Sun, Apr 3, 2022 at 10:10 PM Chris Angelico wrote:
> On Mon, 4 Apr 2022 at 14:13, Ricky Teachey wrote:
> > What does that idea bring other than being able to say 5.0m
> [...] instead of 5.0*m [...]?
>
> A large amount of clarity, readability, and namespacing (you don't have to
> pollute your
> This is just flatly wrong of usage in particle physics. Electron volts are
> precisely the default units used to describe the mass of subatomic
> particles.
I don't know what to tell you man. Here's Wikipedia. If you follow the link to
the actual SI publication, it says the same thing. How
I think I posted this somewhere else in this thread, or the previous thread.
argparse can handle negative numbers, but only of one of the built-in primitive
types. See example below:
```
import re, argparse
class meters(float):
def __new__(cls, x):
return super().__new__(cls,
> There are thousands of units in use in sciences, commerce, engineering
In the SI system, there are:
7 base SI standard units
22 named, derived standard units
14 alternative standard units of measure that are commensurate with one of the
29 base and derived units, and
~35 units (not symbols)
On 4/4/22 07:25, David Mertz, Ph.D. wrote:
On Mon, Apr 4, 2022, 12:53 AM Brian McCall
> An electron volt is a unit of energy. Or of mass. Or of momentum.
An electron volt is a unit of energy and only a unit of energy.
Knowing a particle's energy (in certain situations) means that
On Mon, 4 Apr 2022 at 15:26, David Mertz, Ph.D. wrote:
>
> On Mon, Apr 4, 2022, 12:53 AM Brian McCall
>>
>> > An electron volt is a unit of energy. Or of mass. Or of momentum.
>> An electron volt is a unit of energy and only a unit of energy. Knowing a
>> particle's energy (in certain
On Mon, 4 Apr 2022 at 15:20, Brian McCall
wrote:
>
> Typing "3m + 4cm" into a terminal produced the above output, even if it meant
> I needed to import the pint module, that would be great. No idea how that
> would work out, but all for it. argparse still seems like it would be a loose
> end,
On Mon, 4 Apr 2022 at 14:22, Brian McCall
wrote:
>
> I think if you look into CGPM standards (they're the grand pooh bahs who
> decide what SI units are) then you'd find that a lot of these potential
> collisions have already been encountered and resolved. Under SI, there is no
> ambiguity
On Mon, Apr 4, 2022, 12:53 AM Brian McCall
> > An electron volt is a unit of energy. Or of mass. Or of momentum.
> An electron volt is a unit of energy and only a unit of energy. Knowing a
> particle's energy (in certain situations) means that you also know other
> physical quantities about that
Typing "3m + 4cm" into a terminal produced the above output, even if it meant I
needed to import the pint module, that would be great. No idea how that would
work out, but all for it. argparse still seems like it would be a loose end,
though. Although, to be fair, it would be a loose end no
On Mon, 4 Apr 2022 at 14:13, Ricky Teachey 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:
>
>
>There are thousands of units in use in sciences, commerce, engineering,
>ordinary life, etc. In all of them, it is not uncommon for the same few
>letters to represent multiple things, depending on context.
Units in science and engineering are NOT AT ALL ambiguous. If they were, planes
would be
Native level support for units would be much more powerful and be much more
worth the effort than libraries. Libraries already exist, and they are not
sufficient.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
In the previous thread (Custom C++ literals), ChrisA raised some good
questions, some of which I can actually answer :D
> Part of the problem here is that Python has to be many many things.
> Which set of units is appropriate? For instance, in a lot of contexts,
> it's fine to simply attach K to
On Sun, Apr 3, 2022, 11:03 PM Chris Angelico wrote:
> > I'm unsure simple tags are enough. What should the behavior of this be?
>
> > height = 5ft + 4.5in
>
> My view on this is that it should basically be defined as:
>
> height = ft(5) + in(4.5)
>
> where you register your constructor
On Mon, 4 Apr 2022 at 13:45, David Mertz, Ph.D. wrote:
>
> While units are certainly useful, I think this is FAR too large to add to
> Python syntax. A library like "units" is great, but it really needs to be a
> library, and not a small one.
>
> There are thousands of units in use in sciences,
While units are certainly useful, I think this is FAR too large to add to
Python syntax. A library like "units" is great, but it really needs to be a
library, and not a small one.
There are thousands of units in use in sciences, commerce, engineering,
ordinary life, etc. In all of them, it is not
On Mon, 4 Apr 2022 at 12:42, Ricky Teachey wrote:
>
> On Sun, Apr 3, 2022, 6:27 PM Chris Angelico wrote:
>
> On Mon, 4 Apr 2022 at 07:45, Ethan Furman wrote:
> > Mechanically, are `lbs`, `km`, `hr`, etc., something that is imported, or
> > are they tags attached to the numbers? If
> >
On Sun, Apr 3, 2022, 6:27 PM Chris Angelico wrote:
On Mon, 4 Apr 2022 at 07:45, Ethan Furman wrote:
> Mechanically, are `lbs`, `km`, `hr`, etc., something that is imported, or
are they tags attached to the numbers? If
> attached to the numbers, memory size would increase and performance might
On the previous thread, Rickey wrote:
> Python SHOULD be that language we do this with. It is awesome in every other
> way. But if it isn't DEAD SIMPLE to use units in python, it won't happen.
I agree, being dead simple to use is of critical importance. Not only that, but
there are a number of
On 04/04/2022 09.45, Ethan Furman wrote:
> On 4/3/22 11:52, Brian McCall wrote:
>
...
>> The old engineering disciplines- mine (civil engineering), structural,
> electrical, etc- are the next frontier in the
>> "software eats the world" revolution, and they desperately need a
> language with
On Mon, 4 Apr 2022 at 07:45, Ethan Furman wrote:
> Mechanically, are `lbs`, `km`, `hr`, etc., something that is imported, or are
> they tags attached to the numbers? If
> attached to the numbers, memory size would increase and performance might
> decrease -- but, how often do we have a number
101 - 134 of 134 matches
Mail list logo
