Re: [Python-Dev] Strategy for converting the decimal module to C
Nick Maclaren wrote: The compiled code has made a data structure temporarily inconsistent because the operation is safe (say, list insertion), and then gets an asynchronous interrupt (e.g. SIGINT). The SIGINT handler does some operation (e.g. I/O) that implicitly uses floating-point, which then interrupts. Well, of course anything can be made to happen asynchronously by calling it from something asynchronous, such as a SIGINT handler. That doesn't change the fact that the floating point operation itself is deterministic, including whether it causes an exception. Well-written programs don't do any more in a signal handler than is absolutely necessary, for reasons which apply equally well whether floating point is involved or not. I'd say the mistake was made right at the beginning by assuming that the data structure in question was safe while allowing a SIGINT to occur to a handler that's not careful enough about what it does. BTW, it seems to me you could get exactly the same problem if FP exceptions were handled entirely in user mode, as you suggest. Not that I don't agree that would be a good idea -- I do -- but it wouldn't prevent this particular kind of mistake. And all of this is getting rather far away from where we started, which was simply instrumenting a piece of code to count floating point exceptions. Such a program isn't going to be doing I/O in SIGINT handlers or installing FP exception handlers that mess with unrelated critical data structures. -- Greg ___ 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] Strategy for converting the decimal module to C
Greg Ewing And all of this is getting rather far away from where we started, which was simply instrumenting a piece of code to count floating point exceptions. I'm thinking of adding a note to the Py2.5 docs that the counting feature is not part of the standard and should not be expected to work on other implementations of the standard (including a planned CPython extension module). 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
Re: [Python-Dev] Strategy for converting the decimal module to C
2006/7/26, Raymond Hettinger [EMAIL PROTECTED]: Greg Ewing And all of this is getting rather far away from where we started, which was simply instrumenting a piece of code to count floating point exceptions. I'm thinking of adding a note to the Py2.5 docs that the counting feature is not part of the standard and should not be expected to work on other implementations of the standard (including a planned CPython extension module). +1 -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Strategy for converting the decimal module to C
Greg Ewing [EMAIL PROTECTED] wrote: But we weren't talking about asynchronous exceptions, we were talking about floating point exceptions. Unless your TLB miss handler uses floating point arithmethic, there's no way it can get interrupted by one. (And if it does use floating point arithmetic in a way that can cause an exception, you'd better write it to deal with that!) I am really not getting my message across, am I? Yes, that is true - as far as it goes. The trouble is that designing systems based on assuming that IS true as far as it goes means that they don't work when it goes further. And it does. Here are a FEW of the many examples of where the simplistic model is likely to fail in an x86 context: The compiled code has made a data structure temporarily inconsistent because the operation is safe (say, list insertion), and then gets an asynchronous interrupt (e.g. SIGINT). The SIGINT handler does some operation (e.g. I/O) that implicitly uses floating-point, which then interrupts. The x86 architecture is extended to include out-of-order floating-point as it had in the past, many systems have today, and is very likely to happen in the future. It is one of the standard ways to get better performance, after all, and is on the increase. The x86 architecture is extended to support micro-threading. I have not been told by Intel or AMD that either have such plans, but I have very good reason to believe that both have such projects. IBM and Sun certainly do, though I don't know if IBM's is/are relevant. 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] Strategy for converting the decimal module to C
James Y Knight [EMAIL PROTECTED] wrote: To cut a long story short, it is impractical for a language run-time system to call user-defined handlers with any degree of reliability unless the compiled code and run-time interoperate carefully - I have been there and done that many times, but few people still working have. On architectures with out-of-order execution (and interrupts), you have to assume that an interrupt may occur anywhere, even when the code does not use the relevant facility. Floating-point overflow in the middle of a list insertion? That's to be expected. While this _is_ a real problem, is it _not_ a general problem as you are describing it. Processors are perfectly capable of generating precise interrupts, and the inability to do so has nothing to do with the out-of-order execution, etc. Almost all interrupts are precise. I am sorry, but this is almost totally wrong, though I agree that you will get that impression upon reading the architecture books unless you are very deeply into that area. Let's skip the hardware issues, as they aren't what I am talking about (though see [*]). I am referring to the interaction between the compiled code, deep library functions and run-time interrupt handler. It is almost universal for some deep library functions and common for compiled code to leave data structures inconsistent in a short window that cannot possibly fail - indeed, most system interfaces do this around system calls. If an interrupt occurs then, the run-time system will receive control with those data structures in a state where they must not be accessed. And it is fairly common for such data structures to include ones critical to the functioning of the run-time system. Now, it IS possible to write run-time systems that are safe against this, and still allow asynchronous interrupts, but I am one of three people in the world that I know have done it in the past two decades. There may be as many as six, but I doubt more, and I know of no such implementation on any Unix or Microsoft system. It is even possible to do this for compiled code, but that is where the coordination between the compiler and run-time system comes in. The only interesting one which is not, on x86 processors, is the x87 floating point exception, ... Er, no. Try a machine-check in a TLB miss handler. But it is all pretty irrelevant, as the problem arises with asychronous exceptions (e.g. timer interrupts, signals from other processes), anyway. Also, looking forward, the simd floating point instructions (ie mmx/ sse/sse2/sse3) _do_ ... The critical problems with the x87 floating-point exception were resolved in the 80386. [*] Whether or not it is a fundamental problem, it is very much a general problem at present, and it will become more so as more CPUs implement micro-threading. For why it is tied up with out-of-order execution etc., consider a system with 100 operations flying, of which 10 are memory accesses, and then consider what happens when you have combinations of floating-point exceptions, TLB misses, machine-checks (e.g. ECC problems on memory) and device/timer interrupts. Once you add user-defined handlers into that mix, you either start exposing that mess to the program or have to implement them by stopping the CPU, unwinding the pipeline, and rerunning in very, very serial mode until the handler is called. Look at IA64 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] Strategy for converting the decimal module to C
Greg Ewing [EMAIL PROTECTED] wrote: Now, interrupting into that level has to be transparent, in order to support TLB misses, clock interrupts, device interrupts, machine-check interrupts and so on. I thought we were just talking about counting the number of floating point exceptions that a particular piece of code generates. Surely that's deterministic, and isn't Er, no. Rather fundamentally, on two grounds. Please bear with me, as this IS relevant to Python. See the summary at the end if you like :-) The first is that such things are NOT deterministic, not even on simple CPUs - take a look at the Alpha architecture for an example, and then follow it up with the IA64 one if you have the stomach for it. But that wasn't my main point. It is that modern CPUs have a SINGLE interrupt mechanism (a mistake in itself, but they do), so a CPU may be interrupted when it is running a device driver, other kernel thread or within a system call as much as when running an application. In fact, to some extent, interrupt handlers can themselves be interrupted (let's skip the details). Now, in order to allow the application to run its handler, the state has to be saved, sanitised and converted back to application context; and conversely on return. That is hairy, and is why it is not possible to handle interrupts generated within system calls on many systems. But that is not directly Python's problem. What is, is that the code gets interrupted at an unpredictable place, and the registers and other state may not be consistent as the language run-time system and Python are concerned. It is critical (a) that a sane state is restored before calling the handler and (b) that calling the handler neither relies on nor disturbs any of the in flight actions in the interrupted code. To cut a long story short, it is impractical for a language run-time system to call user-defined handlers with any degree of reliability unless the compiled code and run-time interoperate carefully - I have been there and done that many times, but few people still working have. On architectures with out-of-order execution (and interrupts), you have to assume that an interrupt may occur anywhere, even when the code does not use the relevant facility. Floating-point overflow in the middle of a list insertion? That's to be expected. It becomes considerably easier if the (run-time system) interrupt handler merely needs to flag or count interrupts, as it can use a minimal handler which is defensive and non-intrusive. Even that is a pretty fair nightmare, as many systems temporarily corrupt critical registers when they think that it is safe. And few think of interrupts when deciding that So, in summary, please DON'T produce a design that relies on trapping floating-point exceptions and passing control to a Python function. This is several times harder than implementing fpectl. 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] Strategy for converting the decimal module to C
On Jul 21, 2006, at 6:18 AM, Nick Maclaren wrote: To cut a long story short, it is impractical for a language run-time system to call user-defined handlers with any degree of reliability unless the compiled code and run-time interoperate carefully - I have been there and done that many times, but few people still working have. On architectures with out-of-order execution (and interrupts), you have to assume that an interrupt may occur anywhere, even when the code does not use the relevant facility. Floating-point overflow in the middle of a list insertion? That's to be expected. While this _is_ a real problem, is it _not_ a general problem as you are describing it. Processors are perfectly capable of generating precise interrupts, and the inability to do so has nothing to do with the out-of-order execution, etc. Almost all interrupts are precise. The only interesting one which is not, on x86 processors, is the x87 floating point exception, which is basically for historical reasons. It has never been precise, ever since the actual 8087 coprocessor chip for the 8086. However, all is not lost: the exception cannot occur randomly. It can only occur on *some* floating point instruction, even if the instruction is not the one the error actually occurred in. So, unless your list insertion code uses floating point instructions, you should not get a floating point exception during your list insertion. Also, looking forward, the simd floating point instructions (ie mmx/ sse/sse2/sse3) _do_ generate precise interrupts. And on x86-64, x87 instructions are deprecated and everyone is recommended to use the simd ones, instead (so, for example, gcc defaults to using them). James ___ 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] Strategy for converting the decimal module to C
Greg Ewing [EMAIL PROTECTED] wrote: But couldn't you just put in an interrupt handler that counts the interrupts, for the purpose of measurement? No, but the reasons are very arcane. The general reason is that taking an interrupt handler and returning is not transparent, and is often not possible on modern systems. If that problem is at the hardware level (as on the Alpha and 3086/7), you are stuffed. But, more often, it is due the the fact that the architecture means that such handling can only be done at maximally privileged level. Now, interrupting into that level has to be transparent, in order to support TLB misses, clock interrupts, device interrupts, machine-check interrupts and so on. But the kernels rarely support transparent callbacks from that state into user code (though they used to); it is actually VERY hard to do, and even the mainframes had problems. This very commonly means that such counting breaks other facilities, unless it is done IN the privileged code. Of course, a GOOD hardware architecture wouldn't leave the process state when it gets a floating-point interrupt, but would just invoke an asynchronous routine call. That used to be done. As I said, none of this is directly relevant to emulated implementations, such as the current Python ones, but it IS to the design of an arithmetic specification.It could become relevant if Python wants to start to use a hardware implementation, because your proposal would mean that it would have to try to ensure that such callbacks are transparent. As one of the few people still working who has extensive experience with doing that, I can assure you that it is an order of magnitude fouler than you can imagine. A decimal order of magnitude :-( But note that I wasn't saying that such things should be put into the API, merely that there is a very good reason to do so for hardware implementations and ones used to tune code for such implementations. Personally, I wouldn't bother. 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] Strategy for converting the decimal module to C
Nick Maclaren wrote: Now, interrupting into that level has to be transparent, in order to support TLB misses, clock interrupts, device interrupts, machine-check interrupts and so on. I thought we were just talking about counting the number of floating point exceptions that a particular piece of code generates. Surely that's deterministic, and isn't affected by any of that stuff? -- Greg ___ 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] Strategy for converting the decimal module to C
Raymond Hettinger wrote: Aahz wrote: On Tue, Jul 18, 2006, Raymond Hettinger wrote: P.S. The dictionary approach to context objects should likely be abandoned for the C version. If the API has to change a bit, then so be it. Why do you say that? The rest I agree with; seems to me that making a small wrapper for dict access works well, too. I think it was tripping-up the folks working on the C implementation. Georg can speak to it more directly. IIRC, the issue was that the context object exposed a dictionary which a user could update directly and there was no notification back to the surrounding object so it could update an underlying bitfield representation. Yes, that's exactly what the problem was. Working with bitfields internally is fine as long as Python code doesn't want to change the dicts exposed as a wrapper. If the current approach gets in their way, the C implementers should feel free to make an alternate design choice. +1. (cDecimal is an ugly name, but a sound concept) I don't know what progress Mateusz' work has made until now, but he wrote at one time that he would start optimizing as soon as he's certain that it works. Georg ___ 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] Strategy for converting the decimal module to C
Georg Brandl wrote: Raymond Hettinger wrote: If the current approach gets in their way, the C implementers should feel free to make an alternate design choice. +1. (cDecimal is an ugly name, but a sound concept) I don't know what progress Mateusz' work has made until now, but he wrote at one time that he would start optimizing as soon as he's certain that it works. dmath (decimal-math, modelled on cmath for complex-math) could work. Cheers, Nick. -- 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] Strategy for converting the decimal module to C
I think it was tripping-up the folks working on the C implementation. Georg can speak to it more directly. IIRC, the issue was that the context object exposed a dictionary which a user could update directly and there was no notification back to the surrounding object so it could update an underlying bitfield representation. Yes, that's exactly what the problem was. Working with bitfields internally is fine as long as Python code doesn't want to change the dicts exposed as a wrapper. If you want to stick with dictionary-like access to traps and flags, then use a dict subclass that overrides each of the mutating methods. Even then, we need to drop the concept of having the flags as counters rather than booleans. 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
Re: [Python-Dev] Strategy for converting the decimal module to C
Georg Brandl [EMAIL PROTECTED] wrote: Even then, we need to drop the concept of having the flags as counters rather than booleans. Yes. Given that even Tim couldn't imagine a use case for counting the exceptions, I think it's sensible. Well, I can. There is a traditional, important use - tuning. When such arithmetic is implemented in hardware, it is normal for exceptional cases to be handled by interrupt, and that is VERY expensive - often 100-1,000 times the cost of a single operation, occasionally 10,000 times. It then becomes important to know how many of the things you got, to know whether it is worth putting code in to avoid them or even using a different algorithm. Now, it is perfectly correct to say that this does not apply to emulated arithmetic and that there is no justification for such ghastly implementations. But, regrettably, almost all exception handling on modern systems IS ghastly - at least by the standards of the 1960s. Whether you regard the use of Python for tuning code that is to be run using hardware, where the arithmetic will be performance- critical as important, is a matter of taste. I don't :-) 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] Strategy for converting the decimal module to C
... [Raymond] Even then, we need to drop the concept of having the flags as counters rather than booleans. [Georg Brandl] Yes. Given that even Tim couldn't imagine a use case for counting the exceptions, I think it's sensible. That's not it -- someone will find a use for anything. It's unfortunate that we used a dict with counts because the /standard/ we're trying to meet requires no such thing, and clearly had a pile of on/off bits model in mind. Extending a standard without strong need creates problems (for example, this one 0.5 wink). ___ 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] Strategy for converting the decimal module to C
Nick Maclaren wrote: When such arithmetic is implemented in hardware, it is normal for exceptional cases to be handled by interrupt, and that is VERY expensive ... It then becomes important to know how many of the things you got, to know whether it is worth putting code in to avoid them or even using a different algorithm. But couldn't you just put in an interrupt handler that counts the interrupts, for the purpose of measurement? -- Greg ___ 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] Strategy for converting the decimal module to C
Tim Peters wrote: ... [Raymond] Even then, we need to drop the concept of having the flags as counters rather than booleans. [Georg Brandl] Yes. Given that even Tim couldn't imagine a use case for counting the exceptions, I think it's sensible. That's not it -- someone will "find a use" for anything. It's unfortunate that we used a dict with counts because the /standard/ we're trying to meet requires no such thing, and clearly had a "pile of on/off bits" model in mind. Extending a standard without strong need creates problems (for example, this one 0.5 wink). What do you guys think about deprecating it for Py2.5? 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
[Python-Dev] Strategy for converting the decimal module to C
I briefly had a chance to look at some of the work being done on a C implementation of decimal, and it looks like the approach is following the Python version too literally. Ideally, it should be written as if Python were not involved and afterwards add the appropriate method wrappers. Contexts should be small structures that include the traps and flags as bitfields. Likewise, the internal representation of a decimal should be in a simple structure using a byte array for the decimal digits -- it should not be a Python object. Internally, the implementation creates many temporary decimals for a scratchpad, it makes many copies of contexts, it frequently tests components of a context, and the functions frequently call each other. Those operations need to be as cheap as possible -- that means no internal tuple objects, no ref counting, and no passing variables through tuples of arguments, etc. I recommend writing most of the module to be independent of the Python C API. After a working implementation is built, grafting on the wrappers should be a trivial step. Unless we stay true to this course, the code will end-up being unnecessarily complex and the performance will be disappointing. my-two-cents, Raymond P.S. The dictionary approach to context objects should likely be abandoned for the C version. If the API has to change a bit, then so be it. ___ 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] Strategy for converting the decimal module to C
On Tue, Jul 18, 2006, Raymond Hettinger wrote: P.S. The dictionary approach to context objects should likely be abandoned for the C version. If the API has to change a bit, then so be it. Why do you say that? The rest I agree with; seems to me that making a small wrapper for dict access works well, too. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian W. Kernighan ___ 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] Strategy for converting the decimal module to C
[Raymond Hettinger] ... If the current approach gets in their way, the C implementers should feel free to make an alternate design choice. I expect they will, eventually. Converting this to C is a big job, and at the NFS sprint we settled on an incremental strategy allowing most of the module to remain written in Python, converting methods to C one at a time. Changing the user-visible API is a hard egg to swallow, and it's unfortunate that the Python code used a dict to hold flags to begin with. The dict doesn't just record whether an exception has occurred, it also counts how many times the exception occurred. It's possible that someone, somewhere, has latched on to that as a feature. ___ 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] Strategy for converting the decimal module to C
Aahz wrote: On Tue, Jul 18, 2006, Raymond Hettinger wrote: P.S. The dictionary approach to context objects should likely be abandoned for the C version. If the API has to change a bit, then so be it. Why do you say that? The rest I agree with; seems to me that making a small wrapper for dict access works well, too. I think it was tripping-up the folks working on the C implementation. Georg can speak to it more directly. IIRC, the issue was that the context object exposed a dictionary which a user could update directly and there was no notification back to the surrounding object so it could update an underlying bitfield representation. If the current approach gets in their way, the C implementers should feel free to make an alternate design choice. 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
Re: [Python-Dev] Strategy for converting the decimal module to C
On 7/18/06, Tim Peters [EMAIL PROTECTED] wrote: [Raymond Hettinger] ... If the current approach gets in their way, the C implementers should feel free to make an alternate design choice. I expect they will, eventually. Converting this to C is a big job, and at the NFS sprint we settled on an incremental strategy allowing most of the module to remain written in Python, converting methods to C one at a time. Changing the user-visible API is a hard egg to swallow, and it's unfortunate that the Python code used a dict to hold flags to begin with. The dict doesn't just record whether an exception has occurred, it also counts how many times the exception occurred. It's possible that someone, somewhere, has latched on to that as a feature. Why not a 'cDecimal' module instead? -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ 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] Strategy for converting the decimal module to C
Lisandro Dalcin wrote: On 7/18/06, Tim Peters [EMAIL PROTECTED] wrote: [Raymond Hettinger] ... If the current approach gets in their way, the C implementers should feel free to make an alternate design choice. I expect they will, eventually. Converting this to C is a big job, and at the NFS sprint we settled on an "incremental" strategy allowing most of the module to remain written in Python, converting methods to C one at a time. Changing the user-visible API is a hard egg to swallow, and it's unfortunate that the Python code used a dict to hold "flags" to begin with. The dict doesn't just record whether an exception has occurred, it also counts how many times the exception occurred. It's possible that someone, somewhere, has latched on to that as "a feature". Why not a 'cDecimal' module instead? Good answer. My recommendation is that instead of "eventually", we bite the bullet now. The development path for decimal can follow that for sets where the lessons from sets.py were used to make an improved API for the C version while leaving the pure Python verion unmodified. Realizing that "it's unfortunate that the Python code used a dict to hold flags to begin with", the C implementers for decimal should move on to more sensible choices. Also, I have to take the blame for encouraging the "incremental" migration approach. I thought we could get some quick wins on the most common called parts of the module. Now, I can see that this approach will result in nasty, convoluted C code that falls far short of its performance potential and is a nightmare to maintain. Looking at some of the checkins, it is now clear to me that there are substantial benefits to divorcing the base C implementation of decimal from the Python C API. 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
Re: [Python-Dev] Strategy for converting the decimal module to C
Tim Peters wrote: Changing the user-visible API is a hard egg to swallow, and it's unfortunate that the Python code used a dict to hold flags to begin with. The dict doesn't just record whether an exception has occurred, it also counts how many times the exception occurred. It's possible that someone, somewhere, has latched on to that as a feature. Especially since it was a documented one: import decimal help(decimal.Context) Help on class Context in module decimal: class Context(__builtin__.object) | Contains the context for a Decimal instance. [...] | flags - When an exception is caused, flags[exception] is incremented. | (Whether or not the trap_enabler is set) | Should be reset by user of Decimal instance. [...] -- Giovanni Bajo ___ 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
