Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

[Brett Cannon]

Marked as accepted in https://hg.python.org/peps/rev/a52066565cc2

On Thu, 12 May 2016 at 16:59 Guido van Rossum  wrote:

> Is anyone going to mark the PEP as accepted?
>
> On Thu, May 12, 2016 at 8:11 AM, Guido van Rossum 
> wrote:
>
>> OK, then PEP 515 is now officially accepted! Congratulations. Start the
>> implementation work!
>>
>> --Guido (mobile)
>> On May 11, 2016 10:33 PM, "Georg Brandl"  wrote:
>>
>> I'm happy with the latest version.
>>
>> Georg
>>
>> On 05/11/2016 06:46 PM, Guido van Rossum wrote:
>> > If the authors are happy I'll accept it right away.
>> >
>> > (I vaguely recall there's another PEP that's ready for pronouncement --
>> but
>> > which one?)
>> >
>> > On Wed, May 11, 2016 at 9:34 AM, Brett Cannon > > > wrote:
>> >
>> > Is there anything holding up PEP 515 at this point in terms of
>> acceptance or
>> > implementation?
>> >
>> > On Sat, 19 Mar 2016 at 11:56 Guido van Rossum > > > wrote:
>> >
>> > All that sounds fine!
>> >
>> > On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah <
>> ste...@bytereef.org
>> > > wrote:
>> > > Guido van Rossum  python.org >
>> writes:
>> > >> So should the preprocessing step just be s.replace('_', ''),
>> or should
>> > >> it reject underscores that don't follow the rules from the
>> PEP
>> > >> (perhaps augmented so they follow the spirit of the PEP and
>> the letter
>> > >> of the IBM spec)?
>> > >>
>> > >> Honestly I think it's also fine if specifying this exactly
>> is left out
>> > >> of the PEP, and handled by whoever adds this to Decimal.
>> Having a PEP
>> > >> to work from for the language spec and core builtins (int(),
>> float()
>> > >> complex()) is more important.
>> > >
>> > > I'd keep it simple for Decimal: Remove left and right
>> whitespace (we're
>> > > already doing this), then remove underscores from the
>> remaining string
>> > > (which must not contain any further whitespace), then use the
>> IBM grammar.
>> > >
>> > >
>> > > We could add a clause to the PEP that only those strings that
>> follow
>> > > the spirit of the PEP are guaranteed to be accepted in the
>> future.
>> > >
>> > >
>> > > One reason for keeping it simple is that I would not like to
>> slow down
>> > > string conversion, but thinking about two grammars is also a
>> problem --
>> > > part of the string conversion in libmpdec is modeled in ACL2,
>> which
>> > > would be invalidated or at least complicated with two
>> grammars.
>> > >
>> > >
>> > >
>> > > Stefan Krah
>> > >
>> > > ___
>> > > 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/guido%40python.org
>> >
>> >
>> >
>> > --
>> > --Guido van Rossum (python.org/~guido > >)
>> > ___
>> > 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/brett%40python.org
>> >
>> >
>> >
>> >
>> > --
>> > --Guido van Rossum (python.org/~guido )
>> >
>> >
>>
>>
>> ___
>> 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/guido%40python.org
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> 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/brett%40python.org
>
___
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 515: Underscores in Numeric Literals (revision 3)

[Guido van Rossum]

Is anyone going to mark the PEP as accepted?

On Thu, May 12, 2016 at 8:11 AM, Guido van Rossum 
wrote:

> OK, then PEP 515 is now officially accepted! Congratulations. Start the
> implementation work!
>
> --Guido (mobile)
> On May 11, 2016 10:33 PM, "Georg Brandl"  wrote:
>
> I'm happy with the latest version.
>
> Georg
>
> On 05/11/2016 06:46 PM, Guido van Rossum wrote:
> > If the authors are happy I'll accept it right away.
> >
> > (I vaguely recall there's another PEP that's ready for pronouncement --
> but
> > which one?)
> >
> > On Wed, May 11, 2016 at 9:34 AM, Brett Cannon  > > wrote:
> >
> > Is there anything holding up PEP 515 at this point in terms of
> acceptance or
> > implementation?
> >
> > On Sat, 19 Mar 2016 at 11:56 Guido van Rossum  > > wrote:
> >
> > All that sounds fine!
> >
> > On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah <
> ste...@bytereef.org
> > > wrote:
> > > Guido van Rossum  python.org >
> writes:
> > >> So should the preprocessing step just be s.replace('_', ''),
> or should
> > >> it reject underscores that don't follow the rules from the PEP
> > >> (perhaps augmented so they follow the spirit of the PEP and
> the letter
> > >> of the IBM spec)?
> > >>
> > >> Honestly I think it's also fine if specifying this exactly is
> left out
> > >> of the PEP, and handled by whoever adds this to Decimal.
> Having a PEP
> > >> to work from for the language spec and core builtins (int(),
> float()
> > >> complex()) is more important.
> > >
> > > I'd keep it simple for Decimal: Remove left and right
> whitespace (we're
> > > already doing this), then remove underscores from the
> remaining string
> > > (which must not contain any further whitespace), then use the
> IBM grammar.
> > >
> > >
> > > We could add a clause to the PEP that only those strings that
> follow
> > > the spirit of the PEP are guaranteed to be accepted in the
> future.
> > >
> > >
> > > One reason for keeping it simple is that I would not like to
> slow down
> > > string conversion, but thinking about two grammars is also a
> problem --
> > > part of the string conversion in libmpdec is modeled in ACL2,
> which
> > > would be invalidated or at least complicated with two grammars.
> > >
> > >
> > >
> > > Stefan Krah
> > >
> > > ___
> > > 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/guido%40python.org
> >
> >
> >
> > --
> > --Guido van Rossum (python.org/~guido  >)
> > ___
> > 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/brett%40python.org
> >
> >
> >
> >
> > --
> > --Guido van Rossum (python.org/~guido )
> >
> >
>
>
> ___
> 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/guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
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 515: Underscores in Numeric Literals (revision 3)

