On Thu, Aug 25, 2016 at 08:46:54PM -0700, Ken Kundert wrote:
> This idea is new to general purpose languages,
For the record, at least some HP calculators include a "units" data type
as part of the programming language "RPL", e.g. the HP-28 and HP-48
series. I've been using those for 20+ years
On 26 August 2016 at 08:34, Nick Coghlan wrote:
> On 26 August 2016 at 13:46, Ken Kundert
> wrote:
> > 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,
On 8/25/16, Ken Kundert wrote:
[...]
> Just allowing the units to be present, even it not
>
> retained, is a big advantage because it can bring a great deal of clarity to
> the
> meaning of the number. For example, even if the language does not flag an
> error
> when a user writes:
>
> vdiff
On 26 August 2016 at 13:46, Ken Kundert wrote:
> 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,
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 when we allow user to add
> > com
On Thu, Aug 25, 2016, at 19:50, Steven D'Aprano wrote:
> Historically, there are *three* different meanings for "MB", only one of
> which is an official standard:
>
> http://physics.nist.gov/cuu/Units/binary.html
The link doesn't work for me... is the third one the 1,024,000 bytes
implicit in de
On 26 August 2016 at 06:06, Ken Kundert wrote:
> Here is a fairly typical example that illustrates the usefulness of supporting
> SI scale factors and units in Python.
Ken,
To build a persuasive case, you'll find it's necessary to stop
comparing Python-with-syntactic-support to
Python-with-no-sy
On Thu, Aug 25, 2016 at 11:02:11AM -0700, Ken Kundert wrote:
> Once you
> allow SI scale factors on numbers, the natural tendency is for people to want
> to
> add units, which is a good thing because it gives important information about
> the number. We should allow it because it improves the
On Thu, Aug 25, 2016 at 09:03:32PM +0100, Paul Moore wrote:
> That's not to say there's no room for debate here - the proposal is
> interesting, and not without precedent (for example Windows Powershell
> supports constants of the form 1MB, 1GB
That's great! I know a few command line tools and s
On 25/08/2016 22:06, Ken Kundert wrote:
> 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 simu
On Fri, Aug 26, 2016 at 6:06 AM, Ken Kundert
wrote:
> Here is some simulation code that uses SI scale factors
>
> for delta in [-500nA, 0, 500nA]:
> input = 2.75uA + delta
> wait(1us)
> expected = 100kOhm*(2.75uA + delta)
> tolerance = 2.2mV
> fails = ch
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
On 25 August 2016 at 19:02, Ken Kundert wrote:
> 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 r
> On Aug 25, 2016, at 3:27 PM, Nick Jacobson via Python-ideas
> wrote:
>
> +1 for clear_dir()
>
> I agree that there's no other obvious meaning that it could have.
+1, but I think "cleardir" would better match naming conventions in the shutil
module.
(My personal rule of thumb on the use
+1 for clear_dir()
I agree that there's no other obvious meaning that it could have.
On Thursday, August 25, 2016 9:44 AM, Nick Coghlan
wrote:
On 25 August 2016 at 23:14, Victor Stinner wrote:
> Maybe add a different function rather add a flag? Something like
> shutil.remove_dir_files
The only reason I can think of for wanting this simple class in the stdlib
would be that on GIL-free Python implementations you could replace it with
a lock-free version. But I think we'd probably want to rethink a bunch of
other datastructures to be lock-free, and a 3rd party package on PyPI makes
On 25.08.2016 20:10, Ben Hoyt wrote:
>> As long as Python uses a GIL to protect C level function
>> calls, you can use an iterator for this:
>>
>> import itertools
>> x = itertools.count()
>> ...
>> mycount = next(x)
>>
>
> Yeah, that's a neat hack -- I saw it recommended on StackOverflow, and saw
> As long as Python uses a GIL to protect C level function
> calls, you can use an iterator for this:
>
> import itertools
> x = itertools.count()
> ...
> mycount = next(x)
>
Yeah, that's a neat hack -- I saw it recommended on StackOverflow, and saw
it used in the standard library somewhere. I thi
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
On 25.08.2016 19:31, Ben Hoyt wrote:
> I had to implement a simple atomic counter the other day to count the total
> number of requests processed in a multi-threaded Python web server.
>
> I was doing a demo of "how cool Python is" to my colleagues, and they were
> generally wowed, but one of the
I had to implement a simple atomic counter the other day to count the total
number of requests processed in a multi-threaded Python web server.
I was doing a demo of "how cool Python is" to my colleagues, and they were
generally wowed, but one of the things that made them do a double-take
(coming
On 25 August 2016 at 23:14, Victor Stinner wrote:
> Maybe add a different function rather add a flag? Something like
> shutil.remove_dir_files().
The typical Python term for the concept would be "clear", giving
shutil.clear_dir(). Like the ".clear()" method on containers, it would
delete the cont
Hi Yury et al,
Apologies for not participating in this discussion before -- unfortunately
I've been dealing with some boring medical issues and haven't been able to
contribute as much as early as I should have... But I do have two concerns,
one minor and one not.
Minor comment: this is purely an
Maybe add a different function rather add a flag? Something like
shutil.remove_dir_files().
Victor
Le 25 août 2016 4:32 AM, "Nick Jacobson via Python-ideas" <
python-ideas@python.org> a écrit :
> I've been finding that a common scenario is where I want to remove
> everything in a directory, but
On Thu, Aug 25, 2016 at 9:24 PM, Steven D'Aprano wrote:
> If I try to add 30 feet to 6 metres and get either 36 feet or 36 metres,
> then your unit system is *worse* than useless, it is actively harmful. I
> don't mind if I get 15.144 metres or 49.685039 feet or even
> 5.0514947e-08 lightseconds,
On Wed, Aug 24, 2016 at 09:28:03PM -0700, Ken Kundert wrote:
> All,
> I propose that support for SI scale factors be added to Python.
I think there's something to be said for these ideas, but you are
combining multiple ideas into one suggestion.
First off, units with quantities: I think that
I have trouble imagining situations in which SI units would help
readability over scientific notation. On the one hand reading it always
involves mental conversion to the exponents, so this is just an extra step.
E.g. this equality is evident at a glance:
1e3 * 1e6 * 1e-9 == 1
This one would take
On Thu, Aug 25, 2016 at 6:19 PM, Ken Kundert
wrote:
>> 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
On 25 August 2016 at 06:06, Paul Moore wrote:
> On 25 August 2016 at 09:54, Ken Kundert wrote:
>> 1G -> 1e+09
>> 1M -> 1e+06
>> 1k -> 1e+03
>
> While these suffixes are suitable for a scientific context, in a
> computing context, 1k=1024, 1M=1024*1024 and 1G=1024*1024*1024 make
> just
On 25 August 2016 at 09:54, Ken Kundert wrote:
> 1G -> 1e+09
> 1M -> 1e+06
> 1k -> 1e+03
While these suffixes are suitable for a scientific context, in a
computing context, 1k=1024, 1M=1024*1024 and 1G=1024*1024*1024 make
just as much, if not more, sense (and yes, I'm aware of Gigabyt
> 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_
32 matches
Mail list logo
