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 somet
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
> 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
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 yo
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 situations)
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, t
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 rega
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 o
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
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 c
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
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 functions
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
> > attached
On Sun, Apr 03, 2022 at 10:06:35PM -, malmiteria wrote:
> Then what's the solution to the diamond problem in python?
> in this example :
[code removed for brevity]
class hierarchy:
```
HighGobelin
/ \
/ \
/
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
d
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
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 Tue, 1 Mar 2022 at 17:31, Svein Seldal wrote:
> for x in (a for a in y if c):
-1 on this form, I know it's supported, but I can see it getting ugly, i.e.
for x in (a for x in (a for x in a)) # add a few more "for x in (a"
and it will get messy fast
> or
>
> it = (a for a in
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 nati
On Mon, 4 Apr 2022 at 08:09, malmiteria wrote:
>
> Chris Angelico writes:
> > It's a very real problem in C++, because C++ has a completely
> > different concept of multiple inheritance.
>
> Then what's the solution to the diamond problem in python?
> in this example :
> ```
> class HighGobelin:
>
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
>
On Mon, 4 Apr 2022 at 04:53, Brian McCall
wrote:
> If you had asked me twenty years ago if I thought units should be a native
> part of any programming language, I would have said absolutely - because in
> my youthful ignorance I had no idea what it would take to make such a thing
> work. Five
Chris Angelico writes:
> It's a very real problem in C++, because C++ has a completely
> different concept of multiple inheritance.
Then what's the solution to the diamond problem in python?
in this example :
```
class HighGobelin:
def scream(self):
print("raAaaaAar")
class Corrupted
On 4/3/22 11:52, Brian McCall wrote:
> If you had asked me twenty years ago if I thought units should be a native
part of any
> programming language, I would have said absolutely - because in my youthful
ignorance
> I had no idea what it would take to make such a thing work. Five years later,
On Mon, 4 Apr 2022 at 07:35, malmiteria wrote:
>
> Chris Angelo writes :
> > You start out with the assumption that MOST PEOPLE think of super as a
> > way to call THE, singular, parent. If this is indeed a problem, then
> > it's not a problem with super, it's a problem with expectations.
> This i
On Mon, 4 Apr 2022 at 07:16, malmiteria wrote:
> > You haven't demonstrated that there's a problem to be solved.
> The problem called "diamond problem" is a classic of multiple inheritance, an
> exemple here that was already posted on this thread :
> https://stackoverflow.com/questions/55829798/
Chris Angelo writes :
> You start out with the assumption that MOST PEOPLE think of super as a
> way to call THE, singular, parent. If this is indeed a problem, then
> it's not a problem with super, it's a problem with expectations.
This is not so much a problem as this is the context we're working
HEAR HEAR!
BUT- SI units isn't enough. Engineers in the US and Canada (I have many
colleagues in Canada and when I ask they always say: we pretend to use SI
but we don't) have all kinds of units.
Give us native, customizable units, or give us death! Who's with me??!!
...
I'm kidding to a
Paul Moor writes :
> PS Please don't respond to this with another wall of text. I won't
> read it.
I'll try my best, just tell me if this is too long.
> your fundamental
> misconception that there is always a single well defined "parent
> class"
I don't hold such a conception
> In practice ther
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
On Mon, 4 Apr 2022 at 03:33, malmiteria wrote:
>
> Chris Angelico writes:
> > And is it still based on the fundamental
> > assumption that super() calls THE parent class?
> what are you even talking about?
>
I'm talking about this:
> feature 1 (of super alone): proxying the parent.
> What most p
*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
On Sun, 3 Apr 2022 at 18:36, malmiteria wrote:
>
> Chris Angelico writes:
> > And is it still based on the fundamental
> > assumption that super() calls THE parent class?
> what are you even talking about?
It's been explained before in this thread - your fundamental
misconception that there is al
Chris Angelico writes:
> And is it still based on the fundamental
> assumption that super() calls THE parent class?
what are you even talking about?
> I don't have the time to read
> that long a post.
Then just read the list of 4-5 features i describe as features of current MRO +
super, at the to
On Mon, 4 Apr 2022 at 01:10, malmiteria wrote:
>
> ROUND 2 @everyone
>
> this is... a lenghty post to say the least.
> That should give you the 'full' picture.
Incredibly lengthy. And is it still based on the fundamental
assumption that super() calls THE parent class? Because if so, there's
not a
ROUND 2 @everyone
this is... a lenghty post to say the least.
That should give you the 'full' picture.
It's quite a lot of things to talk about, so i'm asking you to please
explicitely state what proposal you are adressing when responding to this email.
If possible with a "CONTEXT : ..." line som
On 2022-04-02 22:28, Steven D'Aprano wrote:
On Sun, Apr 03, 2022 at 01:09:00PM +0900, Stephen J. Turnbull wrote:
>There was a proposal to provide literal syntax for physical units like
>meters, kilograms, and seconds, along the the SI magnitude prefixes.
>I think that got to the "proto-PEP" sta
42 matches
Mail list logo
