Re: [Python-Dev] Changes to decimal.py
"Tim Peters" <[EMAIL PROTECTED]> wrote: > > One low-effort approach is to use a general root-finding algorithm and > build ln(x) on top of exp() via (numerically) solving the equation > exp(ln(x)) == x for ln(x). ... Not a general one, please! At least use one that assumes the continuity of second derivatives :-) > However, the IBM spec requires < 1 ULP worst-case error, and that may > be unreasonably hard to meet with a root-finding approach. ... It's a doddle in a software implementation for civilised functions like log. All you do is to do the calculation in a sufficiently extended precision - and you can work that out in advance for very little extra effort. Then you round to the result - and, hey! Bob's your uncle! 0.501 ULPs is as easy as 1, if a bit slower. Now, doing that for the power function is a right royal pain in the neck, and you really DON'T want to even contemplate a generic gamma function, let alone one of the beta functions :-( But none of this is specific to a decimal base, of course. 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 [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __lltrace__
Hello again. So, using __lltrace__, I stumbled over a crashbug (to which I have already submitted a fix).i To trigger the crash, I modified lib/test/test_trace.py, lines 609 onwards: def test_16_no_jump_into_finally_block(self): globals()["__lltrace__"] = 1 self.run_test(no_jump_into_finally_block) del globals()["__lltrace__"] This would crash in all versions I tried. Now, I wonder, is it worth it adding a regression test for the __lltrace__ functionality? I realize it is a debug feature, only availible in debug builds, for debugging python itself, on the other hand, it had been broken for a long time and no one had noticed, hence perhaps the need for a test? What do you think? Kristján ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __lltrace__
The __lltrace__ feature costs in maintenance; it should either be fixed or ripped out. On 4/14/07, Kristján Valur Jónsson <[EMAIL PROTECTED]> wrote: > > > > > Hello again. > > So, using __lltrace__, I stumbled over a crashbug (to which I have already > submitted a fix).i > > To trigger the crash, I modified lib/test/test_trace.py, lines 609 onwards: > > def test_16_no_jump_into_finally_block(self): > > globals()["__lltrace__"] = 1 > > self.run_test(no_jump_into_finally_block) > > del globals()["__lltrace__"] > > > > This would crash in all versions I tried. > > Now, I wonder, is it worth it adding a regression test for the __lltrace__ > functionality? I realize it is a debug feature, only availible in > > debug builds, for debugging python itself, on the other hand, it had been > broken for a long time and no one had noticed, hence perhaps the need for a > test? > > > > What do you think? > > > > Kristján > ___ > Python-Dev mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making builtins more efficient
;`On Thu, 2007-02-22 at 01:26 +0100, Giovanni Bajo wrote: > On 20/02/2007 16.07, Steven Elliott wrote: > > > I'm finally getting back into this. I'd like to take one more shot at > > it with a revised version of what I proposed before. > > > > For those of you that did not see the original thread it was about ways > > that accessing builtins could be more efficient. It's a bit much to > > summarize again now, but you should be able to find it in the archive > > with this subject and a date of 2006-03-08. > > Are you aware of this patch, which is still awaiting review? > https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1616125&group_id=5470 I was not aware of your patch. I've since downloaded it, applied it, and played with it a bit. I find the cached module lookups (cached lookups when loading attributes in modules via LOAD_ATTR) to be particularly interesting since it addresses a case where PEP 280 leaves off. Your idea is to have an indexable array of objects that is only used when the hash table has not been changed, which can be determined by the timestamps you added. That may be the best way of handling attributes in modules (LOAD_ATTR). For global variables (LOAD_GLOBAL) I'm curious how it compares to PEP 280 and or Greg Ewing's idea. -- --- | Steven Elliott | [EMAIL PROTECTED] | --- ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] fdopen mode needs sanitizing
In fileobject the mode string is sanitized using a function, sanitize_the_mode(). The same thing needs to happen for posixmodule.fdopen(). Otherwise, the universal_newlines regression test in test_subprocess.py will fail for python compiled with Visual Studio 2005. I have made a local patch by copying this static function over, and it fixes the issue, but I wonder if we would want to share this code? Also, are there other places that spring to mind where we have to sanitize mode strings before handing them to fopen-like functions? Kristján ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] new subscriber looking for grunt work
Hello All, I'll be as brief as possible. The welcome message to this list suggested that I post a brief introduction of myself, so here it goes. I've been programming for about 10 years now (7 professionally). I would rank myself as a moderate programmer always looking to improve, and would like to help on this project in whatever way I can. I'll be trolling for grunt work and any documentation that needs to be done while I get the hang of things around here. Thanks for your patience. Sergio Mion ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (04/08/07 - 04/15/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1649 open ( +2) / 8584 closed ( +0) / 10233 total ( +2) Average duration of open issues: 764 days. Median duration of open issues: 715 days. Open Issues Breakdown open 1649 ( +2) pending 0 ( +0) Issues Created Or Reopened (2) __ Art 04/12/07 http://bugs.python.org/issue1028created artleafoll session error04/13/07 http://bugs.python.org/issue1029created artleafoll ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com