[Python-Dev] PEP needed for http://bugs.python.org/issue9232 ?

So, there's a patch on issue 9232 - allow trailing commas in function definitions - but there's been enough debate that I suspect we need a PEP. Would love it if someone could correct me, but I'd like to be able to either categorically say 'no' and close the ticket, or 'yes and this is what needs

Re: [Python-Dev] PEP-498: Literal String Formatting

ISAAC J SCHWABACHER schrieb am 11.08.2015 um 01:05: > I don't know about you, but I sure like this better than what you have: > > code.putlines(f""" > static char {entry.doc_cname}[] = "{ > split_string_literal(escape_bytestring(docstr))}"; > > { # nested! > f""" > #if CYTHON_COMPILING_IN_CPY

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

Cameron Simpson wrote: To illustrate, there's a consumer rights TV snow here with a segment called "F.U. Tube", where members of the public describe ripoffs and other product failures in video form. While a phonetic play on the name "YouTube", the abbreviation also colloquially means just what

Re: [Python-Dev] PEP-498: Literal String Formatting

I don't know about you, but I sure like this better than what you have: code.putlines(f""" static char {entry.doc_cname}[] = "{ split_string_literal(escape_bytestring(docstr))}"; { # nested! f""" #if CYTHON_COMPILING_IN_CPYTHON struct wrapperbase {entry.wrapperbase_cname}; #endif """ if e

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 10, 2015 at 2:04 PM, Carl Meyer wrote: > On 08/10/2015 02:49 PM, Eric V. Smith wrote: > > On 08/10/2015 02:44 PM, Yury Selivanov wrote: > >> > >> > >> On 2015-08-10 2:37 PM, Eric V. Smith wrote: > Besides, any expression you have to calculate can go in a local that > will ge

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 10, 2015 at 1:52 PM, David Mertz wrote: > I know. I elided including the nonexistent `nonlocals()` in there. But it > *should* be `lngb()`. Or call it scope(). :-) > On Aug 10, 2015 10:09 AM, "Steven D'Aprano" wrote: > >> On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote:

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 10, 2015 at 09:23:15PM +0200, Guido van Rossum wrote: [...] > Anyway, this generalization from print() is why I want arbitrary > expressions. Wouldn't it be silly if we introduced print() today and said > "we don't really like to encourage printing complicated expressions, but > maybe

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 10, 2015 4:52 PM, "Nathaniel Smith" wrote: > > On Aug 10, 2015 11:33 AM, "Barry Warsaw" wrote: > > > > On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote: > > > > >I think I would be happy with f-strings, or perhaps i-strings if we use > > >Nick's ideas about internationalisation, and lim

Re: [Python-Dev] Sorry folks, minor hiccup for Python 3.5.0rc1

On 08/10/2015 05:55 PM, Larry Hastings wrote: I yanked the tarballs off the release page as soon as I suspected something. I'm rebuilding the tarballs and the docs now. If you grabbed the tarball as soon as it appeared, it's slightly out of date, please re-grab. p.s. I should have mentioned

[Python-Dev] Sorry folks, minor hiccup for Python 3.5.0rc1

I built the source tarballs with a slightly-out-of-date tree. We slipped the release by a day to get two fixes in, but the tree I built from didn't have those two fixes. I yanked the tarballs off the release page as soon as I suspected something. I'm rebuilding the tarballs and the docs n

Re: [Python-Dev] Instructions on the new "push request" workflow for 3.5.0rc1+ through 3.5.0 final

On 08/10/2015 01:27 AM, Larry Hastings wrote: As of Python 3.5.0rc1, the canonical repository for Python 3.5.0 is *no longer* on hg.python.org. Instead, it's hosted on Bitbucket on my personal account, here: https://bitbucket.org/larry/cpython350 Since 3.5.0rc1 isn't out yet I'm keeping

[Python-Dev] [RELEASED] Python 3.5.0rc1 is now available

On behalf of the Python development community and the Python 3.5 release team, I'm relieved to announce the availability of Python 3.5.0rc1, also known as Python 3.5.0 Release Candidate 1. Python 3.5 has now entered "feature freeze". By default new features may no longer be added to Python

Re: [Python-Dev] Instructions on the new "push request" workflow for 3.5.0rc1+ through 3.5.0 final

