Re: [Python-Dev] gcc 4.2 exposes signed integer overflows
Tim Peters [EMAIL PROTECTED] wrote: This is a wrong time in the release process to take on chance on discovering a flaky LONG_MIN on some box, so I want to keep the code as much as possible like what's already there (which worked fine for 10 years on all known boxes) for now. No, it didn't. I reported a bug a couple of years back. A blanket rule not to use symbols is clearly wrong, but there are good reasons not to want to rely on LONG_MIN (or INT_MIN for that matter). Because of some incredibly complex issues (which I only know some of), it hasn't been consistently -(1+LONG_MAX) on twos' complement machines. There are good reasons for making it -LONG_MAX, but they aren't the ones that actually cause it to be so. There are, however, very good reasons for using BOTH tests. I.e. if I have a C system which defines LONG_MIN to be -LONG_MAX because it uses -(1+LONG_MAX) for an integer NaN indicator in some contexts, you really DON'T want to create such a value. I don't know if there are any such C systems, but there have been other languages that did. I hope that Guido wasn't saying that Python should EVER rely on signed integer overflow wrapping in twos' complement. Despite the common usage, Java and all that, it is perhaps the worst systematic architectural change to have happened in 30 years, and accounts for a good 30% of all hard bugs in many classes of program. Simple buffer overflow is fairly easy to avoid by good programming style; integer overflow causing trashing of unpredictable data isn't. Any decent programming language (like Python!) regards integer overflow as an error, and the moves to make C copy Java semantics are yet another step away from software engineering in the direction of who-gives-a-damn hacking. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
Raymond Hettinger wrote: I would like to see the changes to the decimal module reverted for the Py2.5 release. I believe you may be overreacting - I don't consider the current behaviour buggy and the module level API can be added later. That said, the docstring is definitely wrong, and I can't find any unit tests for the feature (I thought there were some in test_with, but I appear to be mistaken). Currently, the code in the decimal module implements the context manager as a separate class instead of incorporating it directly in decimal.Context. This makes the API unnecessarily complex and is not pretty compared to the code it was intended to replace. The removal of the __context__ method made it impossible to permit context objects to be used directly in with statements. Even when that was the case, the separate ContextManager class was necessary in order to correctly handle the restoration as context objects may be shared between threads or nested within a single thread [1]. The localcontext() function in PEP 343 does exactly the same thing - it merely uses a generator context instead of a direct implementation of __enter__ and __exit__. The current syntax (the get_manager() method) can easily be made prettier in the future by adding a sugar function at the module level: def localcontext(ctx=None): if ctx is None: ctx = getcontext() return ctx.get_manager() Worse still, the implementation saves a reference to the context instead of making a copy of it. Remember decimal.Context objects are mutable -- the current implementation does not fulfill its contract to restore the context to its original state at the conclusion of the with-statement. The implementation doesn't forget that. The context to restore is determined by calling getcontext() in the __enter__ method. The restored context has nothing to do with the context passed to the ContextManager constructor. from decimal import getcontext() getcontext().prec 28 with getcontext().get_manager() as ctx: ... ctx.prec += 2 ... getcontext().prec 28 The only ways to break it are to call ContextManager directly with an existing context that someone else already has a reference to: from decimal import getcontext() getcontext().prec 28 with ContextManager(getcontext()) as ctx: ... ctx.prec += 2 ... getcontext().prec 30 Or to deliberately reuse a ContextManager instance: mgr = getcontext().get_manager() with mgr as ctx: ...ctx.prec += 2 ...print ctx.prec ... 32 with mgr as ctx: ...ctx.prec += 2 ...print ctx.prec ... 34 Cheers, Nick. [1] In fact, get_manager() is merely a new name for the old __context__ method. This name was suggested by Neal after I initially called the method context_manager(), but was never separately discussed on python-dev (the original discussion occurred in one of the massive PEP 343 threads). http://mail.python.org/pipermail/python-checkins/2006-May/052083.html -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
Nick Coghlan wrote: Raymond Hettinger wrote: I would like to see the changes to the decimal module reverted for the Py2.5 release. I believe you may be overreacting - I don't consider the current behaviour buggy and the module level API can be added later. My preference is to remove the method entirely and then implement the approach in PEP 343 by adding a module level localcontext() function in Py2.6. If you keep the method, then at least: * fix the docstring (and make it doctestable) * rename the method to .localcontext() * move the .copy() step to inside the contextmanager instead of its caller * update the WhatsNew example to match * add a unittest ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.5 issue: decimal context manager misimplemented, misdesigned, and misdocumented
I believe you may be overreacting - I don't consider the current behaviour buggy and the module level API can be added later. My preference is to remove the method entirely and then implement the approach in PEP 343 by adding a module level "localcontext()" function in Py2.6. If you keep the method, then at least: * fix the docstring (and make it doctestable) * rename the method to .localcontext() * move the .copy() step to inside the contextmanager instead of its caller * update the WhatsNew example to match * add a unittest Either way, be sure to also update the docs. They currently reflect the __context__ approach. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
