Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #94083 > unrolled thread

Re: Should non-security 2.7 bugs be fixed?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Should non-security 2.7 bugs be fixed? Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-07-18 19:33 -0700
    Re: Should non-security 2.7 bugs be fixed? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-18 19:49 -0700
    Re: Should non-security 2.7 bugs be fixed? Rustom Mody <rustompmody@gmail.com> - 2015-07-18 20:52 -0700
      Re: Should non-security 2.7 bugs be fixed? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-18 21:18 -0700
      Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Steven D'Aprano <steve@pearwood.info> - 2015-07-19 14:45 +1000
        Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Chris Angelico <rosuav@gmail.com> - 2015-07-19 15:06 +1000
          Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Marko Rauhamaa <marko@pacujo.net> - 2015-07-19 10:16 +0300
            Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-07-19 00:32 -0700
              Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Marko Rauhamaa <marko@pacujo.net> - 2015-07-19 10:44 +0300
              Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Terry Reedy <tjreedy@udel.edu> - 2015-07-19 19:13 -0400
                Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-07-19 19:02 -0700
        Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Anuradha Laxminarayan <lanuradha@gmail.com> - 2015-07-18 23:25 -0700
        Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Terry Reedy <tjreedy@udel.edu> - 2015-07-19 04:26 -0400
        Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Tim Chase <python.list@tim.thechases.com> - 2015-07-19 07:56 -0500
        Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Chris Angelico <rosuav@gmail.com> - 2015-07-20 04:07 +1000
        Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Tim Chase <python.list@tim.thechases.com> - 2015-07-19 14:55 -0500
        Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Chris Angelico <rosuav@gmail.com> - 2015-07-20 07:16 +1000
          Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] wxjmfauth@gmail.com - 2015-07-20 00:43 -0700
        Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] MRAB <python@mrabarnett.plus.com> - 2015-07-19 23:13 +0100
        Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-07-20 20:30 -0700
          Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Chris Angelico <rosuav@gmail.com> - 2015-07-21 13:43 +1000
            Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-07-20 23:11 -0700
          Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Laura Creighton <lac@openend.se> - 2015-07-21 10:10 +0200
            Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Marko Rauhamaa <marko@pacujo.net> - 2015-07-21 12:10 +0300
              Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Chris Angelico <rosuav@gmail.com> - 2015-07-21 19:18 +1000
                Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Marko Rauhamaa <marko@pacujo.net> - 2015-07-21 13:13 +0300
              Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-21 11:34 +0100
              Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-07-21 20:39 +1000
                Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Marko Rauhamaa <marko@pacujo.net> - 2015-07-21 13:54 +0300
                  Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Marko Rauhamaa <marko@pacujo.net> - 2015-08-09 00:27 +0300
                    Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-08-09 09:29 -0700
                Re:  Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-07-22 06:34 -0700
                  OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Steven D'Aprano <steve@pearwood.info> - 2015-07-23 02:58 +1000
                    Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Laura Creighton <lac@openend.se> - 2015-07-22 19:17 +0200
                      Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-07-22 10:49 -0700
                        Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Laura Creighton <lac@openend.se> - 2015-07-22 20:14 +0200
                        Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-22 21:59 +0100
                    Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Steven D'Aprano <steve@pearwood.info> - 2015-07-23 03:21 +1000
                      Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-07-22 21:44 -0400
                      Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Chris Angelico <rosuav@gmail.com> - 2015-07-23 12:00 +1000
                    Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Paul Rubin <no.email@nospam.invalid> - 2015-07-22 10:48 -0700
                      Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-07-22 10:51 -0700
                      Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-07-23 15:14 +1000
                    Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-07-22 11:09 -0700
                      Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-07-23 15:41 +1000
                        Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Marko Rauhamaa <marko@pacujo.net> - 2015-07-23 23:59 +0300
                          Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Chris Angelico <rosuav@gmail.com> - 2015-07-24 07:03 +1000
                            Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Marko Rauhamaa <marko@pacujo.net> - 2015-07-24 00:29 +0300
                              Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-23 22:50 +0100
                              Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Laura Creighton <lac@openend.se> - 2015-07-23 23:52 +0200
                                Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Marko Rauhamaa <marko@pacujo.net> - 2015-07-24 00:59 +0300
                                  Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Chris Angelico <rosuav@gmail.com> - 2015-07-24 08:02 +1000
                              Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Chris Angelico <rosuav@gmail.com> - 2015-07-24 08:00 +1000
                              Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] MRAB <python@mrabarnett.plus.com> - 2015-07-23 23:01 +0100
                              Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Laura Creighton <lac@openend.se> - 2015-07-24 00:19 +0200
                              Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-23 23:56 +0100
                              Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Grant Edwards <invalid@invalid.invalid> - 2015-07-24 00:07 +0000
                                Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-23 18:40 -0700
                                Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Paul Rubin <no.email@nospam.invalid> - 2015-07-23 19:03 -0700
                                  Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-23 20:16 -0700
                                  Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Grant Edwards <invalid@invalid.invalid> - 2015-07-24 14:13 +0000
                                    Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Paul Rubin <no.email@nospam.invalid> - 2015-07-24 08:45 -0700
                                    Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-24 16:58 +0100
                              Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-07-23 22:15 -0700
                      Re: OT Re: Math-embarrassment results in CS [was: Should non-security   2.7 bugs be fixed?] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-07-23 18:57 +1200
                        Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-07-23 02:12 -0700
                        Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Rustom Mody <rustompmody@gmail.com> - 2015-07-23 05:52 -0700
                    Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?] Marko Rauhamaa <marko@pacujo.net> - 2015-07-23 11:24 +0300
          Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-07-21 18:57 +1000
      Re: Should non-security 2.7 bugs be fixed? Terry Reedy <tjreedy@udel.edu> - 2015-07-19 02:44 -0400
      Re: Should non-security 2.7 bugs be fixed? Terry Reedy <tjreedy@udel.edu> - 2015-07-19 05:11 -0400
        Re: Should non-security 2.7 bugs be fixed? Rustom Mody <rustompmody@gmail.com> - 2015-07-19 07:30 -0700
      Re: Should non-security 2.7 bugs be fixed? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-19 15:00 +0100
    Re: Should non-security 2.7 bugs be fixed? Steven D'Aprano <steve@pearwood.info> - 2015-07-19 14:45 +1000
      Re: Should non-security 2.7 bugs be fixed? Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-07-19 18:20 -0700
        Re: Should non-security 2.7 bugs be fixed? Steven D'Aprano <steve@pearwood.info> - 2015-07-20 13:05 +1000
          Re: Should non-security 2.7 bugs be fixed? Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-07-19 20:41 -0700
      Re: Should non-security 2.7 bugs be fixed? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-20 02:46 +0100
        Re: Should non-security 2.7 bugs be fixed? Rustom Mody <rustompmody@gmail.com> - 2015-07-19 19:16 -0700
          Re: Should non-security 2.7 bugs be fixed? Chris Angelico <rosuav@gmail.com> - 2015-07-20 12:59 +1000
          Re: Should non-security 2.7 bugs be fixed? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-20 11:59 +0100
          Re: Should non-security 2.7 bugs be fixed? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-20 20:04 -0700
            Re: Should non-security 2.7 bugs be fixed? Rustom Mody <rustompmody@gmail.com> - 2015-07-20 20:15 -0700
              Re: Should non-security 2.7 bugs be fixed? Chris Angelico <rosuav@gmail.com> - 2015-07-21 13:33 +1000
              Re: Should non-security 2.7 bugs be fixed? Terry Reedy <tjreedy@udel.edu> - 2015-07-21 00:45 -0400
            Re: Should non-security 2.7 bugs be fixed? breamoreboy@gmail.com - 2015-07-21 14:22 -0700
              Re: Should non-security 2.7 bugs be fixed? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-21 19:07 -0700
                Re: Should non-security 2.7 bugs be fixed? Terry Reedy <tjreedy@udel.edu> - 2015-07-22 02:51 -0400
                  Re: Should non-security 2.7 bugs be fixed? Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-22 16:37 -0700
      Re: Should non-security 2.7 bugs be fixed? Terry Reedy <tjreedy@udel.edu> - 2015-07-20 02:25 -0400
      Re: Should non-security 2.7 bugs be fixed? dieter <dieter@handshake.de> - 2015-07-20 08:58 +0200
      Re: Should non-security 2.7 bugs be fixed? Devin Jeanpierre <jeanpierreda@gmail.com> - 2015-07-20 00:13 -0700

