Re: [Python-ideas] real numbers with SI scale factors

[Nick Coghlan]

On 30 August 2016 at 13:48, Ken Kundert  wrote:
> >>> d_sun = 93e6*u.imperial.mile
> >>> print(d_sun.to(u.parsec))
> 4.850441695494146e-06 pc

The "imperial.mile" example here highlights one key benefit that
expression based approaches enjoy over dedicated syntax: easy access
to Python's existing namespace features.

As a quick implementation sketch, consider something like:

>>> si_scaling = dict(k=1000, m=0.001)
>>> class SIScale:
... def __getattr__(self, key):
... return SIUnit(si_scaling[key])
...
>>> class SIUnit:
... def __init__(self, value):
... self.value = value
... def __getattr__(self, ignored):
... return self.value
...
>>> si = SIScale()
>>> 500 * si.k.m
50
>>> 500 * si.k.parsec
50
>>> 500 * si.m.m
0.5
>>> 500 * si.m.N
0.5

You could also relatively easily adapt that such that there there was
only one level of lookup, and you could write the examples without the
second dot (you'd just need to do some parsing of the key value in
__getattr__ to separate the SI prefix from the nominal units)

One particular benefit of this kind of approach is that you
automatically avoid the "E" ambiguity problem, since there's nothing
wrong with "si.E" from Python's perspective. You also gain an easy
hook to attach interactive help: "help(si)" (or si? in IPython terms)

Expanding out to full dimensional analysis with something like
astropy.units also becomes relatively straightforward, just by
changing the kind of value that __getattr__ returns.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Nikolaus Rath]

On Aug 28 2016, Ken Kundert 
 wrote:
> So, in summary, you are suggesting that we tell the scientific and 
> engineering 
> communities that we refuse to provide native support for their preferred way 
> of 
> writing numbers because:

I think you're making some incorrect assumptions here. Who, exactly, do
you mean with "we" and "them"?

I consider myself part of the scientific community and think your
proposal is a bad idea, and Google finds some Python modules from you,
but no prior CPython contributions...

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Force UTF-8 option regardless locale

[INADA Naoki]

On Tue, Aug 30, 2016 at 8:14 AM, Victor Stinner
 wrote:
>
> I proposed the idea, but I'm not sure that we can have a single option
> for Linux and Windows. Moreover, I never really worked on trying to
> implement "-X utf8" on Linux, because it looks like the "misconfigured
> system" are less and less common nowadays. I see very few user
> requests in this direction.


Some people loves tiny Linux image for Docker and RasberryPi. They
doesn't has any locale other than C.

Some OPs loves LANG=C or LC_ALL=C to avoid troubles and unexpected
performance regression caused by locale.  (e.g. sort command is much
slower on ja_JP.utf8).

I want to write script using utf-8 for stdio and fsencoding.
Sometimes, people runs my script in C locale. And sometimes runs in
misconfigured
locale because SSH sends LANG that system doesn't have.

So I wonder if Python has Force UTF-8" option.
And if the option is configure option or site-wide installation option, because:

* command line option cannot be set in shebang
* Setting environment variable may be forgetten when writing scripts
like crontab.

The option may make startup bit faster, because it can skip setting locale
in startup.


Any thoughts?
How should the option be set?
-- 
INADA Naoki  
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Ken Kundert]

> 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 enthusiastic because using it would require 
>convincing the rest of the group, which would be too much effort.
> 3. She was amused by the "kilo pico speed of light" comment, but she was 
> adamant 
>that the fact that you, or some system administrator, does not understand 
>what kpc means has absolutely no affect on her desired to use SI scale 
>factors. Her comment: I did not write it for him.
> 4. She pointed out that the software she writes and uses is intended either 
>for herself of other astrophysicists. No system administrators involved.

It has been pointed out to me that the above comes off as being condescending 
towards Steven, system administrators and language developers in general. For 
this I am profoundly sorry. It was not my intent. My only point was that the 
output of these numerical programs are often so highly specialized that only 
the 
authors and their peers understand it.

Let me go further in saying that if anything I have said in this discussion has 
come off as critical or insulting please know that that was not my intent.  
I have tremendous respect for what you all have accomplished and I am extremely 
appreciative of all the feedback and help you have given me.

-Ken
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Steve Dower]

On 29Aug2016 1433, Eric V. Smith wrote:

On 8/29/2016 5:26 PM, Ethan Furman wrote:

Update the PEP, then it's a bugfix.  ;)


Heh. I guess that's true. But it's sort of a big change, so shipping
beta 1 with the code not agreeing with the PEP rubs me the wrong way.

Or, I could stop worrying and typing emails, and instead just get on
with it!


I like this approach :)

But I agree. Release Manager Ned has the final say, but I think this 
change can comfortably go in during the beta period. (I also disagree 
that it's a big change - nobody could agree on the 'obvious' behaviour 
of backslashes anyway, so chances are people would avoid them anyway, 
and there was strong consensus on advising people to avoid them.)


