Re: [Python-ideas] Format mini-language for lakh and crore

On 1 February 2018 at 14:11, Nick Coghlan wrote: > On 1 February 2018 at 08:14, Eric V. Smith wrote: >> On 1/29/2018 2:13 AM, Nick Coghlan wrote: >>> Given the example, I think a more useful approach would be to allow an >>> optional digit grouping specifier after the comma separator, and allow >

Re: [Python-ideas] Format mini-language for lakh and crore

On Jan 31, 2018 8:12 PM, "Nick Coghlan" wrote: On 1 February 2018 at 08:14, Eric V. Smith wrote: >>> print(f"In European format x is {x:,.2f}, in Indian format it is {x:,2,3.2f}") > This just seems too complicated to me, and is overgeneralizing. How many of > these different formats would ever

Re: [Python-ideas] Format mini-language for lakh and crore

On 1 February 2018 at 08:14, Eric V. Smith wrote: > On 1/29/2018 2:13 AM, Nick Coghlan wrote: >> Given the example, I think a more useful approach would be to allow an >> optional digit grouping specifier after the comma separator, and allow >> the separator to be repeated to indicate non-uniform

Re: [Python-ideas] Support WHATWG versions of legacy encodings

On Thu, Feb 1, 2018 at 10:15 AM, Chris Barker wrote: > I still have no ide4a why there is such resistance to this -- yes, it's a > fairly small benefit over a package no PyPi, but there is also virtually no > downside. I don't understand it either. Aside from maybe bikeshedding the *name* of the

Re: [Python-ideas] Support WHATWG versions of legacy encodings

On Wed, Jan 31, 2018 at 9:48 AM, Serhiy Storchaka wrote: > Hm. As a user, unless I run into problems with a specific encoding, I >> never care about how many encodings we have, so I don't see how adding >> extra encodings bothers those users who have no need for them. >> > > The codecs module doc

Re: [Python-ideas] Format mini-language for lakh and crore

On 1/29/2018 2:13 AM, Nick Coghlan wrote: On 29 January 2018 at 11:48, Nathaniel Smith wrote: On Sun, Jan 28, 2018 at 5:31 PM, David Mertz wrote: I actually didn't know about `locale.format("%d", 10e9, grouping=True)`. But it's still much less general than having the option in the f-string/.f

Re: [Python-ideas] Support WHATWG versions of legacy encodings

On Wed, 31 Jan 2018 at 12:50 Serhiy Storchaka wrote: > The passed encoding differs from the name of new Python encoding. It is > just 'windows-1252', not 'windows-1252-whatwg'. If just change the > existing encoding, this can break other code that expects the standard > 'windows-1252'. Thus every

Re: [Python-ideas] Support WHATWG versions of legacy encodings

OK, I am no longer interested in this topic. If you can't reach agreement, so be it, and then the status quo prevails. I am going to mute this thread. There's no need to explain to me why I am wrong. On Wed, Jan 31, 2018 at 9:48 AM, Serhiy Storchaka wrote: > 31.01.18 18:36, Guido van Rossum пише

Re: [Python-ideas] Support WHATWG versions of legacy encodings

31.01.18 18:36, Guido van Rossum пише: On Wed, Jan 31, 2018 at 3:03 AM, Serhiy Storchaka > wrote: 19.01.18 05:51, Guido van Rossum пише: Can someone explain to me why this is such a controversial issue? It seems reasonable to me to add new encod

Re: [Python-ideas] Support WHATWG versions of legacy encodings

On 31.01.2018 17:36, Guido van Rossum wrote: > On Wed, Jan 31, 2018 at 3:03 AM, Serhiy Storchaka > wrote: > > 19.01.18 05:51, Guido van Rossum пише: > > Can someone explain to me why this is such a controversial issue? > > It seems reasonable to m

Re: [Python-ideas] Support WHATWG versions of legacy encodings

On Wed, Jan 31, 2018 at 3:03 AM, Serhiy Storchaka wrote: > 19.01.18 05:51, Guido van Rossum пише: > >> Can someone explain to me why this is such a controversial issue? >> >> It seems reasonable to me to add new encodings to the stdlib that do the >> roundtripping requested in the first message o

Re: [Python-ideas] Adding str.isascii() ?

For the record, I encouraged this. I see no reason to amend my decision. Only .isascii(), for str, bytes, bytearray. No ascii= flags to other functions. On Wed, Jan 31, 2018 at 4:17 AM, Serhiy Storchaka wrote: > 31.01.18 13:18, INADA Naoki пише: > >> Yes. But .isascii() will be match faster tha

Re: [Python-ideas] Adding str.isascii() ?

On Thu, Feb 1, 2018 at 12:44 AM, Victor Stinner wrote: > I like the idea of str.isdigit(ascii=True): would behave as > str.isdigit() and str.isascii(). It's easy to implement and likely to > be very efficient. I'm just not sure that it's so commonly required? > > At least, I guess that some users

Re: [Python-ideas] Adding str.isascii() ?

I like the idea of str.isdigit(ascii=True): would behave as str.isdigit() and str.isascii(). It's easy to implement and likely to be very efficient. I'm just not sure that it's so commonly required? At least, I guess that some users can be surprised that str.isdigit() is "Unicode aware", accept no

Re: [Python-ideas] Adding str.isascii() ?

31.01.18 13:18, INADA Naoki пише: Yes. But .isascii() will be match faster than try ... .encode('ascii') ... except UnicodeEncodeError on most Python implementations. In this case this doesn't matter since this is an exceptional case, and in any case an exception is raised for non-ascii strin

Re: [Python-ideas] Adding str.isascii() ?

Hm, it seems I was too hurry to implement it... > > There were discussions about this. See for example > https://bugs.python.org/issue18814. > > In short, there are two considerations that prevented adding this feature: > > 1. This function can have the constant computation complexity in CPython >

Re: [Python-ideas] Support WHATWG versions of legacy encodings

19.01.18 05:51, Guido van Rossum пише: Can someone explain to me why this is such a controversial issue? It seems reasonable to me to add new encodings to the stdlib that do the roundtripping requested in the first message of the thread. As long as they have new names that seems to fall under

Re: [Python-ideas] Adding str.isascii() ?

26.01.18 10:42, INADA Naoki пише: Currently, int(), str.isdigit(), str.isalnum(), etc... accepts non-ASCII strings. s = １２３" s '１２３' s.isdigit() True print(ascii(s)) '\uff11\uff12\uff13' int(s) 123 But sometimes, we want to accept only ascii string. For example, ipaddress module uses: