On Sun, 17 Apr 2011 19:17:11 +0200, Stefan Krah <ste...@bytereef.org> wrote: > R. David Murray <rdmur...@bitdance.com> wrote: > [snip a lot] > > Thank you, this cleared up many things.
Heh. Keep in mind that this is my viewpoint. I *think* Brett agrees with me. I'm sure he'll speak up if he doesn't. > The technical reason is that the context is a speed critical data structure, > so I'm doing some tricks to emulate the context flags and traps dictionaries. [snip] Thanks, your explanation seems to me to make a good case for making the decimal.py implementation less permissive. > So, if one of the goals of the PEP is to clean up various APIs, I'm all > for it. My concern is though that the process will be very slow due to > lack of time and general reluctance to change APIs. And this is where > I see a potentially negative effect: Well, the general reluctance to change APIs is certainly an issue. But since you are advocating cdecimal changing the API *anyway*, if it is going to go in to CPython this would have to be addressed regardless. So I don't see that the PEP affects the speed of that part of the process from CPython's point of view. > Is it worth to stall development over relatively minor issues? Will > these differences actually affect someone in practice? Will the > four Python implementations block each other? In my vision it wouldn't stall development in any place it shouldn't be stalled by our normal backward compatibility rules. It would be a bug in the bug tracker saying "the API of module X has some undesirable characteristics that get in the way of implementing accelerators, can we change it?" Again, I don't see this as changing what the current procedure should be anyway, just clarifying it and making it more likely that we will *notice* the changes and deal with them proactively rather than finding out about them after the accelerator is in the field, having introduced a backward-incompatible change unintentionally. (Note: I'm sure that we will still accidentally do this anyway, I'm just hoping to reduce the frequency of such occurrences). -- R. David Murray http://www.bitdance.com _______________________________________________ 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