Cheers,
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Eric V. Smith]

On 8/29/2016 5:40 PM, Steve Dower wrote:

On 29Aug2016 1433, Eric V. Smith wrote:

On 8/29/2016 5:26 PM, Ethan Furman wrote:

Update the PEP, then it's a bugfix.  ;)


Heh. I guess that's true. But it's sort of a big change, so shipping
beta 1 with the code not agreeing with the PEP rubs me the wrong way.

Or, I could stop worrying and typing emails, and instead just get on
with it!


I like this approach :)

But I agree. Release Manager Ned has the final say, but I think this
change can comfortably go in during the beta period. (I also disagree
that it's a big change - nobody could agree on the 'obvious' behaviour
of backslashes anyway, so chances are people would avoid them anyway,
and there was strong consensus on advising people to avoid them.)


By "big", I meant "a lot of C code changes". And you'd be surprised by 
the percentage of the tests that are devoted to backslashes inside braces!


Eric.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Alex Rudy]

> On Aug 29, 2016, at 06:08, Erik Bray  wrote:
> 
> On Mon, Aug 29, 2016 at 3:05 PM, Erik Bray  > wrote:
>> On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert
>>  wrote:
>>> 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
>> become:
>> 
>>780kpc -> 7.8e+05
 [...]
 
 For the record, I don't know what kpc might mean. "kilo pico speed of
 light"? So I looked it up using units, and it is kilo-parsecs. That
 demonstrates that unless your audience is intimately familiar with the
 domain you are working with, adding units (especially units that aren't
 actually used for anything) adds confusion.
 
 Python is not a specialist application targetted at a single domain. It
 is a general purpose programming language where you can expect a lot of
 cross-domain people (e.g. a system administrator asked to hack on a
 script in a domain they know nothing about).
>>> 
>>> 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 enthusiastic because using it would require
>>>   convincing the rest of the group, which would be too much effort.
>>> 3. She was amused by the "kilo pico speed of light" comment, but she was 
>>> adamant
>>>   that the fact that you, or some system administrator, does not understand
>>>   what kpc means has absolutely no affect on her desired to use SI scale
>>>   factors. Her comment: I did not write it for him.
>>> 4. She pointed out that the software she writes and uses is intended either 
>>> for
>>>   herself of other astrophysicists. No system administrators involved.
>> 
>> Astropy also has a very powerful units package--originally derived
>> from pyunit I think but long since diverged and grown:
>> 
>> http://docs.astropy.org/en/stable/units/index.html
>> 
>> It was originally developed especially for astronomy/astrophysics use
>> and has some pre-defined units that many other packages don't have, as
>> well as support for logarithmic units like decibel and optional (and
>> customizeable) unit equivalences (e.g. frequency/wavelength or
>> flux/power).
>> 
>> That said, its power extends beyond astronomy and I heard through last
>> week's EuroScipy that even some biology people have been using it.
>> There's been some (informal) talk about splitting it out from Astropy
>> into a stand-alone package.  This is tricky since almost everything in
>> Astropy has been built around it (dimensional calculations are always
>> used where possible), but not impossible.
>> 
>> One of the other big advantages of astropy.units is the Quantity class
>> representing scale+dimension values.  This is deeply integrated into
>> Numpy so that units can be attached to Numpy arrays, and all Numpy
>> ufuncs can operate on them in a dimensionally meaningful way.  The
>> needs for this have driven a number of recent features in Numpy.  This
>> is work that, unfortunately, could never be integrated into the Python
>> stdlib.
> 
> I'll also add that syntactic support for units has rarely been an
> issue in Astropy.  The existing algebraic rules for units work fine
> with Python's existing order of operations.  It can be *nice* to be
> able to write "1m" instead of "1 * m" but ultimately it doesn't add
> much for clarity (and if really desired could be handled with a
> preparser--something I've considered adding for Astropy sources (via
> codecs).

I just want to add, as an astrophysicist who uses astropy.units: the astropy 
solution is pretty great, and I don’t mind the library overhead. I’d much 
rather have astropy.units, which does dimensional analysis, as well as handling 
SI prefixes for 2 reasons:
1. I don’t normally see or use SI prefixes without units, so bare SI prefixes 
are fairly worthless to me as a scientist. IF the units are going to be there, 
I’d much rather have a library that does a good job at dimensional analysis, 
and has taken my domain-specific concerns into account, for reasons fairly well 
covered in this thread.
2. I don’t find it cumbersome at all to use something like astropy.units which 
provides both the prefix and units for my code on input and output. The added 
syntactic weight of a single import, plus multiplication, is really not that 
big a burden, and makes it both clear what I am trying to write, and easy for 
the library to maintain this meaning when I use the variable later. e.g.
from astropy.units import *
distance = 10 * km

If that multiplication symbol is really 

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Ethan Furman]

