Is anyone going to mark the PEP as accepted? On Thu, May 12, 2016 at 8:11 AM, Guido van Rossum <gvanros...@gmail.com> 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" <g.bra...@gmx.net> 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 <br...@python.org > > <mailto:br...@python.org>> 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 <gu...@python.org > > <mailto:gu...@python.org>> wrote: > > > > All that sounds fine! > > > > On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah < > ste...@bytereef.org > > <mailto:ste...@bytereef.org>> wrote: > > > Guido van Rossum <guido <at> python.org <http://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 <mailto: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 <http://python.org/~guido > >) > > _______________________________________________ > > Python-Dev mailing list > > Python-Dev@python.org <mailto: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 <http://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