Page 1 of 5  [1] 2 3 4 5  Next page →

#94083 — Re: Should non-security 2.7 bugs be fixed?

On Sat, Jul 18, 2015 at 6:34 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 7/18/2015 8:27 PM, Mark Lawrence wrote:
>> On 19/07/2015 00:36, Terry Reedy wrote:
>> Programmers don't much like doing maintainance work when they're paid to
>> do it, so why would they volunteer to do it?
>
> Right.  So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x core
> developer reviews and edits the patch until it is ready to commit, why
> should either of them volunteer to do a 2.7 backport that they will not use?

Because it helps even more people. The reason people make upstream
contributions is so that the world benefits. If you only wanted to
help yourself, you'd just patch CPython locally, and not bother
contributing anything upstream.

> I am suggesting that if there are 10x as many 2.7only programmers as 3.xonly
> programmers, and none of the 2.7 programmers is willing to do the backport
> *of an already accepted patch*, then maybe it should not be done at all.

That just isn't true. I have backported 3.x patches. Other people have
backported entire modules.

It gets really boring submitting 2.7-specific patches, though, when
they aren't accepted, and the committers have such a hostile attitude
towards it. I was told by core devs that, instead of fixing bugs in
Python 2, I should just rewrite my app in Python 3. It has even been
implied that bugs in Python 2 are *good*, because that might help with
Python 3 adoption.