On 08/29/2016 02:16 PM, Eric V. Smith wrote:


I've been looking at this, and I agree it's the best thing to do, for
now (and possibly forever).

I'm just not convinced I can get it done before alpha 1.


Isn't the f-string feature already in place?

Update the PEP, then it's a bugfix.  ;)

--
~Ethan~
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Eric V. Smith]

Oops, I meant beta 1 where I said alpha 1.

Eric.

On 8/29/2016 5:12 PM, Eric V. Smith wrote:

On 8/23/2016 8:18 AM, Nick Coghlan wrote:

On 21 August 2016 at 03:32, Eric V. Smith  wrote:

If anything, I'd make it an error to have any backslashes inside the
brackets of an f-string for 3.6. We could always remove this
restriction at
a later date.


+1 for this if you can find a way to do it - it eliminates the
problematic cases where the order of evaluation makes a difference,
and ensures the parts within the braces can be reliably processed as
normal Python code.


I've been looking at this, and I agree it's the best thing to do, for
now (and possibly forever).

I'm just not convinced I can get it done before alpha 1. Assuming I can
get the coding done, I think I should update PEP 498 to say there can be
no backslashes inside the curly braces. That's my preferred outcome.

If I can't get it done by alpha 1, then I think the options are:
1. Leave f-strings as they are now, and that's how they'll always be.
2. Leave f-strings as they are now, but mark them as provisional and
   warn people that the backslash restrictions will show up in an
   upcoming release.
3. Disallow any backslashes anywhere in f-strings for 3.6, and relax the
   restriction in 3.7 to make it only inside braces where the
   restriction is enforced.
4. Remove f-strings from 3.6, and add them in 3.7 with the "no backslash
   inside braces" restriction.

I'm not wild about 2: people will ignore this and will write code that
will break in 3.7. I'm also not wild about 3, since it's too restrictive.

I'm open to suggestions.

Eric.



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Sven R. Kunze]

I didn't follow the previous discussion so far, so excuse me if I repeat 
something somebody already mentioned. But these are intriguing points 
you made here.


On 29.08.2016 09:31, Ken Kundert wrote:

The reason why hexadecimal and octal are in general purpose languages and real
numbers with SI scale factors are not is because languages are developed by
computer scientists and not by scientists. I keep using SPICE and Verilog as
examples of a languages that supports SI scale factors, and that is because they
are the extremely rare cases where the languages were either developed or
specified by end users and not by computer scientists.

The reason why computer scientists tend to add hexadecimal and octal numbers to
their languages and not SI scale factors is that they use hexadecimal and octal
numbers, and as we have seen by this discussion, are rather unfamiliar with real
numbers with SI scale factors. It is easy for them to justify adding hex because
they know from personal experience that it is useful, but if you don't use
widely scaled real numbers day in and day out it is hard to understand just how
tedious exponential notation is and how useful it would be to use SI scale
factors.


I didn't know that THERE ARE languages that already feature SI factors. 
You could be right about their development.


I for one wouldn't have an issue with this being in Python for the 
following reasons:


1) I wouldn't use it as I don't have the use-cases right now
2) if I would need to read such code, it wouldn't hurt my reading 
experience as I am used to SI
3) there will be two classes of code here: a) code that has use for it 
and thus uses it quite extensively and code that doesn't; depending on 
where you work you will encounter this feature or you don't even know it 
exists (this is true for many features in Python which is a good thing: 
each domain should use what is the best tool for them)



The biggest issue I have is the following: SI scale factors without SI 
units do not make much sense, I think (especially considering those 
syntax changes). So, the potential, if any, can only illustrated in 
combination with them. But Python does not feature any SI units so far 
as those are provided by external packages. If you can resolve that I am 
+1 on this proposal, but otherwise just +0.


Sven


PS: If I think about it this way, I might have a use-case in a small 
side-project.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Eric V. Smith]

On 8/23/2016 8:18 AM, Nick Coghlan wrote:

On 21 August 2016 at 03:32, Eric V. Smith  wrote:

If anything, I'd make it an error to have any backslashes inside the
brackets of an f-string for 3.6. We could always remove this restriction at
a later date.


+1 for this if you can find a way to do it - it eliminates the
problematic cases where the order of evaluation makes a difference,
and ensures the parts within the braces can be reliably processed as
normal Python code.


I've been looking at this, and I agree it's the best thing to do, for 
now (and possibly forever).


I'm just not convinced I can get it done before alpha 1. Assuming I can 
get the coding done, I think I should update PEP 498 to say there can be 
no backslashes inside the curly braces. That's my preferred outcome.


If I can't get it done by alpha 1, then I think the options are:
1. Leave f-strings as they are now, and that's how they'll always be.
2. Leave f-strings as they are now, but mark them as provisional and
   warn people that the backslash restrictions will show up in an
   upcoming release.
