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

[Stephen J. Turnbull]

Sven R. Kunze writes:

 > And now we have '_' in numbers.
 > 
 > So much for "preferably one way".

Poor example.  There used to be no way to group long strings of
numerals for better readability.  Now there is exactly one way.

The Zen is not an axe.  It's a scalpel.
___
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] Force UTF-8 option regardless locale

[Victor Stinner]

Le 30 août 2016 02:05, "INADA Naoki"  a écrit :
> How should the option be set?

I propose to add a new -X utf8 option. Maybe if the use case is important,
we might add an PYTHONUTF8 environment variable.

The problem is that I'm not sure that an env var is the right way to
configure Python on such environment? But an env var shouldn't hurt and it
is common to add a new env var with a new cmdline option.

I added PYTHONFAULTHANDLER=1/-X faulthandler for faulthandler and
PYTHONTRACEMALLOC=N/-X tracemalloc=N for tracemalloc.

Victor
___
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

[Terry Reedy]

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

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

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?


Yes. It's been in 3.6 for quite a while (maybe a year?).


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


You can do bug fixes during the beta series.


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!

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/




--
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

[Paul Moore]

On 30 August 2016 at 04:19, Ken Kundert  wrote:
> Do you think there is no value to be able to naturally read and write numbers
> with SI scale factors from Python? Or is your issue with something about my
> proposal?

Ken,
Answering these questions from my perspective (and thanks for taking
note of the comments and toning down your delivery, by the way)

I have an issue with the way your proposal is vague about the
relationship between SI scales and units - it's been mentioned a
couple of times, but never adequately addressed, that scales are
tightly linked to units (we routinely talk about kilometers and
milligrams, but almost never about kilos or millis). There have been
some strong (and justified, IMO) objections to adding units without
giving them proper semantic meaning, and your response to that seems
to be to talk for a while about scale factors in isolation, but then
go straight back to examples using scaled units. It's hard to
understand exactly what you're proposing when your examples don't
match your suggestions.

If we assume you *are* simply talking about pure scales (k=1000,
M=100 etc), then you haven't addressed the many suggestions of
alternatives, with anything more substantive than "well, I (and
colleagues I know) prefer scale factors", plus some examples with
scaled *units* again. Your comparisons tend to show your preferred
approach in the best light, while using the least attractive
alternative options. And there's almost no proper discussions of pros
and cons. In short, you offer almost nothing in the way of objective
arguments for your proposals.

You mention "reading and writing numbers with scale factors from
Python". It's easy enough to do external IO with scale factors, you
just read strings and parse them as you wish. A language syntax only
affects internal constants - and it's not clear to me that the benefit
is significant even then, as I'd expect (as a matter of good style)
that any constant needing this type of syntax should be named anyway.
Again, this isn't something you address.

You've offered no examples of real-world code in existing public
projects that would be improved by your proposal. While that's not
always necessary to a successful proposal, it certainly makes it more
compelling, and helps to confirm that a proposal isn't limited to
"niche" areas.

So to summarise, I don't think you've made objective arguments for
your proposal (your *subjective* enthusiasm for the proposal has never
been in doubt), or addressed many of the comments that have already
been made.

To be honest, I don't think there's much chance of your proposal being
accepted at this point in time. As Steven noted, Python tends not to
be a leader in matters like this, and so the lack of mainstream prior
art is probably sufficient to kill this proposal. But for your own
benefit (and the benefit of any future proposals you may make in this
or other areas - please don't feel put off by the fact that this
specific proposal has met with a lot of resistance) you might want to
review the thread and consider what a PEP might look like for this
discussion, and how you would have incorporated and responded to the
objections raised here -
https://www.python.org/dev/peps/pep-0001/#what-belongs-in-a-successful-pep
is a good summary of the sort of things you should be looking at.
There's no need to actually complete a PEP or post it, the proposal
here hasn't reached a stage where a PEP is useful, but thinking about
the PEP structure might help you understand the context a bit better.

I hope this helps,
Paul
___
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 30.08.2016 04:34, David Mertz wrote:
On Mon, Aug 29, 2016 at 1:55 PM, Sven R. Kunze > wrote:


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


I recall dozens of real world examples that came up during the 
discussion, and have written very numerous such examples in code of my 
own.  This is something that directly affects readability in code I 
write almost every day, and is a clear and obvious win.
I taught examples *today* where I would have badly liked to have 
underscore separators, and it was obvious to me and students that 
awkwardness.  Writing, e.g. `range(int(1e7))` feel contrives (but 
usually the way I do it).  Writing `range(1000)` is nearly 
impossible to parse visually.  In contrast, writing 
`range(10_000_000)` will be immediately clear and obvious.


None of those things can be said of SI units as Python literals.


Hu? None of those things? I do think you exaggerate quite a lot here.

If your real-world example works for underscores, it works for SI units 
and scales as well.



I for one don't have usage of either, so having such a distance to the 
subject at hand, I don't see this as a compelling argument against/for 
his 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] Let’s make escaping in f-literals impossible

[Eric V. Smith]

On 08/30/2016 07:02 AM, Philipp A. wrote:
> Very cool of you to get this going!

Thanks for raising the issue.

> I hope the outcome is to ban escapes within braced code parts of
> f-literals for 3.6 and add them “the right way” in 3.7: f'foo{ bar['\n']
> }baz'

There's debate on if that's the right way, and I personally think it's
probably not. Personally, I'd be happy with the only change being to not
allow backslashes inside braces. But that's not an argument that I'm
willing to get into now, since I need to get this rolling for beta 1.

> Also the name “f-strings” is really misleading: They’re composite
> expressions that evaluate to strings. They can only be considered
> strings if you have no braced code parts in them. So I’m also still in
> favor of renaming them (e.g. to “f-literals”).

I don't have much of an opinion here. I think there's not a lot of
confusion to be had by calling them f-strings, but I think someone who
works with teaching python might have a better handle on that.

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] Let’s make escaping in f-literals impossible

[אלעזר]

> On Tue, Aug 30, 2016 at 3:13 PM Eric V. Smith  wrote:
> >On 08/30/2016 07:02 AM, Philipp A. wrote:
> > Also the name “f-strings” is really misleading: They’re composite
> > expressions that evaluate to strings. They can only be considered
> > strings if you have no braced code parts in them. So I’m also still in
> > favor of renaming them (e.g. to “f-literals”).
> I don't have much of an opinion here. I think there's not a lot of
> confusion to be had by calling them f-strings, but I think someone who
> works with teaching python might have a better handle on that.

The problem is that "literal" is a technical term in the domain of
compilers, and not a well known or self-explanatory term. Especially for
beginners. I'd suggest something like "Format expression".

~Elazar
___
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

[Philipp A.]

Eric V. Smith  schrieb am Di., 30. Aug. 2016 um
14:13 Uhr:

> There's debate on if that's the right way, and I personally think it's
> probably not. Personally, I'd be happy with the only change being to not
> allow backslashes inside braces. But that's not an argument that I'm
> willing to get into now, since I need to get this rolling for beta 1.


And exactly that’s why i’m very happy with the way things are going:

Banning escapes is the right short term solution, and possibly the best
compromise if we can’t find consensus on how escapes should behave inside
of those braces.

‪‫אלעזר‬‎  schrieb am Di., 30. Aug. 2016 um 14:37 Uhr:‬

> The problem is that "literal" is a technical term in the domain of
> compilers, and not a well known or self-explanatory term. Especially for
> beginners. I'd suggest something like "Format expression".
>

That sounds fine as well!

My issue is just that it’s as much of a string as a call of a (string
returning) function/method or an expression concatenating strings:

''.join(things)   # would you call this a string?
'{!r}'.format(x)  # or this? it’s basically the same as this “f-string”:
f'{x!r}'
'start' + 'end'   # or this? it’s a concatenation of two strings, just like
f'start{ "end" }'

Best, Philipp
___
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

[Philipp A.]

Hi Eric,

Very cool of you to get this going!

I hope the outcome is to ban escapes within braced code parts of f-literals
for 3.6 and add them “the right way” in 3.7: f'foo{ bar['\n'] }baz'

It really is how things work in every single language that i ever
encountered that has template literals / string interpolation / f-literals
/ whatchacallit, so in order to be logical and non-surprising, we should do
it that way (eventually).

Also the name “f-strings” is really misleading: They’re composite
expressions that evaluate to strings. They can only be considered
strings if you have no braced code parts in them. So I’m also still in
favor of renaming them (e.g. to “f-literals”).

Best, Philipp
___
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]

Chris,
I was not able to get an astrophyics example, but I do have a reasonable 
one 
that performs a spectral analysis of the output of an analog to digital 
converter, something radio astronomers are known to do.

I am including the code, but it requires a rather large data file to run, which 
I will not include.  The code uses my 'engfmt' library from pypi to perform 
conversion to SI form. In this example, there is no need for conversion from SI 
form.

#!/usr/bin/env python3

import numpy as np
from numpy.fft import fft, fftfreq, fftshift
import matplotlib as mpl
mpl.use('SVG')
from matplotlib.ticker import FuncFormatter
import matplotlib.pyplot as pl
from engfmt import Quantity, set_preferences
set_preferences(spacer=' ')

def mag(spectrum):
return np.absolute(spectrum)

def freq_fmt(val, pos):
return Quantity(val, 'Hz').to_eng()

def volt_fmt(val, pos):
return Quantity(val, 'V').to_eng()

freq_formatter = FuncFormatter(freq_fmt)
volt_formatter = FuncFormatter(volt_fmt)

data = np.fromfile('delta-sigma.smpl', sep=' ')

