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}' is
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
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 name is {name},
On Mon, Aug 10, 2015 at 4:44 PM, Larry Hastings la...@hastings.org 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
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
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_format()
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
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 indexing,
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:
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
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 to stick to the
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 st...@pearwood.info wrote:
On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote:
[...]
That said, there *is* one small
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
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
modifiers. In an
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
On 2015-08-10 20:23, Guido van Rossum wrote:
On Mon, Aug 10, 2015 at 8:49 PM, Eric V. Smith e...@trueblade.com
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
On Aug 10, 2015 11:33 AM, Barry Warsaw ba...@python.org 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
Le lundi 10 août 2015, Eric V. Smith e...@trueblade.com 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
PEP 498:
Leading whitespace in expressions is skipped
https://www.python.org/dev/peps/pep-0498/#id28
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), (3,
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
On 2015-08-11 00:26, Victor Stinner wrote:
Le mardi 11 août 2015, Eric V. Smith e...@trueblade.com
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
On 2015-08-10 23:54, Victor Stinner wrote:
PEP 498:
Leading whitespace in expressions is skipped
https://www.python.org/dev/peps/pep-0498/#id28
Because expressions may begin with a left brace ('{'), there is a
problem when parsing such expressions. For example:
f'{{k:v for k,
Le mardi 11 août 2015, Eric V. Smith e...@trueblade.com 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
On 8/10/2015 7:26 PM, Victor Stinner wrote:
Le mardi 11 août 2015, Eric V. Smith e...@trueblade.com
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
On 8/10/2015 8:04 PM, Victor Stinner wrote:
Le mardi 11 août 2015, MRAB pyt...@mrabarnett.plus.com
mailto:pyt...@mrabarnett.plus.com 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
On 8/10/2015 6:22 PM, Victor Stinner wrote:
Le lundi 10 août 2015, Eric V. Smith e...@trueblade.com
mailto:e...@trueblade.com 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
On 8/10/2015 6:54 PM, Victor Stinner wrote:
PEP 498:
Leading whitespace in expressions is skipped
https://www.python.org/dev/peps/pep-0498/#id28
Because expressions may begin with a left brace ('{'), there is a
problem when parsing such expressions. For example:
Le mardi 11 août 2015, Eric V. Smith 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-string
and str.format().
Victor
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 read
On 11Aug2015 01:00, Victor Stinner victor.stin...@gmail.com 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
Le mardi 11 août 2015, MRAB pyt...@mrabarnett.plus.com 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
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 e...@trueblade.com
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
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'' raw
On Mon, Aug 10, 2015 at 2:04 PM, Carl Meyer c...@oddbird.net 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 get
On Mon, Aug 10, 2015 at 8:49 PM, Eric V. Smith 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 really like
to be able to say, in a debugging context:
On Aug 10, 2015 4:52 PM, Nathaniel Smith n...@pobox.com wrote:
On Aug 10, 2015 11:33 AM, Barry Warsaw ba...@python.org 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
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 we
On Mon, Aug 10, 2015 at 1:52 PM, David Mertz me...@gnosis.cx 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 st...@pearwood.info wrote:
On Sun, Aug 09, 2015 at 06:14:18PM
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
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
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 la...@hastings.org wrote:
As of Python 3.5.0rc1, the canonical repository for Python 3.5.0 is
*no
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
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
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
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
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.
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, say
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
48 matches
Mail list logo