>> Then even if you do the
>> work to fix *ANY* bug there is no guarantee that it gets committed.
>
> I am discussing the situation where there *is* a near guarantee (if the
> backport works and does not break anything and has not been so heavily
> revised as to require a separate review).

That is not how I have experienced contribution to CPython. No, the
patches are *not* guaranteed, and in my experience they are not likely
to be accepted.

If the issue was closed as fixed before I contributed the backported
patch, does anyone even see it?

-- Devin

[toc] | [next] | [standalone]

#94086

On Saturday, July 18, 2015 at 9:34:20 PM UTC-5, Devin Jeanpierre wrote:
> It has even been implied that bugs in Python 2 are *good*,
> because that might help with Python 3 adoption.

So now we're implementing coercion, Microsoft style? What's
next, paid subscriptions to superficial, and backwards
incompatible, upgrades every two years? Perhaps after that, 
we can roll our own security vulnerabilities and inject them 
into the deprecated source downloads!

  You'll pay 2x users! You'll pay! And your little repos too!

[toc] | [prev] | [next] | [standalone]

#94089

On Sunday, July 19, 2015 at 8:04:20 AM UTC+5:30, Devin Jeanpierre wrote:
> On Sat, Jul 18, 2015 at 6:34 PM, Terry Reedy  wrote:
> > On 7/18/2015 8:27 PM, Mark Lawrence wrote:
> >> On 19/07/2015 00:36, Terry Reedy wrote:
> >> Programmers don't much like doing maintainance work when they're paid to
> >> do it, so why would they volunteer to do it?
> >
> > Right.  So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x core
> > developer reviews and edits the patch until it is ready to commit, why
> > should either of them volunteer to do a 2.7 backport that they will not use?
> 
> Because it helps even more people. The reason people make upstream
> contributions is so that the world benefits. If you only wanted to
> help yourself, you'd just patch CPython locally, and not bother
> contributing anything upstream.
> 
> > I am suggesting that if there are 10x as many 2.7only programmers as 3.xonly
> > programmers, and none of the 2.7 programmers is willing to do the backport
> > *of an already accepted patch*, then maybe it should not be done at all.
> 
> That just isn't true. I have backported 3.x patches. Other people have
> backported entire modules.
> 
> It gets really boring submitting 2.7-specific patches, though, when
> they aren't accepted, and the committers have such a hostile attitude
> towards it. I was told by core devs that, instead of fixing bugs in
> Python 2, I should just rewrite my app in Python 3. It has even been
> implied that bugs in Python 2 are *good*, because that might help with
> Python 3 adoption.
> 
> >> Then even if you do the
> >> work to fix *ANY* bug there is no guarantee that it gets committed.
> >
> > I am discussing the situation where there *is* a near guarantee (if the
> > backport works and does not break anything and has not been so heavily
> > revised as to require a separate review).
> 
> That is not how I have experienced contribution to CPython. No, the
> patches are *not* guaranteed, and in my experience they are not likely
> to be accepted.
> 
> If the issue was closed as fixed before I contributed the backported
> patch, does anyone even see it?

Not to mention actively hostile attitude to discussions that could at the 
moment be tangential to current CPython. See (and whole thread)
https://mail.python.org/pipermail/python-ideas/2015-May/033708.html

JFTR: My kids (um... students) have just managed to add devanagari numerals to 
python.
ie we can now do

>>> १ + २
3