time, wave = data.reshape((2, len(data)//2), order='F')
timestep = time[1] - time[0]
nonperiodicity = wave[-1] - wave[0]
period = timestep * len(time)
print('timestep = {}'.format(Quantity(timestep, 's')))
print('nonperiodicity = {}'.format(Quantity(nonperiodicity, 'V')))
print('timepoints = {}'.format(len(time)))
print('freq resolution = {}'.format(Quantity(1/period, 'Hz')))

window = np.kaiser(len(time), 11)/0.37
# beta=11 corresponds to alpha=3.5 (beta = pi*alpha), /.4 # 0.4 is the 
# processing gain with alpha=3.5 is 0.37
#window = 1
windowed = window*wave

spectrum = 2*fftshift(fft(windowed))/len(time)
freq = fftshift(fftfreq(len(wave), timestep))

fig = pl.figure()
ax = fig.add_subplot(111)
ax.plot(freq, mag(spectrum))
ax.set_yscale('log')
ax.xaxis.set_major_formatter(freq_formatter)
ax.yaxis.set_major_formatter(volt_formatter)
pl.savefig('spectrum.svg')
ax.set_xlim((0, 1e6))
pl.savefig('spectrum-zoomed.svg')

When run, this program prints the following diagnostics to stdout:

timestep = 20 ns
nonperiodicity = 2.3 pV
timepoints = 27994
freq resolution = 1.7861 kHz

It also generates two SVG files. I have converted one to PNG and attached it.

A few comments:
1. The data in the input file ('delta-sigma.smpl') has low dynamic range and is 
   machine generated, and not really meant for direct human consumption. As 
   such, it does not benefit from using SI scale factors.  But there are 
   certainly cases where the data has both high dynamic range and is intended 
   for people to examine it directly. In those cases it would be very helpful 
if 
   NumPy was able to directly read the file.  As the language exists today, 
   I would need to read the file myself, manually convert it, and feed the 
   result to NumPy.
2. Many of these numbers that are output do have high dynamic range and are 
   intended to be consumed directly by humans. These benefit from using SI 
scale 
   factors.  For example, the 'freq resolution' can vary from Hz to MHz and 
   'nonperiodicity' can vary from fV to mV.
3. Extra effort was expended to make the axis labels on the graph use SI scale 
   factors so as to make the 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 06:02:29PM +1000, Chris Angelico wrote:
> On Mon, Aug 29, 2016 at 5:07 PM, Ken Kundert
>  wrote:
> >
> > 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.
> 
> So can you share some of her code, and show how the ability to scale
> unitless numbers would help it?
> 
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduc

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

[Steven D'Aprano]

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 
> spirit of SI scale factors, were you are generally expected to 'normalize' 
> the 
> scale factor (use the scale factor that results in the digits presented 
> before 
> the decimal point falling between 1 and 999). So I would expected
> 
> d_andromeda = 780 kpc
> d_sun = 4.8504 upc

Let me see if I get this straight... you *explicitly* asked for the 
distance to the sun in kpc (kiloparsecs), but you expected a result in 
µpc (microparsecs)?

When you ask the waiter for a short black, do you get upset that 
he doesn't bring you a latte with soy milk? *wink*

I can see that such a normalising function would be useful, but I don't 
think it should be the default. (If I ask for millimetres, I want 
millimetres, not gigametres.) I've written and used code like that for 
bytes, it makes sense to apply it to other measurement units. But only 
if the caller requests normalisation, never by default.

I don't think there is any such general expectation that values should 
be normalised in that way, and certainly not that your conversion 
program should automatically do it for you. For example, see this list 
of long-lived radioactive isotopes:

http://w.astro.berkeley.edu/~dperley/areopagus/isotopetable.html

Values above 650,000,000,000 (650e9) years are shown in "scientific 
format", not "engineering format", e.g. Selenium-82 is given 
as 1.1 x 10^20 rather than 110 x 10^18.

Likewise:

http://www.nist.gov/pml/data/halflife-html.cfm

displays a range of units (minutes, hours, days) with the base value 
ranging up to over ten thousand, e.g. Ti-44 is shown as 22154 ± 456 
days. This is NIST, which makes it pretty official. I don't think 
there's any general expectation that values should be shown in the range 
1 to 999. (Perhaps in certain specialist areas.)



-- 
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

[Chris Angelico]

On Tue, Aug 30, 2016 at 10:56 PM, Philipp A.  wrote:
> My issue is just that it’s as much of a string as a call of a (string
> returning) function/method or an expression concatenating strings:
>
> ''.join(things)   # would you call this a string?
> '{!r}'.format(x)  # or this? it’s basically the same as this “f-string”:
> f'{x!r}'
> 'start' + 'end'   # or this? it’s a concatenation of two strings, just like
> f'start{ "end" }'

Yes, an f-string is really a form of expression, not a literal. But
prior art has generally been to have similar constructs referred to as
"interpolated strings" or similar terms:

https://en.wikipedia.org/wiki/String_interpolation

Plenty of languages have some such feature, and it's usually
considered a type of string. Notice the close parallels between actual
string literals used as format strings ("I have %d apples" % apples)
and f-strings (f"I have {apples} apples"), and how this same parallel
can be seen in many other languages. Yes, it may be a join expression
to the compiler, but it's a string to the programmer.

ChrisA
___
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

[João Santos]

On Tue, 30 Aug 2016 at 12:48 Sven R. Kunze  wrote:

> On 30.08.2016 04:34, David Mertz wrote:
>
> On Mon, Aug 29, 2016 at 1:55 PM, Sven R. Kunze  wrote:
>
>> There was no reasonable real-world code examples taken from important
>> projects, that would be significantly improved by underscores in numbers.
>>
>
> I recall dozens of real world examples that came up during the discussion,
> and have written very numerous such examples in code of my own.  This is
> something that directly affects readability in code I write almost every
> day, and is a clear and obvious win.
>
> I taught examples *today* where I would have badly liked to have
> underscore separators, and it was obvious to me and students that
> awkwardness.  Writing, e.g. `range(int(1e7))` feel contrives (but usually
> the way I do it).  Writing `range(1000)` is nearly impossible to parse
> visually.  In contrast, writing `range(10_000_000)` will be immediately
> clear and obvious.
>
> None of those things can be said of SI units as Python literals.
>
>
> Hu? None of those things? I do think you exaggerate quite a lot here.
>
> If your real-world example works for underscores, it works for SI units
> and scales as well.
>
>
There is obvious way now:

G = Ghz = 1000
frequency = 1 * Ghz

You can even have a non naive version Ghz that supports conversions and
unit checking when doing arithmetic with it.
___
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

[Philipp A.]

Sorry, but I'm afraid you are projecting your thinking onto others.

The syntactical constructs are called “string interpolations”, not
“interpolated strings”. I.e. they're interpolations (a certain type of
action) on strings.

Strings are the objects, not the subjects. Strings are data, we have
code/expressions that look like strings with holes, but in reality, only
the parts outside of the braces are strings.

I hope I explained my semantics here adequately. Even if they're internally
post-processed strings in the CPython code: that's an implementation
detail, not a description of the way they work for Python users.

Best, Philipp

Chris Angelico  schrieb am Di., 30. Aug. 2016, 15:43:

> On Tue, Aug 30, 2016 at 10:56 PM, Philipp A.  wrote:
> > My issue is just that it’s as much of a string as a call of a (string
> > returning) function/method or an expression concatenating strings:
> >
> > ''.join(things)   # would you call this a string?
> > '{!r}'.format(x)  # or this? it’s basically the same as this “f-string”:
> > f'{x!r}'
> > 'start' + 'end'   # or this? it’s a concatenation of two strings, just
> like
> > f'start{ "end" }'
>
> Yes, an f-string is really a form of expression, not a literal. But
> prior art has generally been to have similar constructs referred to as
> "interpolated strings" or similar terms:
>
> https://en.wikipedia.org/wiki/String_interpolation
>
> Plenty of languages have some such feature, and it's usually
> considered a type of string. Notice the close parallels between actual
> string literals used as format strings ("I have %d apples" % apples)
> and f-strings (f"I have {apples} apples"), and how this same parallel
> can be seen in many other languages. Yes, it may be a join expression
> to the compiler, but it's a string to the programmer.
>
> ChrisA
> ___
> 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] Let’s make escaping in f-literals impossible

[Guido van Rossum]

Please just call it f-string and move on, we've had the naming debate
previously, it's no longer productive.

Regarding eventually supporting f'{'x'}', that will have to be a new
PEP to extend PEP 498. (I previously thought it would be an
incompatibility, but since f'{' is currently invalid, it's not.
However it's a huge change conceptually and implementation-wise, and I
don't blame Eric if he doesn't want to be responsible for it. So it
has to be a new PEP, to be introduced in 3.7 at the earliest.

-- 
--Guido van Rossum (python.org/~guido)
___
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

[Steven D'Aprano]

On Tue, Aug 30, 2016 at 11:43:03PM +1000, Chris Angelico wrote:
> On Tue, Aug 30, 2016 at 10:56 PM, Philipp A.  wrote:
> > My issue is just that it’s as much of a string as a call of a (string
> > returning) function/method or an expression concatenating strings:
> >
> > ''.join(things)   # would you call this a string?
> > '{!r}'.format(x)  # or this? it’s basically the same as this “f-string”:
> > f'{x!r}'
> > 'start' + 'end'   # or this? it’s a concatenation of two strings, just like
> > f'start{ "end" }'
> 
> Yes, an f-string is really a form of expression, not a literal. But
> prior art has generally been to have similar constructs referred to as
> "interpolated strings" or similar terms:
> 
> https://en.wikipedia.org/wiki/String_interpolation

*shrug* A misleading name is misleading no matter how many people use 
it. If  started calling 
function calls:

func(arg, x, y, z+1)

"s-strings" for "source code strings", because you write them as source 
code, and changed the syntax to 

func"arg, x, y, z+1"

we'd all recognise what a mistake it is to call this a string, string 
delimiters or not. The *result* of calling it may be a string, but the 
expression itself is a kind of function call.

[nasty thought]

Why don't we allow func"*args" as syntactic sugar for str(func(*args))?

[/remove tongue from cheek]


> Plenty of languages have some such feature, and it's usually
> considered a type of string. 

The result is a type of string. The expression is not.


> Notice the close parallels between actual
> string literals used as format strings ("I have %d apples" % apples)
> and f-strings (f"I have {apples} apples"), 

That's a misleading comparison. The *template string* is "I have %d 
apples" and that is just a string. The *format operator* is % and the 
formatting operation or expression is the entire expression.

Since f-strings can contain arbitrary expressions, the analogy is not 
with the template string, but a function (method or operator) call:

f"I have {fruit - bananas - oranges} apples"

is not equivalent to "I have {} apples", but to 

"I have {} apples".format(fruit - bananas - oranges) 

which is clearly a method call that merely returns a string, not a 
string itself.

Consequently, there's no way to delay evaluation of such an f-string, 
any more than you can delay evaluation of the expression[1]:

func(fruit, 2*bananas, 3/oranges)

You can't generate a template, and pass it to different environments to 
be formatted. If you need to evaluate f"I have {apples} apples" in six 
different contexts, you have to repeat yourself: it is equivalent to a 
function call, complete with implicit arguments, not a function object, 
and certainly not equivalent to a template string.


> and how this same parallel
> can be seen in many other languages. Yes, it may be a join expression
> to the compiler, but it's a string to the programmer.

Only if the programmer is fooled by the mere use of string delimiters. 
It really isn't a string. It is executable code that returns a string. 
It is basically a distant cousin to eval(), in disguise.

I really wish we had a better name for these things than f-strings :-(





[1] Tricks with eval() excluded.

-- 
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

[Guido van Rossum]

Philipp, you need to stop debating this issue *now*.

You need to write a PEP that can go into Python 3.7. Further debate at
the current level (a hair-width close to name-calling) is not going to
sway anyone.

(This actually goes for Chris too -- nothing is obviously going to
change Philipp's mind, so you might as well stop debating and save all
the onlookers the embarrassment.)

-- 
--Guido van Rossum (python.org/~guido)
___
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

[Philipp A.]

Hi Guido, thanks for calling me out.

Yikes, I'm terribly sorry that it came over that way!

I'll write the RFC. Should I expand the existing one (this would need
Chris’ pending changes though) or write a new one?

My goals were to sound factual and terse, not to insult anyone. And I don't
see the flaws in my phrasing, so it seems I'm still sometimes bad at
written communication.

@everyone who perceived it as Guido did: It would be really nice if you
could pinpoint the phrases and reasons that make it seem that I mean it
that way. (In a private mail to me)

Best, Philipp

Guido van Rossum  schrieb am Di., 30. Aug. 2016, 18:43:

> Philipp, you need to stop debating this issue *now*.
>
> You need to write a PEP that can go into Python 3.7. Further debate at
> the current level (a hair-width close to name-calling) is not going to
> sway anyone.
>
> (This actually goes for Chris too -- nothing is obviously going to
> change Philipp's mind, so you might as well stop debating and save all
> the onlookers the embarrassment.)
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
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

[Guido van Rossum]

You need to write a new PEP. And it's PEP, not RFC.

On Tue, Aug 30, 2016 at 9:56 AM, Philipp A.  wrote:
> Hi Guido, thanks for calling me out.
>
> Yikes, I'm terribly sorry that it came over that way!
>
> I'll write the RFC. Should I expand the existing one (this would need Chris’
> pending changes though) or write a new one?
>
> My goals were to sound factual and terse, not to insult anyone. And I don't
> see the flaws in my phrasing, so it seems I'm still sometimes bad at written
> communication.
>
> @everyone who perceived it as Guido did: It would be really nice if you
> could pinpoint the phrases and reasons that make it seem that I mean it that
> way. (In a private mail to me)
>
> Best, Philipp
>
>
> Guido van Rossum  schrieb am Di., 30. Aug. 2016, 18:43:
>>
>> Philipp, you need to stop debating this issue *now*.
>>
>> You need to write a PEP that can go into Python 3.7. Further debate at
>> the current level (a hair-width close to name-calling) is not going to
>> sway anyone.
>>
>> (This actually goes for Chris too -- nothing is obviously going to
>> change Philipp's mind, so you might as well stop debating and save all
>> the onlookers the embarrassment.)
>>
>> --
>> --Guido van Rossum (python.org/~guido)



-- 
--Guido van Rossum (python.org/~guido)
___
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

[Steven D'Aprano]

On Tue, Aug 30, 2016 at 11:02:25AM +, Philipp A. wrote:
> Hi Eric,
> 
> Very cool of you to get this going!
> 
> I hope the outcome is to ban escapes within braced code parts of f-literals
> for 3.6 and add them “the right way” in 3.7: f'foo{ bar['\n'] }baz'

That looks like you are doing a key lookup on bar:

bar = {'\n': 'something'}
f'foo{ bar['\n'] }baz'

looks like it will return 'foosomethingbaz'. I expect that syntax will 
confuse an awful lot of people.


-- 
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

[Guido van Rossum]

On Tue, Aug 30, 2016 at 10:30 AM, Steven D'Aprano  wrote:
[...]
> That looks like you are doing a key lookup on bar:
>
> bar = {'\n': 'something'}
> f'foo{ bar['\n'] }baz'
>
> looks like it will return 'foosomethingbaz'. I expect that syntax will
> confuse an awful lot of people.

Can we please stop debating this? This observation has been made about
100 times by now.

-- 
--Guido van Rossum (python.org/~guido)
___
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]

Steve,
Actually I initially asked for the distances in parsecs and was expecting
that they would be presented in a convenient format. So, to frame it in terms of
your analogy, I ordered a short black and become upset when I am delivered 8oz
of coffee in a 55 gallon drum.

This seems to be one of those unstated assumptions that have caused confusion in
these discussions.  Sometimes you want fix the prefix, sometimes you don't.  For
example, the Bel (B) is a unit of measure for ratios, but we never use it
directly, we always use decibels (dB). Nobody uses mB or kB or even B, it is
always dB. But with other units we do use the scale factors and we do tend to
normalize the presentation. For example, nobody says the Usain Bolt won the
10mm dash, or the 0.1km dash. Similarly when people refer to the length of
the Olympic road race in Rio, they say 56km, not 56000m.

This is really only an issue with output. What I am suggesting is adding support
for the second case into stdlib. For example:

>>> print('Attenuation = {:.1f}dB at {:r}m.'.format(-13.7, 50e3))
Attenuation = -13.7dB at 50km.

-Ken


On Tue, Aug 30, 2016 at 11:41:10PM +1000, Steven 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 
> > spirit of SI scale factors, were you are generally expected to 'normalize' 
> > the 
> > scale factor (use the scale factor that results in the digits presented 
> > before 
> > the decimal point falling between 1 and 999). So I would expected
> > 
> > d_andromeda = 780 kpc
> > d_sun = 4.8504 upc
> 
> Let me see if I get this straight... you *explicitly* asked for the 
> distance to the sun in kpc (kiloparsecs), but you expected a result in 
> µpc (microparsecs)?
> 
> When you ask the waiter for a short black, do you get upset that 
> he doesn't bring you a latte with soy milk? *wink*
> 
> I can see that such a normalising function would be useful, but I don't 
> think it should be the default. (If I ask for millimetres, I want 
> millimetres, not gigametres.) I've written and used code like that for 
> bytes, it makes sense to apply it to other measurement units. But only 
> if the caller requests normalisation, never by default.
> 
> I don't think there is any such general expectation that values should 
> be normalised in that way, and certainly not that your conversion 
> program should automatically do it for you. For example, see this list 
> of long-lived radioactive isotopes:
> 
> http://w.astro.berkeley.edu/~dperley/areopagus/isotopetable.html
> 
> Values above 650,000,000,000 (650e9) years are shown in "scientific 
> format", not "engineering format", e.g. Selenium-82 is given 
> as 1.1 x 10^20 rather than 110 x 10^18.
> 
> Likewise:
> 
> http://www.nist.gov/pml/data/halflife-html.cfm
> 
> displays a range of units (minutes, hours, days) with the base value 
> ranging up to over ten thousand, e.g. Ti-44 is shown as 22154 ± 456 
> days. This is NIST, which makes it pretty official. I don't think 
> there's any general expectation that values should be shown in the range 
> 1 to 999. (Perhaps in certain specialist areas.)
> 
> 
> 
> -- 
> 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/
___
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

[Guido van Rossum]

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, most people would do a double-take.

> This is really only an issue with output.

So maybe the proposal should be toned down to just a way to request SI
units when formatting numbers?

-- 
--Guido van Rossum (python.org/~guido)
___
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]

Guido,
I am in the process of summarizing the discussion as a way of wrapping this
up. As part of that I will be making a proposal that I think has a chance of
being accepted, and it will largely be what you suggest.

-Ken


On Tue, Aug 30, 2016 at 11:59:19AM -0700, Guido van Rossum wrote:
> 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, most people would do a double-take.
> 
> > This is really only an issue with output.
> 
> So maybe the proposal should be toned down to just a way to request SI
> units when formatting numbers?
> 
> -- 
> --Guido van Rossum (python.org/~guido)
___
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] Force UTF-8 option regardless locale

