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

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

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

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

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

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

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

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 o

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

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

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

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 righ

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

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

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 int

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

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 /

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

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

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

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

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

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 s

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

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 num

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

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 co

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

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 n

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

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 y

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

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,

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

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

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

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 change

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

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

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

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 sto

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

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 o

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

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

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

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

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

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

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

Okay, let's try to wrap this up. In summary I proposed three things: 1. A change to the Python lexer to accept SI literal as an alternative, but not replacement to, E-notation. As an optional feature, simple units could be added to the end but would be largely ignored. So the following wou

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

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 just

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

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

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

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

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

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

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

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 env

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

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 Giv

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

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 jus

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

> 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