[The devanagari equivalent of "12334567890" is "१२३४५६७८९०"
And also for those who may not be familiar, devanagari is the script for
sanskrit, hindi and a slew of (north) Indian languages
]

Regarding this as a fork of python is technically (legalistically) correct but
pragmatically ridiculous [unless my students spell as 'Linus Torvalds' or somethin...].

Note that while I dont regard that specific answer as representative of the
python-community at large, it is also true that a little help -- even brusque
RTFM answers¹ -- would have seen us farther than "If this is what you are up to, get out of here"

tl;dr: Not so much a complaint but a indicator that people who could 
potentially contribute are being prevented from entering

------
¹ For me, RTFM is always welcome if accompanied by which FM

[toc] | [prev] | [next] | [standalone]

#94091

On Saturday, July 18, 2015 at 10:52:51 PM UTC-5, Rustom Mody wrote:
> tl;dr: Not so much a complaint but a indicator that people
> who could potentially contribute are being prevented from
> entering

EXACTLY! If this community fails, it won't be due to old
members walking out of the back door, no, it will be because
the front door was slammed shut and nails were driven into
the frame, preventing new members from entering! 

We are not in a freaking zombie movie people! We're in a
freaking community! And communities require doors to be
unlocked during business hours. Communities require welcome
mats. But mostly of all, communities require hospitality.

[toc] | [prev] | [next] | [standalone]

#94092 — Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Sun, 19 Jul 2015 01:52 pm, Rustom Mody wrote:

> Not to mention actively hostile attitude to discussions that could at the
> moment be tangential to current CPython. See (and whole thread)
> https://mail.python.org/pipermail/python-ideas/2015-May/033708.html

I stand by my comments there. I have no disagreement with your aim to build
a specialised language for teaching functional programming. I don't believe
that should be Python.


> JFTR: My kids (um... students) have just managed to add devanagari
> numerals to python.
> ie we can now do
> 
>>>> १ + २
> 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 १ + २ prints as 3 rather than ३.

Python already, and has for many years, supported non-ASCII digits in string
conversions. This is in Python 2.4:

py> int(u'१२')
12
py> float(u'.१२')
0.12


so the feature goes back a long time.

I think that Python should allow int and float literals using any sequences
of digits from the same language, e.g. 12 or १२ but not १2. One might have
an interpreter hook which displayed ints and floats using non-ASCII digits,
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?


> Regarding this as a fork of python is technically (legalistically) correct
> but pragmatically ridiculous [unless my students spell as 'Linus Torvalds'
> or somethin...].

There's a grey area between a fork and a local patch. Ever fork begins as a
local patch. It only becomes a fork if you go public with it, give it a new
name, etc. Forks can be highly respected, e.g. Stackless is a fork of
CPython.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#94094 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Sun, Jul 19, 2015 at 2:45 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> I think that Python should allow int and float literals using any sequences
> of digits from the same language, e.g. 12 or १२ but not १2.

I would agree with this. Actually, given that int("१२") works just
fine, I was surprised that it didn't already work in syntax.

> One might have
> an interpreter hook which displayed ints and floats using non-ASCII digits,
> 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')

Easiest way to play with this would be a sys.displayhook, I think; I
suspect it would be problematic to change int.__str__ or int.__repr__.
But for interactive work, yep, definitely, it should be easy enough to
make int and float display appropriately.

ChrisA

[toc] | [prev] | [next] | [standalone]

#94102 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

Chris Angelico <rosuav@gmail.com>:

> On Sun, Jul 19, 2015 at 2:45 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> sys.setdigits('Devanagari')
>
> Easiest way to play with this would be a sys.displayhook, I think;

I think the numeral selection is analogous to the number base:

   >>> 0o10
   8
   >>> "{:o}".format(0o10)
   '10'

what we need is:

   >>> "{:d/base({base})}".format(0o10, base=7)
   '11'
   >>> "{:d/numeral('{num}')".format(0o10, num="European")
   '8'
   >>> "{:d/numeral('{num}')".format(0o10, num="Roman")
   'VIII'
   >>> "{:d/numeral('{num}')".format(0o10, num="RomanLowerCase")
   'viii'
   >>> "{:d/numeral('{num}')".format(0o10, num="EasternArabic")
   '٨'
   >>> "{:d/numeral('{num}')".format(0o10, num="Devanagari")
   '८'

IOW, don't make it global.


Marko

[toc] | [prev] | [next] | [standalone]