[M.-A. Lemburg]

On 30.08.2016 10:29, Victor Stinner wrote:
> Le 30 août 2016 02:05, "INADA Naoki"  a écrit :
>> How should the option be set?
> 
> I propose to add a new -X utf8 option. Maybe if the use case is important,
> we might add an PYTHONUTF8 environment variable.
> 
> The problem is that I'm not sure that an env var is the right way to
> configure Python on such environment? But an env var shouldn't hurt and it
> is common to add a new env var with a new cmdline option.
> 
> I added PYTHONFAULTHANDLER=1/-X faulthandler for faulthandler and
> PYTHONTRACEMALLOC=N/-X tracemalloc=N for tracemalloc.

In PyRun we simply define a default for PYTHONIOENCODING and
set this to utf-8:

http://www.egenix.com/products/python/PyRun/doc/#_Toc452660008

The encoding guessing is still available by setting the env
var to "" (but this is hardly used).

So far this has been working great.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Aug 30 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
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] real numbers with SI scale factors: next steps

[Ken Kundert]

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 would be 
   accepted:

  freq = 2.4GHz
  r = 1k
  l = 10nm

   The idea in accepting units was to allow them to be specified when 
convenient 
   as additional documentation on the meaning of the number.

   Objections:
   a. Acceptance of the abbreviation for Exa (E) overlaps with E-notation (1E+1 
  could represent 1e18 + 1 or 10). A suggestion to change the prefix from 
  E to X conflicts with a proposal to use X, W, and V to represent 10^27, 
  10^30, and 10^33 (en.wikipedia.org/wiki/Metric_prefix)
   b. Allowing the units to be specified will lead some users to assume 
  a dimensional analysis is being performed when in fact the units are 
  ignored. This false sense of security could lead to bugs.
   c. The proposal only supports simple units, not compound units such as m/s.  
  So even if hooks were provided to allow access to the units to support an 
  add-on dimensional analysis capability, an additional mechanism would 