3. Disallow any backslashes anywhere in f-strings for 3.6, and relax the
   restriction in 3.7 to make it only inside braces where the
   restriction is enforced.
4. Remove f-strings from 3.6, and add them in 3.7 with the "no backslash
   inside braces" restriction.

I'm not wild about 2: people will ignore this and will write code that 
will break in 3.7. I'm also not wild about 3, since it's too restrictive.


I'm open to suggestions.

Eric.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Sven R. Kunze]

On 29.08.2016 11:37, Chris Angelico wrote:

That's why I keep asking you for code examples. Real-world code, taken
from important projects, that would be significantly improved by this
proposal.


There was no reasonable real-world code examples taken from important 
projects, that would be significantly improved by underscores in numbers.


Still, we got them, so your argument here is void.


It has to be Python 3 compatible (unless you reckon that
this is the killer feature that will make people take the jump from
2.7), and it has to be enough of an improvement that its authors will
be willing to drop support for <3.6 (which might be a trivial concern,
eg if the author expects to be the only person running the code).
All of those "has to be"s are optional (cf. underscores in numbers) and 
that's not different for this proposal.


Sven

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Sven R. Kunze]

On 29.08.2016 05:40, Brendan Barnwell wrote:

On 2016-08-28 20:29, Ken Kundert wrote:

What is wrong with have two ways of doing things? We have many ways of
specifying the value of the integer 16: 0b1, 0o20, 16, 0x10, 16L, 



Zen of Python: "There should be one-- and preferably only one 
--obvious way to do it."


If Python didn't have binary or octal notation and someone came 
here proposing it, I would not support it, for the same reasons I 
don't support your proposal.  If someone proposed eliminating binary 
or octal notation for Python 4 (or even maybe Python 3.8), I would 
probably support it for the same reason. Those notations are not 
useful enough to justify their existence. Hexadecimal is more 
justifiable as it is far more widely used, but I would be more open to 
removing hexadecimal than I would be to adding octal.


Also, "L" as a long-integer suffix is already gone in Python 3.



And now we have '_' in numbers.

So much for "preferably one way".


Sven
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] A proposal to rename the term "duck typing"

[Erik Bray]

On Sun, Aug 28, 2016 at 7:41 PM, Bruce Leban  wrote:
>
>
> On Sunday, August 28, 2016, ROGER GRAYDON CHRISTMAN  wrote:
>>
>>
>> We have a term in our lexicon "duck typing" that traces its origins, in
>> part to a quote along the lines of
>> "If it walks like a duck, and talks like a duck, ..."
>>
>> ...
>>
>> In that case, it would be far more appropriate for use to call this sort
>> of type analysis "witch typing"
>
>
> I believe the duck is out of the bag on this one. First the "duck test" that
> you quote above is over 100 years old.
> https://en.m.wikipedia.org/wiki/Duck_test So that's entrenched.
>
> Second this isn't a Python-only term anymore and language is notoriously
> hard to change prescriptively.
>
> Third I think the duck test is more appropriate than the witch test which
> involves the testers faking the results.

Agreed.

It's also fairly problematic given that you're deriving the term from
a sketch about witch hunts.  While the Monty Python sketch is
hilarious and, it's the ignorant mob that's the butt of the joke
rather than the "witch", this joke doesn't necessarily play well
universally, especially given that there places today where women are
being killed for being "witches".

Best,
Erik
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Erik Bray]

On Mon, Aug 29, 2016 at 3:05 PM, Erik Bray  wrote:
> On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert
>  wrote:
>> 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
>>> > >become:
>>> > >
>>> > > 780kpc -> 7.8e+05
>>> [...]
>>>
>>> For the record, I don't know what kpc might mean. "kilo pico speed of
>>> light"? So I looked it up using units, and it is kilo-parsecs. That
>>> demonstrates that unless your audience is intimately familiar with the
>>> domain you are working with, adding units (especially units that aren't
>>> actually used for anything) adds confusion.
>>>
>>> Python is not a specialist application targetted at a single domain. It
>>> is a general purpose programming language where you can expect a lot of
>>> cross-domain people (e.g. a system administrator asked to hack on a
>>> script in a domain they know nothing about).
>>
>> 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 enthusiastic because using it would require
>>convincing the rest of the group, which would be too much effort.
>> 3. She was amused by the "kilo pico speed of light" comment, but she was 
>> adamant
>>that the fact that you, or some system administrator, does not understand
>>what kpc means has absolutely no affect on her desired to use SI scale
>>factors. Her comment: I did not write it for him.
>> 4. She pointed out that the software she writes and uses is intended either 
>> for
>>herself of other astrophysicists. No system administrators involved.
>
> Astropy also has a very powerful units package--originally derived
> from pyunit I think but long since diverged and grown:
>
> http://docs.astropy.org/en/stable/units/index.html
>
> It was originally developed especially for astronomy/astrophysics use
> and has some pre-defined units that many other packages don't have, as
> well as support for logarithmic units like decibel and optional (and
> customizeable) unit equivalences (e.g. frequency/wavelength or
> flux/power).
>
> That said, its power extends beyond astronomy and I heard through last
> week's EuroScipy that even some biology people have been using it.
> There's been some (informal) talk about splitting it out from Astropy
> into a stand-alone package.  This is tricky since almost everything in
> Astropy has been built around it (dimensional calculations are always
> used where possible), but not impossible.
>
> One of the other big advantages of astropy.units is the Quantity class
> representing scale+dimension values.  This is deeply integrated into
> Numpy so that units can be attached to Numpy arrays, and all Numpy
> ufuncs can operate on them in a dimensionally meaningful way.  The
> needs for this have driven a number of recent features in Numpy.  This
> is work that, unfortunately, could never be integrated into the Python
> stdlib.