#94103 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Sunday, July 19, 2015 at 12:46:26 PM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico:
> 
> > On Sun, Jul 19, 2015 at 2:45 PM, Steven D'Aprano  wrote:
> >> sys.setdigits('Devanagari')
> >
> > Easiest way to play with this would be a sys.displayhook, I think;
> 
> I think the numeral selection is analogous to the number base:

Nice analogy

> 
>    >>> 0o10
>    8
>    >>> "{:o}".format(0o10)
>    '10'
> 
> what we need is:
> 
>    >>> "{:d/base({base})}".format(0o10, base=7)
>    '11'
>    >>> "{:d/numeral('{num}')".format(0o10, num="European")
>    '8'
>    >>> "{:d/numeral('{num}')".format(0o10, num="Roman")
>    'VIII'
>    >>> "{:d/numeral('{num}')".format(0o10, num="RomanLowerCase")
>    'viii'
>    >>> "{:d/numeral('{num}')".format(0o10, num="EasternArabic")
>    '٨'
>    >>> "{:d/numeral('{num}')".format(0o10, num="Devanagari")
>    '८'
> 
> IOW, don't make it global.

But it is willy-nilly global.
Python:
>>> 4+5
9
>>> 

Unix bc:
$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
4+5
9
obase=8
4+5
11

IOW bc has two (global) variables ibase and obase for input and output base.
If you dont provide these as settable you hardwire them at 10 (8/16 in some
assembly languages)¹

Hopefully you will agree that python is more full-featured than bc and should
subsume bc functionality?

[Implementability is a second question and ease of implementability a third]

I believe numeral-language is similar

---
¹ When Ive played around with writing assemblers for toy machines, the hardwired
10-base has often been a nuisance. Of course one can in principle rebuild an REPL.
Repurposing the existing one is usually a far more palatable option (for me).

[toc] | [prev] | [next] | [standalone]

#94104 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

Rustom Mody <rustompmody@gmail.com>:

> On Sunday, July 19, 2015 at 12:46:26 PM UTC+5:30, Marko Rauhamaa wrote:
>> IOW, don't make it global.
>
> But it is willy-nilly global.
> Python:
>>>> 4+5
> 9

The interactive mode is not all that interesting, but ok, make that
configurable as well.


Marko

[toc] | [prev] | [next] | [standalone]

#94175 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On 7/19/2015 3:32 AM, Rustom Mody wrote:

> Unix bc:
> $ bc
> bc 1.06.95
> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
> This is free software with ABSOLUTELY NO WARRANTY.
> For details type `warranty'.
> 4+5
> 9
> obase=8
> 4+5
> 11
>
> IOW bc has two (global) variables ibase and obase for input and output base.
> If you dont provide these as settable you hardwire them at 10 (8/16 in some
> assembly languages)¹
>
> Hopefully you will agree that python is more full-featured than bc and should
> subsume bc functionality?

Nice try ;-) However, I think is not especially relevant.  I do not 
believe that Guido would agree that bc should govern python design. Do 
*you* really think that?  Python is fundamentally a general purpose 
batch-mode language.  Interactive mode is secondary and generally 
subservient to writing real programs.  I know that he has said that he 
is not inclined to add additional interactive-mode-only features to Python.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#94188 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Monday, July 20, 2015 at 4:43:57 AM UTC+5:30, Terry Reedy wrote:
> On 7/19/2015 3:32 AM, Rustom Mody wrote:
> 
> > Unix bc:
> > $ bc
> > bc 1.06.95
> > Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
> > This is free software with ABSOLUTELY NO WARRANTY.
> > For details type `warranty'.
> > 4+5
> > 9
> > obase=8
> > 4+5
> > 11
> >
> > IOW bc has two (global) variables ibase and obase for input and output base.
> > If you dont provide these as settable you hardwire them at 10 (8/16 in some
> > assembly languages)¹
> >
> > Hopefully you will agree that python is more full-featured than bc and should
> > subsume bc functionality?
> 
> Nice try ;-) However, I think is not especially relevant.  I do not 
> believe that Guido would agree that bc should govern python design. Do 
> *you* really think that?  Python is fundamentally a general purpose 
> batch-mode language.  Interactive mode is secondary and generally 
> subservient to writing real programs.  I know that he has said that he 
> is not inclined to add additional interactive-mode-only features to Python.

We will have to agree to disagree then.

I wrote this in 2012 (that is to say not in context of this discussion):
http://blog.languager.org/2012/10/functional-programming-lost-booty.html