have 
  to be provided to support compound units.
   d. Many people objected to allowing the use of naked scale factors as 
  a perversion of the standard.

2. A change to the float() function so that it accepts SI scale factors and 
   units. This extension naturally follows from the first: the float function 
   should accept anything the Python parser accepts.  For example:

  freq = float('2.4GHz')
  r = float('1k')
  l = float('10nm')

   Objections:
   a. The Exa objection from the above proposal is problematic here as well.
   b. Things that used to be errors are now no longer errors. This could cause 
  problems if a program was counting on float('1k') to be an error.


3. A change to the various string formatting mechanisms to allow outputting 
real 
   numbers with SI scale factors:

  >>> print('Speed of light in a vacuum: {:r}m/s.'.format(2.9979e+08))
  Speed of light in a vacuum: 299.79 Mm/s.

  >>> print('Speed of sound in water: %rm/s.' % 1481
  Speed of sound in water: 1.481 km/s.

   Objections:
   No objections were raised that I recall, however here is something else to 
   consider:

   a. Should we also provide mechanism for the binary scale factors (Ki, Mi, 
  ..., Yi)? For example: '{:b}B'.format(2**30) --> 1 GiB.

On proposed extension 1 (native support for SI literals) my conclusion is that 
we did not reach any sense of consensus and there was considerable opposition 
to 
my proposal.  There was much less discussion on extensions 2 & 3, so it is hard 
to say whether consensus was reached.

So, given all this, I would like to make the following recommendations:
1. No action should be taken.
2. The main justification to modifying float() was to make it consistent with 
   the extended Python language. Without extension 1, this justification goes 
   away. However the need to be able to easily convert strings of numbers with 
   SI scale factors into floats still exists. This should be handled by adding 
   a library or extending an existing library.
3. Allowing numbers to be formatted with SI prefixes is useful and not 
   controversial. The 'r' and 'b' format codes should be added to the various 
   string formatting mechanisms.

What do you think?

-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: next steps

[Paul Moore]

On 30 August 2016 at 21:34, Ken Kundert  wrote:
> So, given all this, I would like to make the following recommendations:
> 1. No action should be taken.
> 2. The main justification to modifying float() was to make it consistent with
>the extended Python language. Without extension 1, this justification goes
>away. However the need to be able to easily convert strings of numbers with
>SI scale factors into floats still exists. This should be handled by adding
>a library or extending an existing library.
> 3. Allowing numbers to be formatted with SI prefixes is useful and not
>controversial. The 'r' and 'b' format codes should be added to the various
>string formatting mechanisms.
>
> What do you think?

Thanks for the summary (which I mostly elided) which I think was fair.

Regarding (3), the only one that remains proposed, I think it would be
useful to see a 3rd-party library implementation of the formatting
operation proposed. This would allow any corner cases or controversial
points to be ironed out before proposing it for direct incorporation
in the string formatting mini-language. Furthermore, in Python 2.6, it
will be possible to write

f"The value is {si_format(the_val)}"

directly, using PEP 498 f-strings. The combination of a 3rd party
function and f-strings may even make special formatting support
unnecessary - but that will be easier to establish with practical
experience. And there's little or no downside - the proposed feature
won't be possible before 3.7, so we may as well use lifetime of the
3.6 release to gain that experience.

Paul
___
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: next steps

[Guido van Rossum]

Given that something like this gets proposed from time to time, I
wonder if it would make sense to actually write up (1) and (2) as a
PEP that is immediately marked rejected. The PEP should make it clear
*why* it is rejected. This would be a handy reference doc to have
around the next time the idea comes up.

-- 
--Guido van Rossum (python.org/~guido)
___
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: next steps

[Sven R. Kunze]

Thanks a lot for this comprehensive summary. :) Find my comments below.