[Guido van Rossum]

OK, then PEP 515 is now officially accepted! Congratulations. Start the
implementation work!

--Guido (mobile)
On May 11, 2016 10:33 PM, "Georg Brandl"  wrote:

I'm happy with the latest version.

Georg

On 05/11/2016 06:46 PM, Guido van Rossum wrote:
> If the authors are happy I'll accept it right away.
>
> (I vaguely recall there's another PEP that's ready for pronouncement --
but
> which one?)
>
> On Wed, May 11, 2016 at 9:34 AM, Brett Cannon  > wrote:
>
> Is there anything holding up PEP 515 at this point in terms of
acceptance or
> implementation?
>
> On Sat, 19 Mar 2016 at 11:56 Guido van Rossum  > wrote:
>
> All that sounds fine!
>
> On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah  > wrote:
> > Guido van Rossum  python.org >
writes:
> >> So should the preprocessing step just be s.replace('_', ''),
or should
> >> it reject underscores that don't follow the rules from the PEP
> >> (perhaps augmented so they follow the spirit of the PEP and
the letter
> >> of the IBM spec)?
> >>
> >> Honestly I think it's also fine if specifying this exactly is
left out
> >> of the PEP, and handled by whoever adds this to Decimal.
Having a PEP
> >> to work from for the language spec and core builtins (int(),
float()
> >> complex()) is more important.
> >
> > I'd keep it simple for Decimal: Remove left and right
whitespace (we're
> > already doing this), then remove underscores from the remaining
string
> > (which must not contain any further whitespace), then use the
IBM grammar.
> >
> >
> > We could add a clause to the PEP that only those strings that
follow
> > the spirit of the PEP are guaranteed to be accepted in the
future.
> >
> >
> > One reason for keeping it simple is that I would not like to
slow down
> > string conversion, but thinking about two grammars is also a
problem --
> > part of the string conversion in libmpdec is modeled in ACL2,
which
> > would be invalidated or at least complicated with two grammars.
> >
> >
> >
> > Stefan Krah
> >
> > ___
> > 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/guido%40python.org
>
>
>
> --
> --Guido van Rossum (python.org/~guido )
> ___
> 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/brett%40python.org
>
>
>
>
> --
> --Guido van Rossum (python.org/~guido )
>
>


___
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/guido%40python.org
___
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 515: Underscores in Numeric Literals (revision 3)

[Georg Brandl]

I'm happy with the latest version.

Georg

On 05/11/2016 06:46 PM, Guido van Rossum wrote:
> If the authors are happy I'll accept it right away.
> 
> (I vaguely recall there's another PEP that's ready for pronouncement -- but
> which one?)
> 
> On Wed, May 11, 2016 at 9:34 AM, Brett Cannon  > wrote:
> 
> Is there anything holding up PEP 515 at this point in terms of acceptance 
> or
> implementation?
> 
> On Sat, 19 Mar 2016 at 11:56 Guido van Rossum  > wrote:
> 
> All that sounds fine!
> 
> On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah  > wrote:
> > Guido van Rossum  python.org > writes:
> >> So should the preprocessing step just be s.replace('_', ''), or 
> should
> >> it reject underscores that don't follow the rules from the PEP
> >> (perhaps augmented so they follow the spirit of the PEP and the 
> letter
> >> of the IBM spec)?
> >>
> >> Honestly I think it's also fine if specifying this exactly is left 
> out
> >> of the PEP, and handled by whoever adds this to Decimal. Having a 
> PEP
> >> to work from for the language spec and core builtins (int(), 
> float()
> >> complex()) is more important.
> >
> > I'd keep it simple for Decimal: Remove left and right whitespace 
> (we're
> > already doing this), then remove underscores from the remaining 
> string
> > (which must not contain any further whitespace), then use the IBM 
> grammar.
> >
> >
> > We could add a clause to the PEP that only those strings that follow
> > the spirit of the PEP are guaranteed to be accepted in the future.
> >
> >
> > One reason for keeping it simple is that I would not like to slow 
> down
> > string conversion, but thinking about two grammars is also a 
> problem --
> > part of the string conversion in libmpdec is modeled in ACL2, which
> > would be invalidated or at least complicated with two grammars.
> >
> >
> >
> > Stefan Krah
> >
> > ___
> > 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/guido%40python.org
> 
> 
> 
> --
> --Guido van Rossum (python.org/~guido )
> ___
> 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/brett%40python.org
> 
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido )
> 
> 


___
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 515: Underscores in Numeric Literals (revision 3)

[Brett Cannon]

On Wed, 11 May 2016 at 10:49 Guido van Rossum  wrote:

> On Wed, May 11, 2016 at 10:28 AM, Brett Cannon  wrote:
>
>>
>>
>> On Wed, 11 May 2016 at 09:47 Guido van Rossum  wrote:
>>
>>> If the authors are happy I'll accept it right away.
>>>
>>> (I vaguely recall there's another PEP that's ready for pronouncement --
>>> but which one?)
>>>
>>
>> PEP 509 is the only one I can think of.
>>
>
> That's in limbo pending conclusive proof (through benchmarks) that at
> least one of Yury's patches that depends on it makes a big enough
> difference.
>
> Which IIUC itself is in limbo pending the wordcode changes (we're doing
> that right?).
>

Yes. Last I checked the author of the patch was waiting on a review from
Serhiy.

-Brett


>
> --
> --Guido van Rossum (python.org/~guido)
>
___
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 515: Underscores in Numeric Literals (revision 3)

[Guido van Rossum]

On Wed, May 11, 2016 at 10:28 AM, Brett Cannon  wrote:

>
>
> On Wed, 11 May 2016 at 09:47 Guido van Rossum  wrote:
>
>> If the authors are happy I'll accept it right away.
>>
>> (I vaguely recall there's another PEP that's ready for pronouncement --
>> but which one?)
>>
>
> PEP 509 is the only one I can think of.
>

That's in limbo pending conclusive proof (through benchmarks) that at least
one of Yury's patches that depends on it makes a big enough difference.

Which IIUC itself is in limbo pending the wordcode changes (we're doing
that right?).

-- 
--Guido van Rossum (python.org/~guido)
___
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 515: Underscores in Numeric Literals (revision 3)

[Brett Cannon]

On Wed, 11 May 2016 at 09:47 Guido van Rossum  wrote:

> If the authors are happy I'll accept it right away.
>
> (I vaguely recall there's another PEP that's ready for pronouncement --
> but which one?)
>

PEP 509 is the only one I can think of.

-Brett


>
> On Wed, May 11, 2016 at 9:34 AM, Brett Cannon  wrote:
>
>> Is there anything holding up PEP 515 at this point in terms of acceptance
>> or implementation?
>>
>> On Sat, 19 Mar 2016 at 11:56 Guido van Rossum  wrote:
>>
>>> All that sounds fine!
>>>
>>> On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah 
>>> wrote:
>>> > Guido van Rossum  python.org> writes:
>>> >> So should the preprocessing step just be s.replace('_', ''), or should
>>> >> it reject underscores that don't follow the rules from the PEP
>>> >> (perhaps augmented so they follow the spirit of the PEP and the letter
>>> >> of the IBM spec)?
>>> >>
>>> >> Honestly I think it's also fine if specifying this exactly is left out
>>> >> of the PEP, and handled by whoever adds this to Decimal. Having a PEP
>>> >> to work from for the language spec and core builtins (int(), float()
>>> >> complex()) is more important.
>>> >
>>> > I'd keep it simple for Decimal: Remove left and right whitespace (we're
>>> > already doing this), then remove underscores from the remaining string
>>> > (which must not contain any further whitespace), then use the IBM
>>> grammar.
>>> >
>>> >
>>> > We could add a clause to the PEP that only those strings that follow
>>> > the spirit of the PEP are guaranteed to be accepted in the future.
>>> >
>>> >
>>> > One reason for keeping it simple is that I would not like to slow down
>>> > string conversion, but thinking about two grammars is also a problem --
>>> > part of the string conversion in libmpdec is modeled in ACL2, which
>>> > would be invalidated or at least complicated with two grammars.
>>> >
>>> >
>>> >
>>> > Stefan Krah
>>> >
>>> > ___
>>> > 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/guido%40python.org
>>>
>>>
>>>
>>> --
>>> --Guido van Rossum (python.org/~guido)
>>> ___
>>> 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/brett%40python.org
>>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
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 515: Underscores in Numeric Literals (revision 3)

[Guido van Rossum]

If the authors are happy I'll accept it right away.

(I vaguely recall there's another PEP that's ready for pronouncement -- but
which one?)

On Wed, May 11, 2016 at 9:34 AM, Brett Cannon  wrote:

> Is there anything holding up PEP 515 at this point in terms of acceptance
> or implementation?
>
> On Sat, 19 Mar 2016 at 11:56 Guido van Rossum  wrote:
>
>> All that sounds fine!
>>
>> On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah 
>> wrote:
>> > Guido van Rossum  python.org> writes:
>> >> So should the preprocessing step just be s.replace('_', ''), or should
>> >> it reject underscores that don't follow the rules from the PEP
>> >> (perhaps augmented so they follow the spirit of the PEP and the letter
>> >> of the IBM spec)?
>> >>
>> >> Honestly I think it's also fine if specifying this exactly is left out
>> >> of the PEP, and handled by whoever adds this to Decimal. Having a PEP
>> >> to work from for the language spec and core builtins (int(), float()
>> >> complex()) is more important.
>> >
>> > I'd keep it simple for Decimal: Remove left and right whitespace (we're
>> > already doing this), then remove underscores from the remaining string
>> > (which must not contain any further whitespace), then use the IBM
>> grammar.
>> >
>> >
>> > We could add a clause to the PEP that only those strings that follow
>> > the spirit of the PEP are guaranteed to be accepted in the future.
>> >
>> >
>> > One reason for keeping it simple is that I would not like to slow down
>> > string conversion, but thinking about two grammars is also a problem --
>> > part of the string conversion in libmpdec is modeled in ACL2, which
>> > would be invalidated or at least complicated with two grammars.
>> >
>> >
>> >
>> > Stefan Krah
>> >
>> > ___
>> > 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/guido%40python.org
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> ___
>> 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/brett%40python.org
>>
>


-- 
--Guido van Rossum (python.org/~guido)
___
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 515: Underscores in Numeric Literals (revision 3)

[Brett Cannon]

Is there anything holding up PEP 515 at this point in terms of acceptance
or implementation?

On Sat, 19 Mar 2016 at 11:56 Guido van Rossum  wrote:

> All that sounds fine!
>
> On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah  wrote:
> > Guido van Rossum  python.org> writes:
> >> So should the preprocessing step just be s.replace('_', ''), or should
> >> it reject underscores that don't follow the rules from the PEP
> >> (perhaps augmented so they follow the spirit of the PEP and the letter
> >> of the IBM spec)?
> >>
> >> Honestly I think it's also fine if specifying this exactly is left out
> >> of the PEP, and handled by whoever adds this to Decimal. Having a PEP
> >> to work from for the language spec and core builtins (int(), float()
> >> complex()) is more important.
> >
> > I'd keep it simple for Decimal: Remove left and right whitespace (we're
> > already doing this), then remove underscores from the remaining string
> > (which must not contain any further whitespace), then use the IBM
> grammar.
> >
> >
> > We could add a clause to the PEP that only those strings that follow
> > the spirit of the PEP are guaranteed to be accepted in the future.
> >
> >
> > One reason for keeping it simple is that I would not like to slow down
> > string conversion, but thinking about two grammars is also a problem --
> > part of the string conversion in libmpdec is modeled in ACL2, which
> > would be invalidated or at least complicated with two grammars.
> >
> >
> >
> > Stefan Krah
> >
> > ___
> > 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/guido%40python.org
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> 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/brett%40python.org
>
___
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 515: Underscores in Numeric Literals (revision 3)