in which I list an REPL as one of the factors that distinguish a modern, 
powerful v hi-level language from stodgy old-fashioned blub languages.

Regarding your earlier points about idle, I think you are (to use a traditional 
OS metaphor) mixing up policy with mechanism.
Policy: Having a REPL (things like Idle)
Mechanism: How exactly its bundled

eg in pythonland python the interpreter and the interactive version are the same
executable functioning in different modes
In other languages (haskell has ghci, ruby has irb) the interactive interpreter
is a different program (just a thin wrapper) on the main interpreter (compiler
for haskell)
Likewise in debian (ubuntu) vs windows the bundling is v different.
In debian python comes for free and the system would not work without it but tkinter, idle etc need to be installed with their dependencies
In windows, one needs to install one bundle and one gets the whole lot...

Of course as recently discussed, it may be time to have ipython replace vanilla
python and therefore break that off from the core. 

These are (to me) minor points compared to the existence/non-existence of  an interactive interpreter.

[toc] | [prev] | [next] | [standalone]

#94099 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Sunday, July 19, 2015 at 10:15:37 AM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 19 Jul 2015 01:52 pm, Rustom Mody wrote:
>
> > Not to mention actively hostile attitude to discussions that could at the
> > moment be tangential to current CPython. See (and whole thread)
> > https://mail.python.org/pipermail/python-ideas/2015-May/033708.html
>
> I stand by my comments there. I have no disagreement with your aim to build
> a specialised language for teaching functional programming. I don't believe
> that should be Python.
>
>
> > JFTR: My kids (um... students) have just managed to add devanagari
> > numerals to python.
> > ie we can now do
> >
> >>>> १ + २
> > 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 १ + २ prints as 3 rather than ३.

Thanks. [I am part of this team]

>
> Python already, and has for many years, supported non-ASCII digits in string
> conversions. This is in Python 2.4:
>
> py> int(u'१२')
> 12
> py> float(u'.१२')
> 0.12
>

Very useful to know!

>
> so the feature goes back a long time.
>
> I think that Python should allow int and float literals using any sequences
> of digits from the same language, e.g. 12 or १२ but not १2. One might have
> an interpreter hook which displayed ints and floats using non-ASCII digits,
> 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')
>


Currently our code works with UTF-8 byte sequences not unicode codepoints
because thats how tokenizer.c is structured: messy and not generalizable (easily) to things beyond devanagari.  How far this can be improved (without too deep surgery) is not quite clear yet.

In other words, this generality is nice to talk about but easier said than done at the moment.

[toc] | [prev] | [next] | [standalone]

#94106 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

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
>>
>>>>> १ + २
>> 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 १ + २ prints as 3 rather than ३.
>
> Python already, and has for many years, supported non-ASCII digits in string
> conversions. This is in Python 2.4:
>
> py> int(u'१२')
> 12
> py> float(u'.१२')
> 0.12
>
>
> so the feature goes back a long time.
>
> I think that Python should allow int and float literals using any sequences
> of digits from the same language, e.g. 12 or १२ but not १2.

This could be done easily by adding 10 modified productions from
https://docs.python.org/3/reference/lexical_analysis.html#integer-literals
for each language.  The problem of doing the above in the grammar, 
including the no mixing rule, is that is *would* take a separate set of 
productions for each language supported.

 > One might have
> an interpreter hook which displayed ints and floats using non-ASCII digits,
> 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 
(python-ideas?, pydev?), the possibility of expanding literals was 
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 
as numbers or converted by int or float.  The few numeric literals in 
programs could just as well be converted first, or the int expression 
could be used.

These true observations do not cover the shell, as in the examples 
above.  At some time, Guido has expresses the opinion that interactive 
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 
in sending keystrokes as is to compile() and output streams as are to 
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 
does not treat backspace and return the same way simulated terminal 
consoles usually do.

While the bug claims have been rejected, I have been thinking that the 
Idle extension interface could and maybe should be extended so that 
extensions could filter and either transform or act on the input/output 
streams.

With a general mechanism in place, it would be trivial to use 
str.maketrans and str.translate in the input/output streams.  This would 
not disable ascii digit input, including mixtures in a single literal, 
but output has to all be in one digit set.  Selecting a language is a 
somewhat solved problem because last summer we added a extension 
configuration dialog that dynamically generates a dialog tab for each 
extension present.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#94138 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On 2015-07-19 14:45, Steven D'Aprano wrote:
>> ie we can now do
>>>>> १ + २  
>> 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 १ + २ prints as 3 rather than ३.
> 
> Python already, and has for many years, supported non-ASCII digits
> in string conversions. This is in Python 2.4:
> 
> py> int(u'१२')  
> 12
> py> float(u'.१२')  
> 0.12
> 
> so the feature goes back a long time.