On 30.08.2016 22:34, Ken Kundert wrote:

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 would be
accepted:

   freq = 2.4GHz
   r = 1k
   l = 10nm

The idea in accepting units was to allow them to be specified when 
convenient
as additional documentation on the meaning of the number.

Objections:
a. Acceptance of the abbreviation for Exa (E) overlaps with E-notation (1E+1
   could represent 1e18 + 1 or 10). A suggestion to change the prefix from
   E to X conflicts with a proposal to use X, W, and V to represent 10^27,
   10^30, and 10^33 (en.wikipedia.org/wiki/Metric_prefix)


I think this results from the possibility of omitting the SI units.


b. Allowing the units to be specified will lead some users to assume
   a dimensional analysis is being performed when in fact the units are
   ignored. This false sense of security could lead to bugs.


Same can be said for variable annotations for which a PEP is in the works.


c. The proposal only supports simple units, not compound units such as m/s.
   So even if hooks were provided to allow access to the units to support an
   add-on dimensional analysis capability, an additional mechanism would 
have
   to be provided to support compound units.


I get the feeling that SI syntax should only work when the hook is provided.

So this could be the dealbreaker here: only enabling it when the hook is 
provided, changes the syntax/semantics of valid Python code depending on 
the presence of some hidden hooks. Enabling the syntax regardless of a 
working hook, have those sideeffects like described by you above.