I'll also add that syntactic support for units has rarely been an
issue in Astropy.  The existing algebraic rules for units work fine
with Python's existing order of operations.  It can be *nice* to be
able to write "1m" instead of "1 * m" but ultimately it doesn't add
much for clarity (and if really desired could be handled with a
preparser--something I've considered adding for Astropy sources (via
codecs).

Best,
Erik
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Erik Bray]

On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert
 wrote:
> 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
>> > >become:
>> > >
>> > > 780kpc -> 7.8e+05
>> [...]
>>
>> For the record, I don't know what kpc might mean. "kilo pico speed of
>> light"? So I looked it up using units, and it is kilo-parsecs. That
>> demonstrates that unless your audience is intimately familiar with the
>> domain you are working with, adding units (especially units that aren't
>> actually used for anything) adds confusion.
>>
>> Python is not a specialist application targetted at a single domain. It
>> is a general purpose programming language where you can expect a lot of
>> cross-domain people (e.g. a system administrator asked to hack on a
>> script in a domain they know nothing about).
>
> 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 enthusiastic because using it would require
>convincing the rest of the group, which would be too much effort.
> 3. She was amused by the "kilo pico speed of light" comment, but she was 
> adamant
>that the fact that you, or some system administrator, does not understand
>what kpc means has absolutely no affect on her desired to use SI scale
>factors. Her comment: I did not write it for him.
> 4. She pointed out that the software she writes and uses is intended either 
> for
>herself of other astrophysicists. No system administrators involved.

Astropy also has a very powerful units package--originally derived
from pyunit I think but long since diverged and grown:

http://docs.astropy.org/en/stable/units/index.html

It was originally developed especially for astronomy/astrophysics use
and has some pre-defined units that many other packages don't have, as
well as support for logarithmic units like decibel and optional (and
customizeable) unit equivalences (e.g. frequency/wavelength or
flux/power).

That said, its power extends beyond astronomy and I heard through last
week's EuroScipy that even some biology people have been using it.
There's been some (informal) talk about splitting it out from Astropy
into a stand-alone package.  This is tricky since almost everything in
Astropy has been built around it (dimensional calculations are always
used where possible), but not impossible.

One of the other big advantages of astropy.units is the Quantity class
representing scale+dimension values.  This is deeply integrated into
Numpy so that units can be attached to Numpy arrays, and all Numpy
ufuncs can operate on them in a dimensionally meaningful way.  The
needs for this have driven a number of recent features in Numpy.  This
is work that, unfortunately, could never be integrated into the Python
stdlib.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Mark Lawrence via Python-ideas]

On 29/08/2016 13:35, Stephan Houben wrote:

Note that the Sage computer algebra system uses Python with some
syntactic changes implemented by a "pre-parser".

The current proposal could be implemented in a similar way and then
integrated in, say, Ipython.

If it would prove to be wildly popular, then it would make a stronger
case for incorporation in the core.

Stephan


Op 29 aug. 2016 2:12 p.m. schreef "Mark Lawrence via Python-ideas"
>:

On 29/08/2016 02:44, Ken Kundert wrote:


Changing Python so that it understands SI scale factors on real
numbers as first
class citizens innately requires a change to the base language;
it cannot be
done solely through libraries.  The question before you is,
should we do it?

No, no, no, if the people who provide this http://www.scipy.org/ can
do without it.

Now would you please be kind enough to give up with this dead horse
before I take a ride to the Clifton Suspension Bridge or Beachy
Head, whichever is closest.



As iPython is a core part of scipy, which I linked above, why would the 
developers want to incorporate this suggestion?  I'd have also thought 
that if this idea was to be "wildly popular" it would have been done 
years ago.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Stephan Houben]

Note that the Sage computer algebra system uses Python with some syntactic
changes implemented by a "pre-parser".

The current proposal could be implemented in a similar way and then
integrated in, say, Ipython.

If it would prove to be wildly popular, then it would make a stronger case
for incorporation in the core.

Stephan

Op 29 aug. 2016 2:12 p.m. schreef "Mark Lawrence via Python-ideas" <
python-ideas@python.org>:

> On 29/08/2016 02:44, Ken Kundert wrote:
>
>>
>> Changing Python so that it understands SI scale factors on real numbers
>> as first
>> class citizens innately requires a change to the base language; it cannot
>> be
>> done solely through libraries.  The question before you is, should we do
>> it?
>>
>>
> No, no, no, if the people who provide this http://www.scipy.org/ can do
> without it.
>
> Now would you please be kind enough to give up with this dead horse before
> I take a ride to the Clifton Suspension Bridge or Beachy Head, whichever is
> closest.
>
> --
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
>
> Mark Lawrence
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Mark Lawrence via Python-ideas]

On 29/08/2016 02:44, Ken Kundert wrote:


Changing Python so that it understands SI scale factors on real numbers as first
class citizens innately requires a change to the base language; it cannot be
done solely through libraries.  The question before you is, should we do it?



No, no, no, if the people who provide this http://www.scipy.org/ can do 
without it.


Now would you please be kind enough to give up with this dead horse 
before I take a ride to the Clifton Suspension Bridge or Beachy Head, 
whichever is closest.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[David Mertz]

I teach working scientists about numeric computing on a daily basis. There
are a few special field where Ken's ideas are the norm, at least in
informal notation. The large majority of working scientists would find a
syntax change like he proposes an annoyance and nuisance.

Alienating and confusing everyone who isn't a circuit designer is a bad
goal. It's not going to happen in python.

If you really want this syntax, you need to use a different language, or
maybe write a preprocessor that turns a slightly different language back
into Python.

On Aug 29, 2016 4:09 AM, "Ken Kundert"  wrote:

> > > 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 benefit from this. Show us how it's better.
>
> Sorry, I am trying very hard not to let my emotions show through, and
> instead
> provide answers, examples, and comments that are well reasoned and well
> supported. I do find it frustrating that I appear to be the only one
> involved in
> the conversation that has a strong background in numerical computation,
> meaning
> that I have to carry one side of the argument without any support. It is
> especially frustrating when that background is used as a reason to
> discount my
> position. Let me try to make the case in an unemotional way.
>
> It is hard to justify the need for SI scale factors being built into the
> language with an example because it is relatively simple to do the
> conversion.
> For example ...
>
> With built-in support for SI scale factors:
>
> h_line = 1.4204GHz
> print('hline = {:r}Hz'.format(h_line))
> ...
>
> In Python today:
>
> from engfmt import Quantity
> h_line = Quantity('1.4204GHz')
> print('hline = {:q}'.format(h_line))
> h_line = float(h_line)
> ...
>
> Not really much harder to use the library. This is very similar to the
> situation
> with octal numbers ...
>
> With built-in support for octal numbers:
>
> S_IFREG  = 0o10  # regular file
>
> With out built-in support for octal numbers:
>
> S_IFREG  = int('10', base=8)  # regular file
>
> So just giving a simple example is not enough to see the importance of
> native
> support. The problem with using a library is that you always have to
> convert
> from SI scale factors as the number is input and then converting back as
> the
> number is output. So you can spend a fair amount of effort converting too
> and
> from representations that support SI scale factors. Not a big deal if
> there is
> only a few, but can be burdensome if there is a large number. But the real
> benefit to building it in a native capability is that it puts pressure on
> the
> rest of the ecosystem to also adopt the new way of representing real
> numbers.
> For example, now the interchange packages and formats (Pickle, YaML, etc.)
> need
> to come up with a way of passing the information without losing its
> essential
> character.  This in turn puts pressure on other languages to follow suit.
> It
> would also put pressure on documenting and formatting packages, such as
> Sphinx,
> Jinja, and matplotlib, to adapt. Now it becomes easier to generate clean
> documentation.  Also the interactive environments, such as ipython, need to
> adapt. The more this occurs, the better life gets for scientists and
> engineers.
>
>
> > Something that I don't think you've acknowledged is that the SI
> > scaling markers are *prefixes to units*, not *suffixes to numbers*.
> > That is to say, you don't have "132G" of a thing called a "pascal",
> > you have "132" of a thing called a "gigapascal". Outside of a
> > unit-based system, SI prefixes don't really have meaning. I don't
> > remember ever, in a scientific context, seeing a coefficient of
> > friction listed as "30 milli-something"; it's always "0.03". So if
> > unitless values are simply numbers, and Python's ints and floats are
> > unitless, they won't see much benefit from prefixes-on-nothing.
>
> Yeah, this is why I suggested that we support the ability for users to
> specify
> units with the numbers, but it is not a hard and fast rule. Once you add
> support
> for SI scale factors, people find them so convenient that they tend to use
> them
> whether they are units or not. For example, it is common for circuit
> designers
> to specify the gain of an amplifier using SI scale factors even though
> gain is
> often unitless. For example, gain=50k. Also, electrical engineers will
> often
> drop the units when they are obvious, especially if they are long. For
> example,
> it is common to see a resistance specified as 100k. When values are given
> in
> a table and all the values in a column have the same units, it is common
> to give
> numbers with scale factors by without units to save space.
>
> -Ken
> 

