Previously you were adamant that it is important that the units be propagated
into the final result. In my experience this rarely works out as one expects
because the units come out in an overly complicated, confusing form or
unexpected form. For example, you gave the units for Planck's const
As why it is naive, see my previous post where I talk about the limitations of
dimensional analysis.
As a point of reference, I have been developing software for electrical
engineers for over 40 years. That software uses physical quantities (voltage
current, resistance, capacitance, etc.) heav
As why it is naive, see my previous post where I talk about the limitations of
dimensional analysis.
As a point of reference, I have been developing software for electrical
engineers for over 40 years. That software uses physical quantities (voltage
current, resistance, capacitance, etc.) heav
I think there is one more point worth making here. There is a suggestion that
dimensional analysis can underpin a units system. Actually, the idea that all
units can be broken down into a small set of fundamental units is very limiting
and results in many vexing issues.
For example, consider
On Sat, May 19, 2018 at 07:06:41AM -0400, Eric V. Smith wrote:
> On 5/19/2018 1:56 AM, Ken Kundert wrote:
> >On Tue, May 15, 2018 at 04:23:26PM -0400, Eric V. Smith wrote:
> >>I'm busy at the sprints, so I don't have a lot of time to think about this.
> >&
On Tue, May 15, 2018 at 04:23:26PM -0400, Eric V. Smith wrote:
> I'm busy at the sprints, so I don't have a lot of time to think about this.
>
> However, let me just say that recursive format specs are supported,
> to a depth of 1.
>
> >>> width=10
> >>> f'{"test":{width}}'
> 'test '
>
> So
The syntax for formatted string literals is given here:
https://docs.python.org/3/reference/lexical_analysis.html#f-strings
If you were to examine this carefully, you would see that a format_spec (the
part within the braces but after the colon) can be empty or it can consist of
literal chara
Facundo,
I think this is the beginning of a great feature. And it fills a hole in
the
current string formatting. Specifically, we can carefully control the
formatting
of the base data types, but not collections.
I would like to see you flesh out the idea. In particular, I'd like to see you
Nick,
I see. The Python C interface provides a very simple way of raising an
exception in the case where the exception is only passed one argument, the
error
message. It even makes it easy to interpolate arguments into that error
message.
If it is important to include other arguments, as
On Tue, Jul 04, 2017 at 04:54:11PM -0400, Terry Reedy wrote:
> There have been many proposals for what we might call
> RichExceptions, with more easily access information. But as Raymond
> Hettinger keeps pointing out, Python does not use exceptions only
> for (hopefully rare) errors. It also use
All,
My primary concern is gaining access to the components that make up the
messages. I am not hung up on the implementation. I just proposed the minimum
that I thought would resolve the issue and introduce the least amount of risk.
Concerning MRAB's idea of making the named arguments attri
I think in trying to illustrate the existing behavior I made things more
confusing than they needed to be. Let me try again.
Consider this code.
>>> import Food
>>> try:
... import meals
... except NameError as e:
... name = str(e).split("'")[1] # <-- fragile code
All,
Here is a proposal for enhancing the way BaseException handles arguments.
-Ken
Rationale
=
Currently, the base exception class takes all the unnamed arguments passed to
an
exception and saves them into args. In this way they are available to the
exception handler. A commonl
On Wed, Oct 05, 2016 at 03:07:42AM +1100, Steven D'Aprano wrote:
>
> Extra newlines are cheap. Writing
>
The cost is paid in newlines *and* extra levels of indentation.
Why isn't it the programmer that is writing the code the best person to decide
what is best?
-Ken
__
In my experience it is exceptions and inconsistencies that consume 'working
memory in the brain of humans'. By eliminating the distinction between list
comprehensions and for loops we would be making the language simpler by
eliminating an inconsistency.
Furthermore, I do not believe it is valid to
All,
Armed with all of your requirements, suggestions and good ideas, I believe
I am ready to try to put something together.
Thank you all, and once again let me apologize for 'all the drama'.
I'll let you know when I have something.
-Ken
___
Pytho
Thanks Chris.
I had misunderstood Steve's request, and I was thinking of something much more
complicated.
Your code is very helpful.
-Ken
On Wed, Aug 31, 2016 at 05:07:11PM +1000, Chris Angelico wrote:
> On Wed, Aug 31, 2016 at 2:08 PM, Ken Kundert
> wrote:
> > > What
> What's the mnemonic here? Why "r" for scale factor?
My thinking was that r stands for real like f stands for float.
With the base 2 scale factors, b stands for binary.
> (1) Why no support for choosing a particular scale? If this only auto-scales,
> I'm not interested.
Auto-scaling is kind of
Okay, let's try to wrap this up. In summary I proposed three things:
1. A change to the Python lexer to accept SI literal as an alternative, but not
replacement to, E-notation. As an optional feature, simple units could be
added to the end but would be largely ignored. So the following wou
:
> On Tue, Aug 30, 2016 at 11:48 AM, Ken Kundert
> wrote:
> > [...] Similarly when people refer to the length of
> > the Olympic road race in Rio, they say 56km, not 56000m.
>
> However I can't help to point out that if I said the distance to the
> sun is 149.6 Gm, mo
D'Aprano wrote:
> On Mon, Aug 29, 2016 at 08:48:55PM -0700, Ken Kundert wrote:
>
> > >>> print(d_sun.to(u.kpc))
> > 4.850441695494146e-09 kpc
> >
> > I can see where this can be helpful at times, but it kind of goes against
> > the
>
he results 'publication quality'.
My hope is that if Python accepted SI literals directly, then both NumPy nad
MatPlotLib would also be extended to accept/use these formats directly,
eliminating the need for me to do the conversions and manage the axes.
-Ken
On Mon, Aug 29, 2016 at
Erik,
One aspect of astropy.units that differs significantly from what I am
proposing is that with astropy.units a user would explicitly specify the scale
factor along with the units, and that scale factor would not change even if the
value became very large or very small. For example:
factors from Python? Or is your issue with something about my
proposal?
-Ken
On Mon, Aug 29, 2016 at 06:59:15PM -0700, Nikolaus Rath wrote:
> On Aug 28 2016, Ken Kundert
> wrote:
> > So, in summary, you are suggesting that we tell the scientific and
> > engineering
> > co
> I talked to astrophysicist about your comments, and what she said was:
> 1. She would love it if Python had built in support for real numbers with SI
>scale factors
> 2. I told her about my library for reading and writing numbers with SI scale
>factors, and she was much less enthusiasti
> > These do not seem like good reasons for not doing this.
>
> Not worded the way you have them, no, because you've aimed for an
> extremely emotional argument instead of answering concrete questions
> like "where's the code that this would improve". Find some real-world
> code that would truly b
On Mon, Aug 29, 2016 at 12:18:02AM -0700, Brendan Barnwell wrote:
> On 2016-08-29 00:07, Ken Kundert wrote:
> > > >I completely believe Ken that within a single tightly focussed user
> > > >community, using their expected conventions (including SI prefixes)
> >
> There are other languages too that had hexadecimal and octal.
>
> They've been around in programming languages for decades.
>
> How many languages have scale factors?
>
> Does Fortran? Not that I know of.
>
The reason why hexadecimal and octal are in general purpose languages and real
number
On Mon, Aug 29, 2016 at 01:45:20PM +1000, Steven D'Aprano wrote:
> On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote:
> > On 2016-08-28 18:44, Ken Kundert wrote:
> > >When working with a general purpose programming language, the above numbers
> > &g
On Mon, Aug 29, 2016 at 12:33:16PM +1000, Chris Angelico wrote:
> On Mon, Aug 29, 2016 at 11:44 AM, Ken Kundert
> wrote:
> > When working with a general purpose programming language, the above numbers
> > become:
> >
> > 780kpc -> 7.8e+05
> > 108
ange: using SI scale factors and using exponential notation. And
we
can tell which is preferred. You said femptoseconds, you did not say 1e-15
seconds. Even you prefer SI scale factors.
-Ken
> On Aug 28, 2016 8:44 PM, "Ken Kundert" wrote:
>
> > Wow, things have suddenl
Wow, things have suddenly turned very negative. I understand that this is very
normal for these types of forums where it is easy to lose sight of the big
picture. So let me try to refocus this discussion again.
MOTIVATION
The way the scientific and engineering communities predominately write r
On Sat, Aug 27, 2016 at 03:24:49PM +0900, Stephen J. Turnbull wrote:
> If you want to change the *language* you need to provide answers to
> the following. I have no answers to them that I like, but maybe you
> can do better.
>
> How about 2.4Gaunitwithaveryveryveryveryveryverylongname?
Why woul
a serious computational task. Fortress looks
like a general purpose programming language, but little detail seems to remain
about this language, and I found nothing on units or scale factors.
-Ken
On Sat, Aug 27, 2016 at 01:48:29PM +1000, Steven D'Aprano wrote:
> On Fri, Aug 26, 2016 at 03:23:24PM
, output the
units, input the units, check the units, this proposal addresses the first two.
-Ken
On Fri, Aug 26, 2016 at 08:01:29PM +1000, Steven D'Aprano wrote:
> On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
> > On 8/25/16, Ken Kundert wrote:
> >
>
Okay, so I talked to Guido about this, and all he was trying to convey is that
there is an extremely high bar that must be reached before he will consider
changing the base language, which of course is both prudent and expected.
I'd like to continue the discussion because I believe there is some c
On Fri, Aug 26, 2016 at 10:14:53AM +1000, Steven D'Aprano wrote:
> On Thu, Aug 25, 2016 at 11:02:11AM -0700, Ken Kundert wrote:
>
> > Even if the language completely ignores the units, we have still gained by
> > allowing the units to be there, just like we gain wh
Here is a fairly typical example that illustrates the usefulness of supporting
SI scale factors and units in Python.
This is simple simulation code that is used to test a current mirror driving an
100kOhm resistor ...
Here is some simulation code that uses SI scale factors
for delta in [-5
All,
This proposal basically has two parts. One part is that Python should
naturally support printing real numbers with SI scale factors. Currently there
are three formats for printing real number: %f, %d, %g. They all become
difficult to read for even moderately large or small numbers. Ex
> Question, though: What happens with exa-? Currently, if the parser
> sees "1E", it'll expect to see another number, eg 1E+1 == 10.0. Will
> this double meaning cause confusion?
Allow me to refine my answer to this question ...
Yes, that is definitely problematic. I see two possible solutions.
1
> So you can have 1000mm or 0.001km but not 1m?
If the scale factor is optional, then numbers like 1m are problematic because
the m can represent either milli or meter. This is resolved by requiring the
scale factor and defining a unity scale factor. I propose '_'. So 1m represents
milli and 1_
All,
I propose that support for SI scale factors be added to Python. This would
be very helpful for any program that heavily uses real numbers, such as those
involved with scientific and engineering computation. There would be two primary
changes. First, the lexer would be enhanced to take rea
42 matches
Mail list logo