[Guido van Rossum]

All that sounds fine!

On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah  wrote:
> Guido van Rossum  python.org> writes:
>> So should the preprocessing step just be s.replace('_', ''), or should
>> it reject underscores that don't follow the rules from the PEP
>> (perhaps augmented so they follow the spirit of the PEP and the letter
>> of the IBM spec)?
>>
>> Honestly I think it's also fine if specifying this exactly is left out
>> of the PEP, and handled by whoever adds this to Decimal. Having a PEP
>> to work from for the language spec and core builtins (int(), float()
>> complex()) is more important.
>
> I'd keep it simple for Decimal: Remove left and right whitespace (we're
> already doing this), then remove underscores from the remaining string
> (which must not contain any further whitespace), then use the IBM grammar.
>
>
> We could add a clause to the PEP that only those strings that follow
> the spirit of the PEP are guaranteed to be accepted in the future.
>
>
> One reason for keeping it simple is that I would not like to slow down
> string conversion, but thinking about two grammars is also a problem --
> part of the string conversion in libmpdec is modeled in ACL2, which
> would be invalidated or at least complicated with two grammars.
>
>
>
> Stefan Krah
>
> ___
> 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/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
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 515: Underscores in Numeric Literals (revision 3)

[Stefan Krah]

Guido van Rossum  python.org> writes:
> So should the preprocessing step just be s.replace('_', ''), or should
> it reject underscores that don't follow the rules from the PEP
> (perhaps augmented so they follow the spirit of the PEP and the letter
> of the IBM spec)?
> 
> Honestly I think it's also fine if specifying this exactly is left out
> of the PEP, and handled by whoever adds this to Decimal. Having a PEP
> to work from for the language spec and core builtins (int(), float()
> complex()) is more important.

I'd keep it simple for Decimal: Remove left and right whitespace (we're
already doing this), then remove underscores from the remaining string
(which must not contain any further whitespace), then use the IBM grammar.


We could add a clause to the PEP that only those strings that follow
the spirit of the PEP are guaranteed to be accepted in the future.


One reason for keeping it simple is that I would not like to slow down
string conversion, but thinking about two grammars is also a problem --
part of the string conversion in libmpdec is modeled in ACL2, which
would be invalidated or at least complicated with two grammars.



Stefan Krah

___
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 515: Underscores in Numeric Literals (revision 3)

[Guido van Rossum]

So should the preprocessing step just be s.replace('_', ''), or should
it reject underscores that don't follow the rules from the PEP
(perhaps augmented so they follow the spirit of the PEP and the letter
of the IBM spec)?

Honestly I think it's also fine if specifying this exactly is left out
of the PEP, and handled by whoever adds this to Decimal. Having a PEP
to work from for the language spec and core builtins (int(), float()
complex()) is more important.

On Sat, Mar 19, 2016 at 10:24 AM, Stefan Krah  wrote:
>
> Guido van Rossum  python.org> writes:
>> I don't care too much either way, but I think passing underscores to the
> constructor shouldn't be affected by the context -- the underscores are just
> removed before parsing the number. But if it's too complicated to implement
> I'm fine with punting.
>
> Just removing the underscores would be fine. The problem is that per
> the PEP the conversion should happen according the Python float grammar
> but the actual decimal grammar is the one from the IBM specification.
>
> I'd much rather express the problem like you did above: A preprocessing
> step followed by the IBM specification grammar.
>
>
>
> Stefan Krah
>
>
>
>
>
>
> ___
> 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/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
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 515: Underscores in Numeric Literals (revision 3)

[Stefan Krah]

Guido van Rossum  python.org> writes:
> I don't care too much either way, but I think passing underscores to the
constructor shouldn't be affected by the context -- the underscores are just
removed before parsing the number. But if it's too complicated to implement
I'm fine with punting.

Just removing the underscores would be fine. The problem is that per
the PEP the conversion should happen according the Python float grammar 
but the actual decimal grammar is the one from the IBM specification.

I'd much rather express the problem like you did above: A preprocessing
step followed by the IBM specification grammar.



Stefan Krah






___
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 515: Underscores in Numeric Literals (revision 3)

[Guido van Rossum]

I don't care too much either way, but I think passing underscores to the
constructor shouldn't be affected by the context -- the underscores are
just removed before parsing the number. But if it's too complicated to
implement I'm fine with punting.

--Guido (mobile)
On Mar 19, 2016 6:24 AM, "Nick Coghlan"  wrote:

> On 19 March 2016 at 16:44, Georg Brandl  wrote:
> > On the other hand, assuming decimal literals are introduced at some
> > point, they would almost definitely need to support underscores.
> > Of course, the decision whether to modify the Decimal constructor
> > can be postponed until that time.
>
> The idea of Decimal literals is complicated significantly by their
> current context dependent behaviour (especially when it comes to
> rounding), so I'd suggest leaving them alone in the context of this
> PEP.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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/guido%40python.org
>
___
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 515: Underscores in Numeric Literals (revision 3)

[Nick Coghlan]

On 19 March 2016 at 16:44, Georg Brandl  wrote:
> On the other hand, assuming decimal literals are introduced at some
> point, they would almost definitely need to support underscores.
> Of course, the decision whether to modify the Decimal constructor
> can be postponed until that time.