Re: [Python-ideas] a multiProcess scheduler

[Nick Coghlan]

On 29 August 2016 at 15:53, Thales filizola costa  wrote:
> Hi Nick,
>
> I have just checked all the links you posted, they are indeed very
> interesting and very efficient. However, I think those are very complicate
> in terms of installation and setup, and I still see a lot of usages for a
> multi-process scheduler.

Potentially, but one of the big challenges you'll face is to establish
how it differs from using asyncio in the current process to manage
tasks dispatched to other processes via run_in_executor, and when
specifically it would be useful thing for a developer to have in the
builtin toolkit (vs being something they can install from PyPI).

Don't get me wrong, I think it's really cool that you were able to
implement this - there's just a big gap between "implementing this was
useful to me" and "this is sufficiently useful in a wide enough range
of cases not otherwise addressed by the standard library that it
should be added as a new standard application building block".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Terry Reedy]

On 8/28/2016 9:44 PM, Ken Kundert wrote:


The way the scientific and engineering communities predominately write real
numbers is by using SI scale factors.


I don't believe it, not with naked scale factors as you have proposed. 
I have worked in science and I never saw naked scale factors until this 
proposal.  The scale factors are usually attached to units.



These numbers almost always represent
physical quantities, so it is common to write the number with scale factor and
units.


The scale factor is part of the unit, and people now learn this in grade 
school, I presume.



 So for example, the distance to Andromeda is 780kpc, the pressure at the
bottom of the Mariana Trench is 108MPa, the total power produced by a typical
hurricane is 600TW, the number of base pairs in human DNA is 3.2Gb, and the Bohr
radius is 53pm.


These are all scaled units and to me not relevant to the proposed 
addition of scale factors without units.


At this point I quit reading.

--
Terry Jan Reedy

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Ken Kundert]

> > 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 benefit from this. Show us how it's better.

Sorry, I am trying very hard not to let my emotions show through, and instead 
provide answers, examples, and comments that are well reasoned and well 
supported. I do find it frustrating that I appear to be the only one involved 
in 
the conversation that has a strong background in numerical computation, meaning 
that I have to carry one side of the argument without any support. It is 
especially frustrating when that background is used as a reason to discount my 
position. Let me try to make the case in an unemotional way.

It is hard to justify the need for SI scale factors being built into the 
language with an example because it is relatively simple to do the conversion.  
For example ...

With built-in support for SI scale factors:

h_line = 1.4204GHz
print('hline = {:r}Hz'.format(h_line))
...

In Python today: 

from engfmt import Quantity
h_line = Quantity('1.4204GHz')
print('hline = {:q}'.format(h_line))
h_line = float(h_line)
...

Not really much harder to use the library. This is very similar to the 
situation 
with octal numbers ...

With built-in support for octal numbers:

S_IFREG  = 0o10  # regular file

With out built-in support for octal numbers:

S_IFREG  = int('10', base=8)  # regular file

So just giving a simple example is not enough to see the importance of native 
support. The problem with using a library is that you always have to convert 
from SI scale factors as the number is input and then converting back as the 
number is output. So you can spend a fair amount of effort converting too and 
from representations that support SI scale factors. Not a big deal if there is 
only a few, but can be burdensome if there is a large number. But the real 
benefit to building it in a native capability is that it puts pressure on the 
rest of the ecosystem to also adopt the new way of representing real numbers.  
For example, now the interchange packages and formats (Pickle, YaML, etc.) need 
to come up with a way of passing the information without losing its essential 
character.  This in turn puts pressure on other languages to follow suit. It 
would also put pressure on documenting and formatting packages, such as Sphinx,
Jinja, and matplotlib, to adapt. Now it becomes easier to generate clean 
documentation.  Also the interactive environments, such as ipython, need to 
adapt. The more this occurs, the better life gets for scientists and engineers.


> Something that I don't think you've acknowledged is that the SI
> scaling markers are *prefixes to units*, not *suffixes to numbers*.
> That is to say, you don't have "132G" of a thing called a "pascal",
> you have "132" of a thing called a "gigapascal". Outside of a
> unit-based system, SI prefixes don't really have meaning. I don't
> remember ever, in a scientific context, seeing a coefficient of
> friction listed as "30 milli-something"; it's always "0.03". So if
> unitless values are simply numbers, and Python's ints and floats are
> unitless, they won't see much benefit from prefixes-on-nothing.

