[Python-ideas] Re: Native support for units [was: custom literals]

On Wed, 6 Apr 2022 at 13:33, Christopher Barker wrote: > (or may favorite: API Gravity [2] as a density) > Wow, I have to remember this. I've worked with a lot of APIs in my time, and some of them definitely are more dense than others. ChrisA ___

[Python-ideas] Re: Native support for units [was: custom literals]

> Length is measured in a variety of units, but the degree ain't one of 'em. Mostly I was just being silly. But the relevant part is that people do a lot of useful work using values that are not in "proper" units, and don't follow the rules as they should. >From things as simple as using kg as

[Python-ideas] Re: mro and super don't feel so pythonic

On Wed, 6 Apr 2022 at 08:42, Greg Ewing wrote: > > On 6/04/22 4:57 am, Eric Fahlgren wrote: > > On Tue, Apr 5, 2022 at 7:49 AM Greg Ewing > > wrote: > > > > It's only there now for backwards compatibility. > > > > Not always. I have an example, where a

[Python-ideas] Re: mro and super don't feel so pythonic

On 6/04/22 4:57 am, Eric Fahlgren wrote: On Tue, Apr 5, 2022 at 7:49 AM Greg Ewing > wrote: > It's only there now for backwards compatibility. Not always.  I have an example, where a method creates a closure that calls super, requiring the class/self

[Python-ideas] Re: Native support for units [was: custom literals]

On Wed, 6 Apr 2022 at 08:35, Greg Ewing wrote: > > On 6/04/22 3:47 am, Christopher Barker wrote: > > And they are -- degrees latitude and degrees longitude are very > > different units :-) > > I'm thinking more of a local Cartesian coordinate system rather > than lat-long. > > Think about this:

[Python-ideas] Re: Native support for units [was: custom literals]

On 6/04/22 3:47 am, Christopher Barker wrote: And they are -- degrees latitude and degrees longitude are very different units :-) I'm thinking more of a local Cartesian coordinate system rather than lat-long. Think about this: You're driving north in a car that's 3m long. You turn east. Do

[Python-ideas] Re: Native support for units [was: custom literals]

On 6/04/22 3:30 am, Stephen J. Turnbull wrote: suppose I wanted to know how many cm there are in an in: cm_per_in = 1 * in / 1 * cm Of course that's a silly mistake, but the (sole, IMO) advantage of the original proposal is that you can't make that silly mistake. Well, you can make the

[Python-ideas] Re: mro and super don't feel so pythonic

Paul Moore writes: > I > personally think this is probably useless, but it's not a Python > change so do it if you want. I agree, this is most likely useless. Other people on this thread were worried about dependency injection through MRO injection being lost by my proposal, today's __bases__

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, Apr 5, 2022 at 11:57 AM Steven D'Aprano wrote: > > And they are -- degrees latitude and degrees longitude are very different > > units :-) > > Greg said *distances*, not coordinates or angles. People DO sometimes use lat/lon as distances— particularly latitude, where 1 minute is a

[Python-ideas] Re: Native support for units [was: custom literals]

On Wed, Apr 06, 2022 at 12:28:49AM +1200, Greg Ewing wrote: > On 5/04/22 6:05 am, Ethan Furman wrote: > >It seems to me that these "unitless' units actually have units, even if > >they *appear* to cancel each other out. > > I think it's more that units alone don't capture everything > that's

[Python-ideas] Re: Native support for units [was: custom literals]

On Wed, Apr 06, 2022 at 12:30:47AM +0900, Stephen J. Turnbull wrote: > Greg Ewing writes: > > > With my "no new syntax" suggestion there would be no question here -- > > the only way to write it would be > > > > height = 5 * ft + 4.5 * in > > I'm very sympathetic to the "no new syntax"

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, Apr 05, 2022 at 08:47:52AM -0700, Christopher Barker wrote: > On Tue, Apr 5, 2022 at 5:13 AM Greg Ewing > wrote: > > > single 4-dimensional continuum, this makes about as much > > sense as insisting that north-south and east-west distances > > are measured in different units. > > > >

[Python-ideas] Re: mro and super don't feel so pythonic

Greg Ewing writes: > It does this because the way it's intended to be used is to > pass it the class in which the method you're calling it from is > defined. It doesn't really matter what's the intended way for it to be used tho, what matters when it comes to designing / updating the design of

[Python-ideas] Re: Native support for units [was: custom literals]

I'll start with some opinionated stuff, but possibly helpful attempts to understand the requirements follows from about the middle of the post. Ricky Teachey writes: > [Brian McCall] had it right in his first post that spurred this > discussion. I'll quote bits of it: > > > ...I have spent

[Python-ideas] Re: mro and super don't feel so pythonic

On Tue, Apr 5, 2022 at 7:49 AM Greg Ewing wrote: > > It's only there now for backwards compatibility. It's not > Not always. I have an example, where a method creates a closure that calls super, requiring the class/self pair as there isn't enough context for parameterless super. (And also in

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, Apr 5, 2022 at 5:13 AM Greg Ewing wrote: > single 4-dimensional continuum, this makes about as much > sense as insisting that north-south and east-west distances > are measured in different units. > And they are -- degrees latitude and degrees longitude are very different units :-)

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, 5 Apr 2022 at 14:25, Ricky Teachey wrote: > units are at THE CORE of that need. > > i think python should be the language we reach for. i have made python work > for me as a civil engineer and been extremely successful with it for all the > usual reasons: ease of learning and community

