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
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 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
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 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
*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 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
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
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
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
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
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/
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 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,
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 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
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 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 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 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
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 -- [email protected]
To unsubscribe send an email to [email protected]
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
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 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 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
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 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,
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
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 -- [email protected]
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
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:
>
>
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, 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
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, 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 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 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
> 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
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
42 matches
Mail list logo