A quick hg tip for making sure you check out the right branch: end the URL on #3.5 and it will start the repo out with the 3.5 as the active branch. On Mon, Aug 10, 2015, 01:28 Larry Hastings wrote: > > As of Python 3.5.0rc1, the canonical repository for Python 3.5.0 is > *no longer* on hg.pytho

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 8:04 PM, Victor Stinner wrote: > > > Le mardi 11 août 2015, MRAB > a écrit : > > I'm a little bit surprised at seeing this: (...) > > > We may modify str.format to ignore leading spaces, but IMHO it should > not be motivated by the PEP. Agr

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 8:00 PM, MRAB wrote: > On 2015-08-11 00:26, Victor Stinner wrote: >> Le mardi 11 août 2015, Eric V. Smith > > a écrit : >> >> It sounds like you want to disallow leading spaces just to >> disallow this one type of expression. >> >> >> I would like t

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

Le mardi 11 août 2015, MRAB a écrit : > > I'm a little bit surprised at seeing this: (...) > We may modify str.format to ignore leading spaces, but IMHO it should not be motivated by the PEP. Victor ___ Python-Dev mailing list Python-Dev@python.org htt

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On 2015-08-11 00:26, Victor Stinner wrote: Le mardi 11 août 2015, Eric V. Smith mailto:e...@trueblade.com>> a écrit : It sounds like you want to disallow leading spaces just to disallow this one type of expression. I would like to reduce the number of subtle differences between f-str

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On 11Aug2015 01:00, Victor Stinner wrote: By the way, I don't think that fu'...' syntax should be allowed. IMHO u'...' was only reintroduced to Python 3.3 to ease transition from Python 2 to Python 3 of the existing u'...' Syntax. Since f'...' is a new syntax, backward compatibility doesn't matt

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 7:26 PM, Victor Stinner wrote: > Le mardi 11 août 2015, Eric V. Smith > a écrit : > > It sounds like you want to disallow leading spaces just to > disallow this one type of expression. > > > I would like to reduce the number of subtle differences

Re: [Python-Dev] PEP 498 f-string: is it a preprocessor?

On 8/10/2015 7:23 PM, Victor Stinner wrote: > But in any event, I don't see the distinction between calling > str.format(), and calling each object's __format__ method. Both are > compliant with the PEP, which doesn't specify exactly how the > transformation is done. > > > When I

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

Le mardi 11 août 2015, Eric V. Smith a écrit : > It sounds like you want to disallow leading spaces just to > disallow this one type of expression. > I would like to reduce the number of subtle differences between f-string and str.format(). Victor __

Re: [Python-Dev] PEP 498 f-string: is it a preprocessor?

Le mardi 11 août 2015, Eric V. Smith a écrit : > > Oops, I was thinking of going the other way (str.format -> f''). Yes, I > think you're correct. Ah ok. But in any event, I don't see the distinction between calling > str.format(), and calling each object's __format__ method. Both are > complia

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On 2015-08-10 23:54, Victor Stinner wrote: PEP 498: """ Leading whitespace in expressions is skipped Because expressions may begin with a left brace ('{'), there is a problem when parsing such expressions. For example: f'{{k:v fo

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 6:54 PM, Victor Stinner wrote: > > PEP 498: > > """ > > > Leading whitespace in expressions is skipped > > > Because expressions may begin with a left brace ('{'), there is a > problem when parsing such expressions. For

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

By the way, I don't think that fu'...' syntax should be allowed. IMHO u'...' was only reintroduced to Python 3.3 to ease transition from Python 2 to Python 3 of the existing u'...' Syntax. Since f'...' is a new syntax, backward compatibility doesn't matter here. Victor

Re: [Python-Dev] PEP 498 f-string: is it a preprocessor?

On 8/10/2015 6:22 PM, Victor Stinner wrote: > Le lundi 10 août 2015, Eric V. Smith > a écrit : > > On 08/10/2015 10:18 AM, Victor Stinner wrote: > > Hi, > > > > I read the PEP but I don't understand how it is implemented. For > me, it > > should

[Python-Dev] PEP 498 f-string: please remove the special case for spaces

