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:
https://media.giphy
*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 in
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
syst
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
https://mail.python.org/mailman3
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 m
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
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 p
>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 c
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 matt
> 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) tha
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, float(re.sub(r'm
> 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 somet
> 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 an
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 a
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
https://mail.python.org/
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 un
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 t
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":
https://media.giphy.com/media/Nl6T837bDWE1DPc
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
> 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 o
> 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 squeez
> 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 value
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
> 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
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 python-ideas-le.
> 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 s
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 do
> 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 that
> 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 da
29 matches
Mail list logo