So, no matter how done, it always has some negative connotation.


d. Many people objected to allowing the use of naked scale factors as
   a perversion of the standard.


Remove this and it also solves 1.a.



2. A change to the float() function so that it accepts SI scale factors and
units. This extension naturally follows from the first: the float function
should accept anything the Python parser accepts.  For example:

   freq = float('2.4GHz')
   r = float('1k')
   l = float('10nm')

Objections:
a. The Exa objection from the above proposal is problematic here as well.
b. Things that used to be errors are now no longer errors. This could cause
   problems if a program was counting on float('1k') to be an error.


3. A change to the various string formatting mechanisms to allow outputting real
numbers with SI scale factors:

   >>> print('Speed of light in a vacuum: {:r}m/s.'.format(2.9979e+08))
   Speed of light in a vacuum: 299.79 Mm/s.

   >>> print('Speed of sound in water: %rm/s.' % 1481
   Speed of sound in water: 1.481 km/s.

Objections:
No objections were raised that I recall, however here is something else to
consider:

a. Should we also provide mechanism for the binary scale factors (Ki, Mi,
   ..., Yi)? For example: '{:b}B'.format(2**30) --> 1 GiB.

On proposed extension 1 (native support for SI literals) my conclusion is that
we did not reach any sense of consensus and there was considerable opposition to
my proposal.  There was much less discussion on extensions 2 & 3, so it is hard
to say whether consensus was reached.

So, given all this, I would like to make the following recommendations:
1. No action should be taken.
2. The main justification to modifying float() was to make it consistent with
the extended Python language. Without extension 1, this justification goes
away. However the need to be able to easily convert strings of numbers with
SI scale factors into floats still exists. This should be handled by adding
a library or extending an existing library.
3. Allowing numbers to be formatted with SI prefixes is useful and not
controversial. The 'r' and 'b' format codes should be added to the various
string formatting mechanisms.

What do you think?


I like your conclusion. It seems there is missing some technical note of 
why this won't happen the way you proposed it (maybe the hook + missing 
stdlib package for SI units). :)


Aren't there some package already available for recommendation 3?


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: next steps

[Barry Warsaw]

On Aug 30, 2016, at 02:16 PM, Guido van Rossum wrote:

>Given that something like this gets proposed from time to time, I
>wonder if it would make sense to actually write up (1) and (2) as a
>PEP that is immediately marked rejected. The PEP should make it clear
>*why* it is rejected. This would be a handy reference doc to have
>around the next time the idea comes up.

There certainly is precedence: e.g. PEPs 404 and 666. :)

Cheers,
-Barry


pgpLLpPQDzqcA.pgp
Description: OpenPGP digital signature
___
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] Force UTF-8 option regardless locale

[INADA Naoki]

On Wed, Aug 31, 2016 at 4:45 AM, M.-A. Lemburg  wrote:
> On 30.08.2016 10:29, Victor Stinner wrote:
>> Le 30 août 2016 02:05, "INADA Naoki"  a écrit :
>>> How should the option be set?
>>
>> I propose to add a new -X utf8 option. Maybe if the use case is important,
>> we might add an PYTHONUTF8 environment variable.
>>
>> The problem is that I'm not sure that an env var is the right way to
>> configure Python on such environment? But an env var shouldn't hurt and it
>> is common to add a new env var with a new cmdline option.
>>
>> I added PYTHONFAULTHANDLER=1/-X faulthandler for faulthandler and
>> PYTHONTRACEMALLOC=N/-X tracemalloc=N for tracemalloc.
>
> In PyRun we simply define a default for PYTHONIOENCODING and
> set this to utf-8:
>
> http://www.egenix.com/products/python/PyRun/doc/#_Toc452660008
>
> The encoding guessing is still available by setting the env
> var to "" (but this is hardly used).
>
> So far this has been working great.

My concern is, people other than me running Python scripts on such systems
(which has only C locale).
Most unix commands runs well in C locale.  But only Python script get many
trouble.

* locale error when just running Python script. (when bad LANG setting).

* Unicode error happen when stdout is piped, while runs well when
  without pipe (when LANG=C, and no PYTHONIOENCODING set).