Agreed that it's pretty awesome.  It seems to have some holes though:

Python 3.4.2 (default, Oct  8 2014, 10:45:20) 
[GCC 4.9.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print('\N{VULGAR FRACTION ONE EIGHTH}')
⅛
>>> print(float('\N{VULGAR FRACTION ONE EIGHTH}'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: '⅛'
>>> print('\N{ROMAN NUMERAL NINE}')
Ⅸ
>>> int('\N{ROMAN NUMERAL NINE}')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: 'Ⅸ'
>>> print('\N{ROMAN NUMERAL TEN THOUSAND}')
ↂ
>>> int('\N{ROMAN NUMERAL TEN THOUSAND}')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: 'ↂ'

-tkc

[toc] | [prev] | [next] | [standalone]

#94143 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Sun, Jul 19, 2015 at 10:56 PM, Tim Chase
<python.list@tim.thechases.com> wrote:
> Agreed that it's pretty awesome.  It seems to have some holes though:
>
> Python 3.4.2 (default, Oct  8 2014, 10:45:20)
> [GCC 4.9.1] on linux
> Type "help", "copyright", "credits" or "license" for more information.
>>>> print('\N{VULGAR FRACTION ONE EIGHTH}')
> ⅛
>>>> print(float('\N{VULGAR FRACTION ONE EIGHTH}'))
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError: could not convert string to float: '⅛'
>>>> print('\N{ROMAN NUMERAL NINE}')
> Ⅸ
>>>> int('\N{ROMAN NUMERAL NINE}')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError: invalid literal for int() with base 10: 'Ⅸ'
>>>> print('\N{ROMAN NUMERAL TEN THOUSAND}')
> ↂ
>>>> int('\N{ROMAN NUMERAL TEN THOUSAND}')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError: invalid literal for int() with base 10: 'ↂ'

The int() and float() functions accept, if I'm not mistaken, anything
with Unicode category "Nd" (Number, decimal digit). In your examples,
the fraction (U+215B) is No, and the Roman numerals (U+2168, U+2182)
are Nl, so they're not supported. Adding support for these forms might
be accepted as a feature request, but it's not a bug.

(I may be wrong about the definition being based on category. It may
be based on the "Numeric type" of each character. But again, the
characters that are accepted would be those which have a Digit type,
not merely Numeric, and again, it'd be a feature request to expand
that.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#94158 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On 2015-07-20 04:07, Chris Angelico wrote:
> The int() and float() functions accept, if I'm not mistaken,
> anything with Unicode category "Nd" (Number, decimal digit). In
> your examples, the fraction (U+215B) is No, and the Roman numerals
> (U+2168, U+2182) are Nl, so they're not supported. Adding support
> for these forms might be accepted as a feature request, but it's
> not a bug.

Ah, that makes sense.  Some simple testing (thanks, unicodedata
module) supports your conjecture.

It's not a particularly big deal so not really worth the brain-cycles
to add support for them.  Just upon hearing "Python's int() does
smart things with Unicode characters", those were some of my first
characters to try.  The failure struck me as odd until you explained
the simple difference.

-tkc

[toc] | [prev] | [next] | [standalone]

#94164 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Mon, Jul 20, 2015 at 5:55 AM, Tim Chase
<python.list@tim.thechases.com> wrote:
> On 2015-07-20 04:07, Chris Angelico wrote:
>> The int() and float() functions accept, if I'm not mistaken,
>> anything with Unicode category "Nd" (Number, decimal digit). In
>> your examples, the fraction (U+215B) is No, and the Roman numerals
>> (U+2168, U+2182) are Nl, so they're not supported. Adding support
>> for these forms might be accepted as a feature request, but it's
>> not a bug.
>
> Ah, that makes sense.  Some simple testing (thanks, unicodedata
> module) supports your conjecture.
>
> It's not a particularly big deal so not really worth the brain-cycles
> to add support for them.  Just upon hearing "Python's int() does
> smart things with Unicode characters", those were some of my first
> characters to try.  The failure struck me as odd until you explained
> the simple difference.

The other part of the problem is: What should float("2⅛3") be? Should
it be equal to 21.0/83.0? Should the first part be parsed as a classic
mixed number (2 + 1/8), and then what should the 3 mean? While it's
easy to see what an individual character should represent (just check
unicodedata.numeric(ch) - for ⅛ it's 0.125), the true meaning of a
string of such characters is less than clear. Similarly, Roman
numerals aren't meant to be used after the decimal point, so "Ⅸ.Ⅴ"
does not normally mean nine and a half... not to mention the confusing
situation that "ⅠⅤ" would naively parse as 15 but "Ⅳ" is definitely 4.
Since these kinds of complexities exist, it's safest to reserve this
level of parsing for a special-purpose function. If someone can come
up with a really strong argument for the float() and int()
constructors interpreting these, I'd expect to see it deployed as a
third-party module first, before being pointed out as "see, you can
use float() for all these, but if you want to use those, you should
use Float() instead". (Incidentally, I fully expect to see, some day,
pytz.localize() semantics brought into the standard library
datetime.datetime class, for precisely this reason.)

Unicode is awesome, but it's not a panacea :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#94222 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

Le dimanche 19 juillet 2015 23:17:16 UTC+2, Chris Angelico a écrit :
> 
> Unicode is awesome, but it's not a panacea :)
> 

It is not because Unicode proposes something, that
this something should be used or has to be used.
But it is good that everything Unicode proposes can
be used.

Unicode implies a new way of thinking.

jmf

[toc] | [prev] | [next] | [standalone]

#94167 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On 2015-07-19 22:16, Chris Angelico wrote:
> On Mon, Jul 20, 2015 at 5:55 AM, Tim Chase
> <python.list@tim.thechases.com> wrote:
>> On 2015-07-20 04:07, Chris Angelico wrote:
>>> The int() and float() functions accept, if I'm not mistaken,
>>> anything with Unicode category "Nd" (Number, decimal digit). In
>>> your examples, the fraction (U+215B) is No, and the Roman numerals
>>> (U+2168, U+2182) are Nl, so they're not supported. Adding support
>>> for these forms might be accepted as a feature request, but it's
>>> not a bug.
>>
>> Ah, that makes sense.  Some simple testing (thanks, unicodedata
>> module) supports your conjecture.
>>
>> It's not a particularly big deal so not really worth the brain-cycles
>> to add support for them.  Just upon hearing "Python's int() does
>> smart things with Unicode characters", those were some of my first
>> characters to try.  The failure struck me as odd until you explained
>> the simple difference.
>
> The other part of the problem is: What should float("2⅛3") be? Should
> it be equal to 21.0/83.0? Should the first part be parsed as a classic
> mixed number (2 + 1/8), and then what should the 3 mean? While it's
> easy to see what an individual character should represent (just check
> unicodedata.numeric(ch) - for ⅛ it's 0.125), the true meaning of a
> string of such characters is less than clear. Similarly, Roman
> numerals aren't meant to be used after the decimal point, so "Ⅸ.Ⅴ"
> does not normally mean nine and a half... not to mention the confusing
> situation that "ⅠⅤ" would naively parse as 15 but "Ⅳ" is definitely 4.
> Since these kinds of complexities exist, it's safest to reserve this
> level of parsing for a special-purpose function. If someone can come
> up with a really strong argument for the float() and int()
> constructors interpreting these, I'd expect to see it deployed as a
> third-party module first, before being pointed out as "see, you can
> use float() for all these, but if you want to use those, you should
> use Float() instead". (Incidentally, I fully expect to see, some day,
> pytz.localize() semantics brought into the standard library
> datetime.datetime class, for precisely this reason.)
>
> Unicode is awesome, but it's not a panacea :)
>
What's the result of, say, float('1e.3')?

It raises an exception.

So float("2⅛3") should also raise an exception.

[toc] | [prev] | [next] | [standalone]

#94260 — Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]

On Sunday, July 19, 2015 at 10:15:37 AM UTC+5:30, Steven D'Aprano wrote:
> > JFTR: My kids (um... students) have just managed to add devanagari
> > numerals to python.
> > ie we can now do
> > 
> >>>> १ + २
> > 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 १ + २ prints as 3 rather than ३.

BTW my boys have just mailed me their latest:

>>> 九.九九
                                                                            
9.99

Can some unicode/Chinese literate person inform me whether
that ideograph is equivalent to roman '9' or roman 'nine'?

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web