PEP 498: """ Leading whitespace in expressions is skipped Because expressions may begin with a left brace ('{'), there is a problem when parsing such expressions. For example: >>> f'{{k:v for k, v in [(1, 2), (3, 4)]}}' '{k:v for k, v in [(1, 2), (

Re: [Python-Dev] PEP 498 f-string: is it a preprocessor?

Le lundi 10 août 2015, Eric V. Smith a écrit : > On 08/10/2015 10:18 AM, Victor Stinner wrote: > > Hi, > > > > I read the PEP but I don't understand how it is implemented. For me, it > > should be a simple preprocessor: > > > > - f'x={x}' is replaced with 'x={0}'.format(x) by the compiler > > - f

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 10, 2015 11:33 AM, "Barry Warsaw" wrote: > > On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote: > > >I think I would be happy with f-strings, or perhaps i-strings if we use > >Nick's ideas about internationalisation, and limit what they can evaluate to > >name lookups, attribute lookups,

Re: [Python-Dev] PEP-498: Literal String Formatting

Here are my notes on PEP 498. 1. Title: Literal String Formatting - String Literal Formatting - Format String Expressions ? 2. Let's call them "format strings" not "f-strings". The latter sounds slightly obnoxious, and also inconsistent with the others: r'' r

Re: [Python-Dev] PEP-498: Literal String Formatting

On 2015-08-10 20:23, Guido van Rossum wrote: On Mon, Aug 10, 2015 at 8:49 PM, Eric V. Smith mailto:e...@trueblade.com>> wrote: On 08/10/2015 02:44 PM, Yury Selivanov wrote: > On 2015-08-10 2:37 PM, Eric V. Smith wrote: >> This is why I think PEP-498 isn't the solution for i18n. I'd r

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 10, 2015, at 02:49 PM, Eric V. Smith wrote: >It's possible. But my point is that Barry doesn't even want >attribute/item getters for an i18n solution, and I'm not willing to >restrict it that much. Actually, attribute chasing is generally fine, and flufl.i18n supports that. Translators can

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 02:49 PM, Eric V. Smith wrote: > On 08/10/2015 02:44 PM, Yury Selivanov wrote: >> >> >> On 2015-08-10 2:37 PM, Eric V. Smith wrote: Besides, any expression you have to calculate can go in a local that will get > interpolated. The same goes for any !r or other formatting

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 10, 2015 at 8:49 PM, Eric V. Smith wrote: > On 08/10/2015 02:44 PM, Yury Selivanov wrote: > > On 2015-08-10 2:37 PM, Eric V. Smith wrote: > >> This is why I think PEP-498 isn't the solution for i18n. I'd really like > >> to be able to say, in a debugging context: > >> > >> print('a:{s

Re: [Python-Dev] Branch Prediction And The Performance Of Interpreters - Don't Trust Folklore

On Mon, Aug 10, 2015 at 4:44 PM, Larry Hastings wrote: > > > This just went by this morning on reddit's /r/programming. It's a paper > that analyzed Python--among a handful of other languages--to answer the > question "are branch predictors still that bad at the big switch statement > approach to

Re: [Python-Dev] PEP-498: Literal String Formatting

I know. I elided including the nonexistent `nonlocals()` in there. But it *should* be `lngb()`. Or call it scope(). :-) On Aug 10, 2015 10:09 AM, "Steven D'Aprano" wrote: > On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote: > > [...] > > That said, there *is* one small corner where I b

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 02:44 PM, Yury Selivanov wrote: > > > On 2015-08-10 2:37 PM, Eric V. Smith wrote: >>> Besides, any expression you have to calculate can go in a local that >>> will get >>> >interpolated. The same goes for any !r or other formatting >>> modifiers. In an >>> >i18n context, you want

Re: [Python-Dev] PEP-498: Literal String Formatting

On 2015-08-10 2:37 PM, Eric V. Smith wrote: Besides, any expression you have to calculate can go in a local that will get >interpolated. The same goes for any !r or other formatting modifiers. In an >i18n context, you want to stick to the simplest possible substitution >placeholders. This is

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 02:31 PM, Barry Warsaw wrote: > On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote: > >> I think I would be happy with f-strings, or perhaps i-strings if we use >> Nick's ideas about internationalisation, and limit what they can evaluate to >> name lookups, attribute lookups, and in

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote: >I think I would be happy with f-strings, or perhaps i-strings if we use >Nick's ideas about internationalisation, and limit what they can evaluate to >name lookups, attribute lookups, and indexing, just like format(). I still think you really

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 01:26 PM, Steven D'Aprano wrote: > On Sun, Aug 09, 2015 at 06:54:38PM -0700, David Mertz wrote: > >> Which brought to mind a certain thought. While I don't like: >> >> f'My name is {name}, my age next year is {age+1}' >> >> I wouldn't have any similar objection to: >> >>'My

Re: [Python-Dev] PEP-498: Literal String Formatting

On Sun, Aug 09, 2015 at 06:54:38PM -0700, David Mertz wrote: > Which brought to mind a certain thought. While I don't like: > > f'My name is {name}, my age next year is {age+1}' > > I wouldn't have any similar objection to: > >'My name is {name}, my age next year is {age+1}'.scope_form

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 01:07 PM, Steven D'Aprano wrote: > On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote: > > [...] >> That said, there *is* one small corner where I believe f-strings add >> something helpful to the language. There is no really concise way to spell: >> >> collections.ChainM

Re: [Python-Dev] PEP-498: Literal String Formatting

On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote: [...] > That said, there *is* one small corner where I believe f-strings add > something helpful to the language. There is no really concise way to spell: > > collections.ChainMap(locals(), globals(), __builtins__.__dict__). I think

Re: [Python-Dev] PEP-498: Literal String Formatting

Eric, On 2015-08-07 9:39 PM, Eric V. Smith wrote: [..] 'f-strings are very awesome!' I'm open to any suggestions to improve the PEP. Thanks for your feedback. Congrats for the PEP, it's a cool concept! Overall I'm +1, because a lot of my own formatting code looks like this: 'something .

[Python-Dev] Branch Prediction And The Performance Of Interpreters - Don't Trust Folklore

This just went by this morning on reddit's /r/programming. It's a paper that analyzed Python--among a handful of other languages--to answer the question "are branch predictors still that bad at the big switch statement approach to interpreters?" Their conclusion: no. Our simulations [.

Re: [Python-Dev] PEP 498 f-string: is it a preprocessor?

On 08/10/2015 10:18 AM, Victor Stinner wrote: > Hi, > > I read the PEP but I don't understand how it is implemented. For me, it > should be a simple preprocessor: > > - f'x={x}' is replaced with 'x={0}'.format(x) by the compiler > - f'x={1+1}' is replaced with 'x={0}'.format(1+1) > - f'x={foo()!r

[Python-Dev] PEP 498 f-string: is it a preprocessor?

Hi, I read the PEP but I don't understand how it is implemented. For me, it should be a simple preprocessor: - f'x={x}' is replaced with 'x={0}'.format(x) by the compiler - f'x={1+1}' is replaced with 'x={0}'.format(1+1) - f'x={foo()!r}' is replaced with 'x={0!r}'.format(foo()) - ... That's all.

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 09, 2015, at 06:14 PM, David Mertz wrote: >That said, there *is* one small corner where I believe f-strings add >something helpful to the language. There is no really concise way to spell: > > collections.ChainMap(locals(), globals(), __builtins__.__dict__). > >If we could spell that as,

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/10/2015 01:29, Sven R. Kunze wrote: The best solution would be "without prefix and '{var}' only" syntax. Not sure if that is possible at all; I cannot remember using '{...}' anywhere else than for formatting. My JSON string literal 'test fixtures' weep at that idea. _

[Python-Dev] Instructions on the new "push request" workflow for 3.5.0rc1+ through 3.5.0 final

As of Python 3.5.0rc1, the canonical repository for Python 3.5.0 is *no longer* on hg.python.org. Instead, it's hosted on Bitbucket on my personal account, here: https://bitbucket.org/larry/cpython350 Since 3.5.0rc1 isn't out yet I'm keeping the repository private for now. Once 3.5.0 rc1 i

[Python-Dev] Python 3.5.0rc1 is delayed by a day

We retagged Python 3.5.0rc1 today to fix two bugs that popped up late in the process. Release candidates are supposed to be software you genuinely would release, and I couldn't release Python with both those bugs. This delay rippled through the whole process, so it just isn't going out ton