* open() without explicit `encoding='utf-8'` runs well on Mac and LANG=*.utf8
  environment.  But UnicodeError happen on LANG=C environment.

(Actually speaking, I and my company doesn't use UTF-8 filename.
So we don't get trouble about fsencoding.  But some other companies may.)


On such system, site-wide configuration to override `nl_langinfo(CODESET)`
may help people. Otherwise:

1 Face locale error when running Python script, and write LANG=C to
their .bashrc.

2 Face UnicodeError when piping from Python script, and write
   PYTHONIOENCODING=utf-8 in their .bashrc.

3 Face UnicodeError when reading/writing from text file, and add
explicit `encoding='utf-8'`
   (This bug may be not found on CI environment having *.UTF-8 locale,
and happens
in production environment)

4 Finally, people feel Python is troublesome language, and they don't
want to use Python
  anymore.

I know about `/etc/environment` file.  But OPs doesn't like adding
lines to it only for Python.
They feel "Perl (or Ruby) is better than Python".


This is why I think configuration option or site-wide configuration is
desirable even if
we have PYTHON(IO|FS|PREFERRED)ENCODINGS environment variables.


>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Aug 30 2016)
 Python Projects, Coaching and Consulting ...  http://www.egenix.com/
 Python Database Interfaces ...   http://products.egenix.com/
 Plone/Zope Database Interfaces ...   http://zope.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>http://www.egenix.com/company/contact/
>   http://www.malemburg.com/
>



-- 
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: next steps

[Steven D'Aprano]

On Tue, Aug 30, 2016 at 01:34:27PM -0700, Ken Kundert wrote:

> 3. A change to the various string formatting mechanisms to allow outputting 
> real 
>numbers with SI scale factors:

This is somewhat similar to a library I wrote for formatting bytes:

https://pypi.python.org/pypi/byteformat

Given that feature freeze for 3.6 is two weeks way, I don't think that 
this proposal will appear before 3.7. So I'm interested, but I'm less 
interested *right now*. So for now I'll limit myself to only a few 
observations.

 
>   >>> print('Speed of light in a vacuum: {:r}m/s.'.format(2.9979e+08))
>   Speed of light in a vacuum: 299.79 Mm/s.

Do you think that {:r} might be confused with {!r}?

What's the mnemonic here? Why "r" for scale factor?

 
>   >>> print('Speed of sound in water: %rm/s.' % 1481
>   Speed of sound in water: 1.481 km/s.

I doubt that you'll get any new % string formatting codes. That's a 
legacy interface, *not* deprecated but unlikely to get new features 
added, and it is intended to closely match the C printf codes.


A few more questions:

(1) Why no support for choosing a particular scale? If this only 
auto-scales, I'm not interested.

(2) Support for full prefix names, so we can format (say) "kilograms" as 
well as "kg"?

(3) Scientific notation and engineering notation?

(4) 1e5 versus 1×10^5 notation?

(5) Is this really something that format() needs to understand? We can 
get a *much* richer and more powerful interface by turning it into a 
generalise numeric pretty-printing library, at the cost of a little less 
convenience.


> 3. Allowing numbers to be formatted with SI prefixes is useful and not 
>controversial.

I wouldn't quite go that far. You made an extremely controversial 
request (new syntax for scaling prefixes + ignored units) and nearly all 
the attention was on that.

For what its worth, I have no need for a format code which *only* 
auto-selects the scaling factor. If I don't have at least the option to 
choose which scaling factor I get, and hence the prefix, this is of 
little or no use to me, I likely wouldn't use it, and as far as I am 
concerned the nuisance value of having yet another format string code to 
learn outweighs the benefit.



-- 
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] real numbers with SI scale factors: next steps

[Chris Angelico]

On Wed, Aug 31, 2016 at 12:05 PM, Steven D'Aprano  wrote:
> (5) Is this really something that format() needs to understand? We can
> get a *much* richer and more powerful interface by turning it into a
> generalise numeric pretty-printing library, at the cost of a little less
> convenience.

Or just have a subclass of int or float that defines __format__, and
can do whatever it likes - including specifying the scale, if you so
choose. Say, something like:

{:s} -- autoscale, prefix
{:S} -- autoscale, full word
{:sM} -- scale to mega, print "M"
{:SM} -- scale to mega, print "Mega"
etc

ChrisA
___
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: next steps

[Ken Kundert]

> 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 the point. There is really little need for a special 
mechanism if your going to specify the scale factor yourself.

>>> print('Attenuation = {:.1f} dB at {:r}m.'.format(-13.7, 50e3))
Attenuation = -13.7 dB at 50 km.

If you wanted to force the second number to be in km, you use a %f format and 
scale the argument:

>>> print('Attenuation = {:.1f} dB at {:.1f} km.'.format(-13.7, 50e3/1e3))
Attenuation = -13.7 dB at 50 km.

> (2) Support for full prefix names, so we can format (say) "kilograms" as well 
> as "kg"?

This assumes that somehow this code can access the units so that it can switch 
between long form 'grams' and short form 'g'. That is a huge expansion in the 
complexity for what seems like a small benefit.

> (3) Scientific notation and engineering notation?
> 
> (4) 1e5 versus 1×10^5 notation?

Ah, okay. But all of these require auto-scaling. And I was still thinking that 
we need to provide input and output capability (ie, we still need be able to 
convert whatever format we output back from strings into floats). Are you 
thinking that we should parse 1×10^5? And why 1×10^5 and not 1×10⁵?

> (5) Is this really something that format() needs to understand? We can get 
> a *much* richer and more powerful interface by turning it into a generalise 
> numeric pretty-printing library, at the cost of a little less convenience.

This is suddenly a much bigger project than what I was envisioning.

-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/