The idea of Decimal literals is complicated significantly by their
current context dependent behaviour (especially when it comes to
rounding), so I'd suggest leaving them alone in the context of this
PEP.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 515: Underscores in Numeric Literals (revision 3)

[Brett Cannon]

Where did this PEP leave off? Anything blocking its acceptance?

On Sat, 13 Feb 2016 at 00:49 Georg Brandl  wrote:

> Hi all,
>
> after talking to Guido and Serhiy we present the next revision
> of this PEP.  It is a compromise that we are all happy with,
> and a relatively restricted rule that makes additions to PEP 8
> basically unnecessary.
>
> I think the discussion has shown that supporting underscores in
> the from-string constructors is valuable, therefore this is now
> added to the specification section.
>
> The remaining open question is about the reverse direction: do
> we want a string formatting modifier that adds underscores as
> thousands separators?
>
> cheers,
> Georg
>
> -
>
> PEP: 515
> Title: Underscores in Numeric Literals
> Version: $Revision$
> Last-Modified: $Date$
> Author: Georg Brandl, Serhiy Storchaka
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 10-Feb-2016
> Python-Version: 3.6
> Post-History: 10-Feb-2016, 11-Feb-2016
>
> Abstract and Rationale
> ==
>
> This PEP proposes to extend Python's syntax and number-from-string
> constructors so that underscores can be used as visual separators for
> digit grouping purposes in integral, floating-point and complex number
> literals.
>
> This is a common feature of other modern languages, and can aid
> readability of long literals, or literals whose value should clearly
> separate into parts, such as bytes or words in hexadecimal notation.
>
> Examples::
>
> # grouping decimal numbers by thousands
> amount = 10_000_000.0
>
> # grouping hexadecimal addresses by words
> addr = 0xDEAD_BEEF
>
> # grouping bits into nibbles in a binary literal
> flags = 0b_0011__0100_1110
>
> # same, for string conversions
> flags = int('0b__', 2)
>
>
> Specification
> =
>
> The current proposal is to allow one underscore between digits, and
> after base specifiers in numeric literals.  The underscores have no
> semantic meaning, and literals are parsed as if the underscores were
> absent.
>
> Literal Grammar
> ---
>
> The production list for integer literals would therefore look like
> this::
>
>integer: decinteger | bininteger | octinteger | hexinteger
>decinteger: nonzerodigit (["_"] digit)* | "0" (["_"] "0")*
>bininteger: "0" ("b" | "B") (["_"] bindigit)+
>octinteger: "0" ("o" | "O") (["_"] octdigit)+
>hexinteger: "0" ("x" | "X") (["_"] hexdigit)+
>nonzerodigit: "1"..."9"
>digit: "0"..."9"
>bindigit: "0" | "1"
>octdigit: "0"..."7"
>hexdigit: digit | "a"..."f" | "A"..."F"
>
> For floating-point and complex literals::
>
>floatnumber: pointfloat | exponentfloat
>pointfloat: [digitpart] fraction | digitpart "."
>exponentfloat: (digitpart | pointfloat) exponent
>digitpart: digit (["_"] digit)*
>fraction: "." digitpart
>exponent: ("e" | "E") ["+" | "-"] digitpart
>imagnumber: (floatnumber | digitpart) ("j" | "J")
>
> Constructors
> 
>
> Following the same rules for placement, underscores will be allowed in
> the following constructors:
>
> - ``int()`` (with any base)
> - ``float()``
> - ``complex()``
> - ``Decimal()``
>
>
> Prior Art
> =
>
> Those languages that do allow underscore grouping implement a large
> variety of rules for allowed placement of underscores.  In cases where
> the language spec contradicts the actual behavior, the actual behavior
> is listed.  ("single" or "multiple" refer to allowing runs of
> consecutive underscores.)
>
> * Ada: single, only between digits [8]_
> * C# (open proposal for 7.0): multiple, only between digits [6]_
> * C++14: single, between digits (different separator chosen) [1]_
> * D: multiple, anywhere, including trailing [2]_
> * Java: multiple, only between digits [7]_
> * Julia: single, only between digits (but not in float exponent parts)
>   [9]_
> * Perl 5: multiple, basically anywhere, although docs say it's
>   restricted to one underscore between digits [3]_
> * Ruby: single, only between digits (although docs say "anywhere")
>   [10]_
> * Rust: multiple, anywhere, except for between exponent "e" and digits
>   [4]_
> * Swift: multiple, between digits and trailing (although textual
>   description says only "between digits") [5]_
>
>
> Alternative Syntax
> ==
>
> Underscore Placement Rules
> --
>
> Instead of the relatively strict rule specified above, the use of
> underscores could be limited.  As we seen from other languages, common
> rules include:
>
> * Only one consecutive underscore allowed, and only between digits.
> * Multiple consecutive underscores allowed, but only between digits.
> * Multiple consecutive underscores allowed, in most positions except
>   for the start of the literal, or special positions like after a
>   decimal point.
>
> The syntax in this PEP has ultimately 

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

[Georg Brandl]

I'll update the text so that the format() gets promoted from optional
to specified.

There was one point of discussion in the tracker issue that should be
resolved before acceptance: the Decimal constructor is listed as
getting updated to allow underscores, but its syntax is specified
in the Decimal spec: http://speleotrove.com/decimal/daconvs.html

Acccepting underscores would be an extension to the spec, which may
not be what we want to do as otherwise Decimal follows that spec
closely.

On the other hand, assuming decimal literals are introduced at some
point, they would almost definitely need to support underscores.
Of course, the decision whether to modify the Decimal constructor
can be postponed until that time.

cheers,
Georg

