> What does it *really* matter which of these you write?
> that's just arguing over the colour of the bikeshed.
> you have shown nothing to justify why unit support must be built into the
> language itself.
I did what I could, but I'm not going to try and justify any more. At the end
of the
> Agreed, this is just using Python as a glorified calculator. I understand
> that this is just an example, but I *am* curious, is the bulk of what you do
> simply calculations like this, or do your more complicated examples tend to
> be more like actual programs?
I have never shipped code
Mike and Andre, thanks for the links!
I was indeed planning to take a crack at implementing some ideas. First, for my
part, I need to get approval from the people who own my intellectual property
;-)
I also figured it would take me a while to sift through the Python code, which
I have never
> Unfortunately, Python simply doesn't have enough symbols available.
> Using precisely one opener/closer for each type is highly limiting,
> since the only characters available are those on a US-English keyboard
> and in the ASCII set. It would be nice if, for instance, ∅ could mean
> "new empty
Oops, my examples have some other problems:
> # λ = 550e-9nm
should be
> # λ = 550nm
and
> # λ = 550e-9 [nm]
should be
> # λ = 550 [nm]
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
> Thank you for all the examples, that should help a lot. Out of curiosity,
> those are the corrected versions of the code? Where was the mistake in the
> original?
Happy to help! The original was unitless altogether, so that was the first
problem. The particular error was λ. I typically work
Wow, this thread has grown quite a bit in the last two days. And there's some
really good points raised alongside the light trolling here and there. While
the discussion around implementation is important and very interesting, I think
the question around motivation is critical. Since I see some
> For example, consider currencies. There are currently hundreds of national
> currencies and thousands of cryptocurrencies. They all have the same basic
> fundamental unit of “value”, but value is only loosely defined. Furthermore,
> there is no fixed ratio between the currency and its
> I drove 20 minutes up the road to by a bushel (US, not British) of U.S. No.
> 1. apples, to make apple cider. On my return trip, I stopped at the hardware
> store to buy a 2 lb box of 1-3/4" ring shank 12 penny nails. I used my 7/8
> hole kitchen planer blade to grate the apples, then
> 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
Asked and answered!
> * There are an unlimited number of derived (non-SI) and compound units
> that people will want to use.
Unlimited? You sure that problem can't be bounded? There are few things I can
think of that could bound this problem in a performance-friendly manner.
In terms of the
Asked and answered! Although, see below*, the additional representations of
these numbers does not mean that "int", "bool", and "float" have no place in
the core language.
*Here is a URL to a GIF of the good people of Letterkenny saying "to be fair":
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
Why don't we allow different libraries to use different, incompatible
implementations of integers, floating points, and bool? Standard units are just
as immutable as any of these data types.
___
Python-ideas mailing list -- python-ideas@python.org
To
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
> 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
> 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)
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
>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 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
Looks like this segue moved on to a new thread, but I'm glad I'm not the only
one who thinks this way!
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
This thread is a little head-spinning. OP and replies are almost as difficult
to understand as the official documentation of super() :D
I'm not going to pile on, but I will provide an example I recently worked on
that illustrated to me both the difficulties and possibilities of the current
*SOAP BOX WARNING*
It's not often that I would say that C++ is easier to read or more WYSIWYG than
Python, but in this case, C++ is clearly well ahead of Python. I have spent a
fair amount of my own time, and I have seen so many others' time wasted because
command line or input fields do not
Oh, I didn't even know about `format_map`! Or `__format__` for that matter.
This makes everything much easier. For my purposes, I don't even need to use
`__format__` since I am not using format strings.
In a show of appreciation, here is a URL to a GIF of James Corden bowing:
29 matches
Mail list logo