[Python-ideas] Re: Native support for units [was: custom literals]

Greg Ewing writes: > With my "no new syntax" suggestion there would be no question here -- > the only way to write it would be > > height = 5 * ft + 4.5 * in I'm very sympathetic to the "no new syntax" suggestion, but suppose I wanted to know how many cm there are in an in:

[Python-ideas] Re: mro and super don't feel so pythonic

On Tue, 5 Apr 2022 at 12:37, malmiteria wrote: > > ROUND 3 i guess > > I promised paul moore an up to date proposal, here it is: > > 1) an alterhitance module, dedicated to all __bases__ (the iterable of > parents) alteration operations > This replaces the "dependency injection" use case (based

[Python-ideas] Re: Custom literals, a la C++

Brian McCall writes: > In terms of the internal representation of units, the > representation that is use for machine calculations, there are only > 7 units that need to be supported. According to you. I would like dollars and shares to be supported as well as perhaps "kg of apples" (vs "kg

[Python-ideas] Re: mro and super don't feel so pythonic

On 5/04/22 5:57 am, malmiteria wrote: When you're actually in need to passing arguments to super, you very likely know what class you're gonna be targeting, and having to run MRO logic in reverse to call super to the class that comes first before your target in MRO order is what i refer to as

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, Apr 5, 2022 at 7:43 AM Steven D'Aprano wrote: > On Mon, Apr 04, 2022 at 01:53:49PM +1000, Chris Angelico wrote: > > > And that's exactly why I think that the *concept* of units could be > > added to the language, with some syntax and low-level semantics, but > > the actual units

[Python-ideas] Re: Native support for units [was: custom literals]

On 5/04/22 6:36 am, Chris Angelico wrote: 5 L/100km in SI units is 5e-3 m³ / 1e5m. That's 5e-8 m². Or if you prefer, 50mm². Fuel economy is a unit of area. This misses the rather important point that it's not just litres of empty space, it's litres *of fuel*. You really need to consider

[Python-ideas] Re: Native support for units [was: custom literals]

On 5/04/22 6:05 am, Ethan Furman wrote: It seems to me that these "unitless' units actually have units, even if they *appear* to cancel each other out. I think it's more that units alone don't capture everything that's important about the physical situation. Another example: the capacitance

[Python-ideas] Re: Native support for units [was: custom literals]

On 5/04/22 6:05 am, Chris Angelico wrote: In any case: the speed of light might be 1, but it's still 1 distance divided by 1 time. If you truly embrace the idea of space and time forming a single 4-dimensional continuum, this makes about as much sense as insisting that north-south and

[Python-ideas] Re: Native support for units [was: custom literals]

On Tue, Apr 05, 2022 at 04:05:36AM +1000, Chris Angelico wrote: > Not sure what you mean by "geometrized", but that would be the same > concept as referring to "natural units", wouldn't it? In any case: the > speed of light might be 1, but it's still 1 distance divided by 1 > time. No.

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 07:42:37AM +0200, Luca Baldini wrote: > I beg to disagree here, here---mass is measured in eV / c^2, and > momentum in eV / c. (Although, as Brian says, we're all guilty of taking > shortcuts in conversations.) I beg to differ. *Real* physicists measure everything in

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 04:47:12AM -, Brian McCall wrote: > Libraries already exist, and they are not sufficient. What are they missing? -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to

[Python-ideas] Re: Native support for units [was: custom literals]

On Mon, Apr 04, 2022 at 01:53:49PM +1000, Chris Angelico wrote: > And that's exactly why I think that the *concept* of units could be > added to the language, with some syntax and low-level semantics, but > the actual units themselves belong in libraries. +1 on that. I'm not even sure about the

[Python-ideas] Re: mro and super don't feel so pythonic

ROUND 3 i guess I promised paul moore an up to date proposal, here it is: 1) an alterhitance module, dedicated to all __bases__ (the iterable of parents) alteration operations This replaces the "dependency injection" use case (based on MRO injection, not __bases__ edits), and on its own

[Python-ideas] Re: Native support for units [was: custom literals]

On 5/04/22 5:17 am, Steven D'Aprano wrote: However, I suspect that having an array of unit objects rather than low-level machine ints or floats will reduce the performance of numpy a lot. If numpy were to incorporate units, I would expect there to be just one unit tag for the whole array. --

[Python-ideas] Re: Native support for units [was: custom literals]

On 5/04/22 12:27 am, David Mertz, Ph.D. wrote: 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! Wouldn't

[Python-ideas] Re: mro and super don't feel so pythonic

On 4/04/22 10:46 pm, Steven D'Aprano wrote: Now tell me that before you ran the code, or read my analysis of it, you would have predicted that super(ProudGobelin, self) would skip ProudGobelin's method and call CorruptedGobelin's method. I could have told you that it would skip ProudGobelin,

[Python-ideas] Re: Native support for units [was: custom literals]

On 4/04/22 7:59 pm, Chris Angelico wrote: How often do you ACTUALLY need them to be local to a module? When is this ever a concern? As long as there are competing *implementations* of units there will be potential for conflicts, even if the actual units being represented are the same. -- Greg

[Python-ideas] Re: Less is more? Smaller code and data to fit more into the CPU cache?

Barry Scott schrieb am 27.03.22 um 22:23: On 22 Mar 2022, at 15:57, Jonathan Fine wrote: As you may have seen, AMD has recently announced CPUs that have much larger L3 caches. Does anyone know of any work that's been done to research or make critical Python code and data smaller so that more