On 03/19/2016 01:02 AM, Guido van Rossum wrote:
> I'm happy to accept this PEP as is stands, assuming the authors are
> ready for this news. I recommend also implementing the option from
> footnote [11] (extend the number-to-string formatting language to
> allow ``_`` as a thousans separator).
> 
> On Thu, Mar 17, 2016 at 11:19 AM, Brett Cannon  wrote:
>> Where did this PEP leave off? Anything blocking its acceptance?
>>
>> On Sat, 13 Feb 2016 at 00:49 Georg Brandl  wrote:
>>>
>>> Hi all,
>>>
>>> after talking to Guido and Serhiy we present the next revision
>>> of this PEP.  It is a compromise that we are all happy with,
>>> and a relatively restricted rule that makes additions to PEP 8
>>> basically unnecessary.
>>>
>>> I think the discussion has shown that supporting underscores in
>>> the from-string constructors is valuable, therefore this is now
>>> added to the specification section.
>>>
>>> The remaining open question is about the reverse direction: do
>>> we want a string formatting modifier that adds underscores as
>>> thousands separators?
>>>
>>> cheers,
>>> Georg
>>>
>>> -
>>>
>>> PEP: 515
>>> Title: Underscores in Numeric Literals
>>> Version: $Revision$
>>> Last-Modified: $Date$
>>> Author: Georg Brandl, Serhiy Storchaka
>>> Status: Draft
>>> Type: Standards Track
>>> Content-Type: text/x-rst
>>> Created: 10-Feb-2016
>>> Python-Version: 3.6
>>> Post-History: 10-Feb-2016, 11-Feb-2016
>>>
>>> Abstract and Rationale
>>> ==
>>>
>>> This PEP proposes to extend Python's syntax and number-from-string
>>> constructors so that underscores can be used as visual separators for
>>> digit grouping purposes in integral, floating-point and complex number
>>> literals.
>>>
>>> This is a common feature of other modern languages, and can aid
>>> readability of long literals, or literals whose value should clearly
>>> separate into parts, such as bytes or words in hexadecimal notation.
>>>
>>> Examples::
>>>
>>> # grouping decimal numbers by thousands
>>> amount = 10_000_000.0
>>>
>>> # grouping hexadecimal addresses by words
>>> addr = 0xDEAD_BEEF
>>>
>>> # grouping bits into nibbles in a binary literal
>>> flags = 0b_0011__0100_1110
>>>
>>> # same, for string conversions
>>> flags = int('0b__', 2)
>>>
>>>
>>> Specification
>>> =
>>>
>>> The current proposal is to allow one underscore between digits, and
>>> after base specifiers in numeric literals.  The underscores have no
>>> semantic meaning, and literals are parsed as if the underscores were
>>> absent.
>>>
>>> Literal Grammar
>>> ---
>>>
>>> The production list for integer literals would therefore look like
>>> this::
>>>
>>>integer: decinteger | bininteger | octinteger | hexinteger
>>>decinteger: nonzerodigit (["_"] digit)* | "0" (["_"] "0")*
>>>bininteger: "0" ("b" | "B") (["_"] bindigit)+
>>>octinteger: "0" ("o" | "O") (["_"] octdigit)+
>>>hexinteger: "0" ("x" | "X") (["_"] hexdigit)+
>>>nonzerodigit: "1"..."9"
>>>digit: "0"..."9"
>>>bindigit: "0" | "1"
>>>octdigit: "0"..."7"
>>>hexdigit: digit | "a"..."f" | "A"..."F"
>>>
>>> For floating-point and complex literals::
>>>
>>>floatnumber: pointfloat | exponentfloat
>>>pointfloat: [digitpart] fraction | digitpart "."
>>>exponentfloat: (digitpart | pointfloat) exponent
>>>digitpart: digit (["_"] digit)*
>>>fraction: "." digitpart
>>>exponent: ("e" | "E") ["+" | "-"] digitpart
>>>imagnumber: (floatnumber | digitpart) ("j" | "J")
>>>
>>> Constructors
>>> 
>>>
>>> Following the same rules for placement, underscores will be allowed in
>>> the following constructors:
>>>
>>> - ``int()`` (with any base)
>>> - ``float()``
>>> - ``complex()``
>>> - ``Decimal()``
>>>
>>>
>>> Prior Art
>>> =
>>>
>>> Those languages that do allow underscore grouping implement a large
>>> variety of rules for allowed placement of underscores.  In cases where
>>> the language spec contradicts the actual behavior, the actual behavior
>>> is listed.  ("single" or "multiple" refer to allowing runs of
>>> consecutive underscores.)
>>>

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

[Guido van Rossum]

I'm happy to accept this PEP as is stands, assuming the authors are
ready for this news. I recommend also implementing the option from
footnote [11] (extend the number-to-string formatting language to
allow ``_`` as a thousans separator).