Yeah, this is why I suggested that we support the ability for users to specify 
units with the numbers, but it is not a hard and fast rule. Once you add 
support 
for SI scale factors, people find them so convenient that they tend to use them 
whether they are units or not. For example, it is common for circuit designers 
to specify the gain of an amplifier using SI scale factors even though gain is 
often unitless. For example, gain=50k. Also, electrical engineers will often 
drop the units when they are obvious, especially if they are long. For example, 
it is common to see a resistance specified as 100k. When values are given in 
a table and all the values in a column have the same units, it is common to 
give 
numbers with scale factors by without units to save space.

-Ken
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Ken Kundert]

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)
> > > >works really well. But Python users do not belong to a single tightly
> > > >focussed user community.
> > You think that Python is only used by generalists?  That is silly. Have you 
> > seen
> > SciPy? If you think that, take a look at Casa (casaguides.nrao.edu). It is
> > written by astrophysicists for astrophysicists doing observations on radio
> > telescope arrays. That is pretty specialized.
> 
>   I think you misunderstand.  My position (reiterated by the text you 
> quote
> from Steven D'Aprano) is not that Python is used only by generalists.  It is
> that we shouldn't change Python in a way that ONLY helps specialists.
> 

But surely we should consider changing Python if the change benefits a wide 
variety of specialists, especially if the change is small and fits cleanly into 
the language.

In this case, our specialists come from most of the disciplines of science and 
engineering. That is a pretty big group.

-Ken
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Ken Kundert]

> 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
numbers with SI scale factors are not is because languages are developed by
computer scientists and not by scientists. I keep using SPICE and Verilog as
examples of a languages that supports SI scale factors, and that is because they
are the extremely rare cases where the languages were either developed or
specified by end users and not by computer scientists.

The reason why computer scientists tend to add hexadecimal and octal numbers to
their languages and not SI scale factors is that they use hexadecimal and octal
numbers, and as we have seen by this discussion, are rather unfamiliar with real
numbers with SI scale factors. It is easy for them to justify adding hex because
they know from personal experience that it is useful, but if you don't use
widely scaled real numbers day in and day out it is hard to understand just how
tedious exponential notation is and how useful it would be to use SI scale
factors.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Brendan Barnwell]

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)
>works really well. But Python users do not belong to a single tightly
>focussed user community.

You think that Python is only used by generalists?  That is silly. Have you seen
SciPy? If you think that, take a look at Casa (casaguides.nrao.edu). It is
written by astrophysicists for astrophysicists doing observations on radio
telescope arrays. That is pretty specialized.


	I think you misunderstand.  My position (reiterated by the text you 
quote from Steven D'Aprano) is not that Python is used only by 
generalists.  It is that we shouldn't change Python in a way that ONLY 
helps specialists.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Ken Kundert]

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
> > >become:
> > >
> > > 780kpc -> 7.8e+05
> [...]
> 
> For the record, I don't know what kpc might mean. "kilo pico speed of 
> light"? So I looked it up using units, and it is kilo-parsecs. That 
> demonstrates that unless your audience is intimately familiar with the 
> domain you are working with, adding units (especially units that aren't 
> actually used for anything) adds confusion.
> 
> Python is not a specialist application targetted at a single domain. It 
> is a general purpose programming language where you can expect a lot of 
> cross-domain people (e.g. a system administrator asked to hack on a 
> script in a domain they know nothing about).

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 enthusiastic because using it would require 
   convincing the rest of the group, which would be too much effort.
3. She was amused by the "kilo pico speed of light" comment, but she was 
adamant 
   that the fact that you, or some system administrator, does not understand 
   what kpc means has absolutely no affect on her desired to use SI scale 
   factors. Her comment: I did not write it for him.
4. She pointed out that the software she writes and uses is intended either for 
   herself of other astrophysicists. No system administrators involved.

> > You've continually repeated this assertion, but I don't buy it.  For 
> > the general case, exponential notation is easier to read because you can 
> > always see exactly what the exponent is as a number.  To read SI units, 
> > you have to know all the SI prefixes.  This may well be common within 
> > scientific communities, but to say that it is "easier" is really a bit 
> > much.  The same is true of "harder to type".  "kpc" is three characters; 
> > e+5 is also three (note that you don't need to write e+05), 
> 
> You don't have to write e+5 either, just e5 is sufficient.
> 
> > and one of 
> > those is a number that transparently indicates how many places to move 
> > the decimal, whereas all of the letters in "kpc" are opaque unless you 
> > already know what the number is meant to represent.
> > 
> > If you have concrete evidence (e.g., from actual user experience 
> > research) showing that it is across-the-board "easier" to read or type 
> > SI prefixes than exponential notation, that would be good to see.
> 
> I completely believe Ken that within a single tightly focussed user 
> community, using their expected conventions (including SI prefixes) 
> works really well. But Python users do not belong to a single tightly 
> focussed user community.

You think that Python is only used by generalists?  That is silly. Have you 
seen 
SciPy? If you think that, take a look at Casa (casaguides.nrao.edu). It is 
written by astrophysicists for astrophysicists doing observations on radio 
telescope arrays. That is pretty specialized.

-Ken

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/