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 you think it might. I can just imagine reciting one of these new strings out loud... We could require it to be spelled uf unless from __future__ import billy_connolly_as_FLUFL is in effect. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces
On 11Aug2015 18:07, Greg Ewing greg.ew...@canterbury.ac.nz wrote: 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 you think it might. I can just imagine reciting one of these new strings out loud... We could require it to be spelled uf unless from __future__ import billy_connolly_as_FLUFL is in effect. That seems like a reasoned and measured response. Cheers, Cameron Simpson c...@zip.com.au For those who understand, NO explanation is needed, for those who don't understand, NO explanation will be given! - Davey D decos...@vnet.ibm.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces
On Tue, Aug 11, 2015 at 09:51:56PM +1000, Chris Angelico wrote: On Tue, Aug 11, 2015 at 5:08 PM, Cameron Simpson c...@zip.com.au wrote: On 11Aug2015 18:07, Greg Ewing greg.ew...@canterbury.ac.nz wrote: 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 you think it might. I can just imagine reciting one of these new strings out loud... We could require it to be spelled uf unless from __future__ import billy_connolly_as_FLUFL is in effect. That seems like a reasoned and measured response. Given the levels of profanity that are not disallowed in identifier names, I think blocking off a two-letter prefix is pretty pointless. It'd be different if the specification _required_ it (though even then, it's not that big a deal...), but merely permitting it? Not Python's fault. Er, if it's not Python's doing, whose doing is it? There's a difference between not censoring identifiers written by the user, and creating syntax. I don't think anyone would blame the language if I created an identifier poop, say, but if the language included a keyword poop or a syntax feature, say, poop-lists: poop[a, b, c, d] then one might wonder what the language designers were thinking. I've already seen a bit of sniggering on Reddit about fu strings. In the grand scheme of things, worrying about fu strings is pretty low on the list of priorities. But if there is no need to allow fu as a prefix, or if there is another equally good prefix to use instead of f, then there's no harm done by disappointing the 14 year olds. -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces
On Tue, Aug 11, 2015 at 5:08 PM, Cameron Simpson c...@zip.com.au wrote: On 11Aug2015 18:07, Greg Ewing greg.ew...@canterbury.ac.nz wrote: 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 you think it might. I can just imagine reciting one of these new strings out loud... We could require it to be spelled uf unless from __future__ import billy_connolly_as_FLUFL is in effect. That seems like a reasoned and measured response. Given the levels of profanity that are not disallowed in identifier names, I think blocking off a two-letter prefix is pretty pointless. It'd be different if the specification _required_ it (though even then, it's not that big a deal...), but merely permitting it? Not Python's fault. ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 differences between
f-string and str.format().
I'm a little bit surprised at seeing this:
'{0}'.format('foo')
'foo'
'{ 0}'.format('foo')
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: ' 0'
'{a}'.format(a='foo')
'foo'
'{ a}'.format(a='foo')
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: ' a'
In some other cases, leading and trailing spaces are ignored:
int(' 0 ')
0
Outside string literals, they're also ignored.
But, then:
'{-1}'.format('foo')
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: '-1'
It's a string key, even though it looks like an int position.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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
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, 4)]}'
For me, this example is crazy. You should not add a special case (ignore
spaces) just to support a corner case.
Is it a special case? Don't we already ignore leading spaces in
bracketed expressions?
This example can easily be rewritten using a temporary variable and it
makes the code simpler.
items={k:v for k, v in [(1, 2), (3, 4)]; f'{items}'
Seriously, a dict-comprehension inside a f-string should be considered
as an abuse of the feature. Don't you think so?
True. Or we can wrap it in parentheses. :-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 differences between f-string and str.format(). The expressions supported are so vastly different that I don't think the whitespace issue matters. Eric. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 by the PEP. Agreed. Eric. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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
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,
4)]}'
For me, this example is crazy. You should not add a special case (ignore
spaces) just to support a corner case.
This example can easily be rewritten using a temporary variable and it
makes the code simpler.
items={k:v for k, v in [(1, 2), (3, 4)]; f'{items}'
Seriously, a dict-comprehension inside a f-string should be considered
as an abuse of the feature. Don't you think so?
Yes, it's absolutely an abuse and should never be written. But if the
only cost to allowing it is skipping leading spaces, I don't see the
harm. It sounds like you want to disallow leading spaces just to
disallow this one type of expression.
My other use case for spaces, which I've not added to the PEP yet, is
for alignment, like:
f' x={ x:15}'
f'xx={xx:15}'
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces
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 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces
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 compatibility doesn't matter here. There's another reason to resist the fu'...' prefix: political correctness. 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 you think it might. I can just imagine reciting one of these new strings out loud... Cheers, Cameron Simpson c...@zip.com.au People shouldn't be allowed to build overpasses ... - Dianne I know what's best for you Feinstein after the '94 LA quake. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces
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 Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 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 differences between
f-string and str.format().
I'm a little bit surprised at seeing this:
'{0}'.format('foo')
'foo'
'{ 0}'.format('foo')
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: ' 0'
'{a}'.format(a='foo')
'foo'
'{ a}'.format(a='foo')
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: ' a'
In some other cases, leading and trailing spaces are ignored:
int(' 0 ')
0
Outside string literals, they're also ignored.
But, then:
'{-1}'.format('foo')
Traceback (most recent call last):
File stdin, line 1, in module
KeyError: '-1'
It's a string key, even though it looks like an int position.
I think there are bug tracker issues for both of these. I think the
argument against changing them is that people might be depending on this
behavior. I'll grant you it seems unlikely, but you never know.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