On Thu, Mar 17, 2016 at 11:19 AM, Brett Cannon  wrote:
> Where did this PEP leave off? Anything blocking its acceptance?
>
> On Sat, 13 Feb 2016 at 00:49 Georg Brandl  wrote:
>>
>> Hi all,
>>
>> after talking to Guido and Serhiy we present the next revision
>> of this PEP.  It is a compromise that we are all happy with,
>> and a relatively restricted rule that makes additions to PEP 8
>> basically unnecessary.
>>
>> I think the discussion has shown that supporting underscores in
>> the from-string constructors is valuable, therefore this is now
>> added to the specification section.
>>
>> The remaining open question is about the reverse direction: do
>> we want a string formatting modifier that adds underscores as
>> thousands separators?
>>
>> cheers,
>> Georg
>>
>> -
>>
>> PEP: 515
>> Title: Underscores in Numeric Literals
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Georg Brandl, Serhiy Storchaka
>> Status: Draft
>> Type: Standards Track
>> Content-Type: text/x-rst
>> Created: 10-Feb-2016
>> Python-Version: 3.6
>> Post-History: 10-Feb-2016, 11-Feb-2016
>>
>> Abstract and Rationale
>> ==
>>
>> This PEP proposes to extend Python's syntax and number-from-string
>> constructors so that underscores can be used as visual separators for
>> digit grouping purposes in integral, floating-point and complex number
>> literals.
>>
>> This is a common feature of other modern languages, and can aid
>> readability of long literals, or literals whose value should clearly
>> separate into parts, such as bytes or words in hexadecimal notation.
>>
>> Examples::
>>
>> # grouping decimal numbers by thousands
>> amount = 10_000_000.0
>>
>> # grouping hexadecimal addresses by words
>> addr = 0xDEAD_BEEF
>>
>> # grouping bits into nibbles in a binary literal
>> flags = 0b_0011__0100_1110
>>
>> # same, for string conversions
>> flags = int('0b__', 2)
>>
>>
>> Specification
>> =
>>
>> The current proposal is to allow one underscore between digits, and
>> after base specifiers in numeric literals.  The underscores have no
>> semantic meaning, and literals are parsed as if the underscores were
>> absent.
>>
>> Literal Grammar
>> ---
>>
>> The production list for integer literals would therefore look like
>> this::
>>
>>integer: decinteger | bininteger | octinteger | hexinteger
>>decinteger: nonzerodigit (["_"] digit)* | "0" (["_"] "0")*
>>bininteger: "0" ("b" | "B") (["_"] bindigit)+
>>octinteger: "0" ("o" | "O") (["_"] octdigit)+
>>hexinteger: "0" ("x" | "X") (["_"] hexdigit)+
>>nonzerodigit: "1"..."9"
>>digit: "0"..."9"
>>bindigit: "0" | "1"
>>octdigit: "0"..."7"
>>hexdigit: digit | "a"..."f" | "A"..."F"
>>
>> For floating-point and complex literals::
>>
>>floatnumber: pointfloat | exponentfloat
>>pointfloat: [digitpart] fraction | digitpart "."
>>exponentfloat: (digitpart | pointfloat) exponent
>>digitpart: digit (["_"] digit)*
>>fraction: "." digitpart
>>exponent: ("e" | "E") ["+" | "-"] digitpart
>>imagnumber: (floatnumber | digitpart) ("j" | "J")
>>
>> Constructors
>> 
>>
>> Following the same rules for placement, underscores will be allowed in
>> the following constructors:
>>
>> - ``int()`` (with any base)
>> - ``float()``
>> - ``complex()``
>> - ``Decimal()``
>>
>>
>> Prior Art
>> =
>>
>> Those languages that do allow underscore grouping implement a large
>> variety of rules for allowed placement of underscores.  In cases where
>> the language spec contradicts the actual behavior, the actual behavior
>> is listed.  ("single" or "multiple" refer to allowing runs of
>> consecutive underscores.)
>>
>> * Ada: single, only between digits [8]_
>> * C# (open proposal for 7.0): multiple, only between digits [6]_
>> * C++14: single, between digits (different separator chosen) [1]_
>> * D: multiple, anywhere, including trailing [2]_
>> * Java: multiple, only between digits [7]_
>> * Julia: single, only between digits (but not in float exponent parts)
>>   [9]_
>> * Perl 5: multiple, basically anywhere, although docs say it's
>>   restricted to one underscore between digits [3]_
>> * Ruby: single, only between digits (although docs say "anywhere")
>>   [10]_
>> * Rust: multiple, anywhere, except for between exponent "e" and digits
>>   [4]_
>> * Swift: multiple, between digits and trailing (although textual
>>   description says only "between digits") [5]_
>>
>>
>> Alternative Syntax
>> ==
>>
>> Underscore Placement Rules
>> --
>>
>> Instead of the relatively strict rule 

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

[Serhiy Storchaka]

On 13.02.16 10:48, Georg Brandl wrote:

Following the same rules for placement, underscores will be allowed in
the following constructors:

- ``int()`` (with any base)
- ``float()``
- ``complex()``
- ``Decimal()``


What about float.fromhex()? Should underscores be allowed in it (I think 
no)?



___
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 515: Underscores in Numeric Literals (revision 3)

[Georg Brandl]

On 02/13/2016 12:10 PM, Serhiy Storchaka wrote:
> On 13.02.16 10:48, Georg Brandl wrote:
>> Following the same rules for placement, underscores will be allowed in
>> the following constructors:
>>
>> - ``int()`` (with any base)
>> - ``float()``
>> - ``complex()``
>> - ``Decimal()``
> 
> What about float.fromhex()? Should underscores be allowed in it (I think 
> no)?

Good question.  It *does* accept a "0x" prefix, as does ``int(x, 16)``, so
there is some precedent for literal-like interpretation of the input here
as well.

Georg


___
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 515: Underscores in Numeric Literals (revision 3)

