Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
Date: Sun, 19 Jul 2015 04:26:27 -0400
References: <moenuj$f11$1@ger.gmane.org> <moeqtn$mh0$1@ger.gmane.org> <moeurf$a6f$1@ger.gmane.org> <mailman.695.1437273248.3674.python-list@python.org> <7083e494-6192-4acb-aea9-216d858171bc@googlegroups.com> <55ab2b57$0$1664$c3e8da3$5496439d@news.astraweb.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
In-Reply-To: <55ab2b57$0$1664$c3e8da3$5496439d@news.astraweb.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.705.1437294417.3674.python-list@python.org>
Lines: 94
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:94106

On 7/19/2015 12:45 AM, Steven D'Aprano wrote:
> On Sun, 19 Jul 2015 01:52 pm, Rustom Mody wrote:

>> JFTR: My kids (um... students) have just managed to add devanagari
>> numerals to python.
>> ie we can now do
>>
>>>>> =E0=A5=A7 + =E0=A5=A8
>> 3
>
> That is actually quite awesome, and I would support a new feature that =
set
> the numeric characters to a particular script, e.g. Latin, Arabic,
> Devanagari, whatever, and printed them in that same script. It seems
> unfortunate that =E0=A5=A7 + =E0=A5=A8 prints as 3 rather than =E0=A5=A9=
=2E
>
> Python already, and has for many years, supported non-ASCII digits in s=
tring
> conversions. This is in Python 2.4:
>
> py> int(u'=E0=A5=A7=E0=A5=A8')
> 12
> py> float(u'.=E0=A5=A7=E0=A5=A8')
> 0.12
>
>
> so the feature goes back a long time.
>
> I think that Python should allow int and float literals using any seque=
nces
> of digits from the same language, e.g. 12 or =E0=A5=A7=E0=A5=A8 but not=
 =E0=A5=A72.

This could be done easily by adding 10 modified productions from
https://docs.python.org/3/reference/lexical_analysis.html#integer-literal=
s
for each language.  The problem of doing the above in the grammar,=20
including the no mixing rule, is that is *would* take a separate set of=20
productions for each language supported.

 > One might have
> an interpreter hook which displayed ints and floats using non-ASCII dig=
its,
> or one might even build that function into the intepreter, e.g. have a
> global setting which tells ints and floats what digits to use, e.g.:
>
> sys.setdigits('Devanagari')
>
> I would support this, or something like this, as a language feature. If=
 we
> can write Python using Hindi identifiers, why not Hindi numerals?

As I remember, when non-ascii-digit inputs to int were last discussed=20
(python-ideas?, pydev?), the possibility of expanding literals was=20
mentioned.  As I remember, to idea was rejected or deferred on the basis =

that nearly all numbers used in production programs are read from files=20
as numbers or converted by int or float.  The few numeric literals in=20
programs could just as well be converted first, or the int expression=20
could be used.

These true observations do not cover the shell, as in the examples=20
above.  At some time, Guido has expresses the opinion that interactive=20
console python should remain plain and basic and the fancier interaction =

features are the domain of replacement shells.

That brings me, anyway, to Idle.  It currently imitates console python=20
in sending keystrokes as is to compile() and output streams as are to=20
the tk display.  There are a couple of tracker issues claiming that this =

means that Idle does not imitate console python because a tk display=20
does not treat backspace and return the same way simulated terminal=20
consoles usually do.

While the bug claims have been rejected, I have been thinking that the=20
Idle extension interface could and maybe should be extended so that=20
extensions could filter and either transform or act on the input/output=20
streams.

With a general mechanism in place, it would be trivial to use=20
str.maketrans and str.translate in the input/output streams.  This would =

not disable ascii digit input, including mixtures in a single literal,=20
but output has to all be in one digit set.  Selecting a language is a=20
somewhat solved problem because last summer we added a extension=20
configuration dialog that dynamically generates a dialog tab for each=20
extension present.

--=20
Terry Jan Reedy