[Steven D'Aprano]

On Sat, Feb 13, 2016 at 09:48:49AM +0100, Georg Brandl wrote:
> Hi all,
> 
> after talking to Guido and Serhiy we present the next revision
> of this PEP.  It is a compromise that we are all happy with,
> and a relatively restricted rule that makes additions to PEP 8
> basically unnecessary.
> 
> I think the discussion has shown that supporting underscores in
> the from-string constructors is valuable, therefore this is now
> added to the specification section.

What about Fraction? Currently this is legal:

py> Fraction("1/100")
Fraction(1, 100)


I think the PEP should also support underscores in Fractions:

Fraction("1/1_000_000")


> The remaining open question is about the reverse direction: do
> we want a string formatting modifier that adds underscores as
> thousands separators?

Yes please.


> Open Proposals
> ==
> 
> It has been proposed [11]_ to extend the number-to-string formatting
> language to allow ``_`` as a thousans separator, where currently only
> ``,`` is supported.  This could be used to easily generate code with
> more readable literals.

/s/thousans/thousands/



-- 
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 515: Underscores in Numeric Literals (revision 3)

[Glenn Linderman]

On 2/13/2016 12:48 AM, Georg Brandl wrote:

Instead of the relatively strict rule specified above, the use of
underscores could be limited.

This sentence doesn't really make sense.

Either s/limited/more limited/
or s/limited/further limited/
or s/limited/relaxed/

Maybe the whole section should be reworded.
___
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 515: Underscores in Numeric Literals (revision 3)

[Ethan Furman]

On 02/13/2016 12:48 AM, Georg Brandl wrote:


The remaining open question is about the reverse direction: do
we want a string formatting modifier that adds underscores as
thousands separators?


+0  Would be nice, but also wouldn't make much sense in other groupings.



Instead of the relatively strict rule specified above, the use of
underscores could be limited.  As we seen from other languages, common
rules include:


s/seen/see  or  s/we//

--
~Ethan~
___
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 515: Underscores in Numeric Literals (revision 3)

[Brett Cannon]

On Sat, Feb 13, 2016, 00:49 Georg Brandl  wrote:

> Hi all,
>
> after talking to Guido and Serhiy we present the next revision
> of this PEP.  It is a compromise that we are all happy with,
> and a relatively restricted rule that makes additions to PEP 8
> basically unnecessary.
>

+1 from me.


> I think the discussion has shown that supporting underscores in
> the from-string constructors is valuable, therefore this is now
> added to the specification section.
>
> The remaining open question is about the reverse direction: do
> we want a string formatting modifier that adds underscores as
> thousands separators?
>

+0

Brett


> cheers,
> Georg
>
> -
>
> PEP: 515
> Title: Underscores in Numeric Literals
> Version: $Revision$
> Last-Modified: $Date$
> Author: Georg Brandl, Serhiy Storchaka
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 10-Feb-2016
> Python-Version: 3.6
> Post-History: 10-Feb-2016, 11-Feb-2016
>
> Abstract and Rationale
> ==
>
> This PEP proposes to extend Python's syntax and number-from-string
> constructors so that underscores can be used as visual separators for
> digit grouping purposes in integral, floating-point and complex number
> literals.
>
> This is a common feature of other modern languages, and can aid
> readability of long literals, or literals whose value should clearly
> separate into parts, such as bytes or words in hexadecimal notation.
>
> Examples::
>
> # grouping decimal numbers by thousands
> amount = 10_000_000.0
>
> # grouping hexadecimal addresses by words
> addr = 0xDEAD_BEEF
>
> # grouping bits into nibbles in a binary literal
> flags = 0b_0011__0100_1110
>
> # same, for string conversions
> flags = int('0b__', 2)
>
>
> Specification
> =
>
> The current proposal is to allow one underscore between digits, and
> after base specifiers in numeric literals.  The underscores have no
> semantic meaning, and literals are parsed as if the underscores were
> absent.
>
> Literal Grammar
> ---
>
> The production list for integer literals would therefore look like
> this::
>
>integer: decinteger | bininteger | octinteger | hexinteger
>decinteger: nonzerodigit (["_"] digit)* | "0" (["_"] "0")*
>bininteger: "0" ("b" | "B") (["_"] bindigit)+
>octinteger: "0" ("o" | "O") (["_"] octdigit)+
>hexinteger: "0" ("x" | "X") (["_"] hexdigit)+
>nonzerodigit: "1"..."9"
>digit: "0"..."9"
>bindigit: "0" | "1"
>octdigit: "0"..."7"
>hexdigit: digit | "a"..."f" | "A"..."F"
>
> For floating-point and complex literals::
>
>floatnumber: pointfloat | exponentfloat
>pointfloat: [digitpart] fraction | digitpart "."
>exponentfloat: (digitpart | pointfloat) exponent
>digitpart: digit (["_"] digit)*
>fraction: "." digitpart
>exponent: ("e" | "E") ["+" | "-"] digitpart
>imagnumber: (floatnumber | digitpart) ("j" | "J")
>
> Constructors
> 
>
> Following the same rules for placement, underscores will be allowed in
> the following constructors:
>
> - ``int()`` (with any base)
> - ``float()``
> - ``complex()``
> - ``Decimal()``
>
>
> Prior Art
> =
>
> Those languages that do allow underscore grouping implement a large
> variety of rules for allowed placement of underscores.  In cases where
> the language spec contradicts the actual behavior, the actual behavior
> is listed.  ("single" or "multiple" refer to allowing runs of
> consecutive underscores.)
>
> * Ada: single, only between digits [8]_
> * C# (open proposal for 7.0): multiple, only between digits [6]_
> * C++14: single, between digits (different separator chosen) [1]_
> * D: multiple, anywhere, including trailing [2]_
> * Java: multiple, only between digits [7]_
> * Julia: single, only between digits (but not in float exponent parts)
>   [9]_
> * Perl 5: multiple, basically anywhere, although docs say it's
>   restricted to one underscore between digits [3]_
> * Ruby: single, only between digits (although docs say "anywhere")
>   [10]_
> * Rust: multiple, anywhere, except for between exponent "e" and digits
>   [4]_
> * Swift: multiple, between digits and trailing (although textual
>   description says only "between digits") [5]_
>
>
> Alternative Syntax
> ==
>
> Underscore Placement Rules
> --
>
> Instead of the relatively strict rule specified above, the use of
> underscores could be limited.  As we seen from other languages, common
> rules include:
>
> * Only one consecutive underscore allowed, and only between digits.
> * Multiple consecutive underscores allowed, but only between digits.
> * Multiple consecutive underscores allowed, in most positions except
>   for the start of the literal, or special positions like after a
>   decimal point.
>
> The syntax in this PEP has ultimately been selected because it covers
> the