Now that the checkin is done, I don't think it needs to be reverted. But, in
general, we should probably abstain from making wholesale revisions that add
zero value for the users.
The stylistic change from:
ValueError, 'foo'
ValueError('foo')
is fine.
Changing MockThreading to subclass from object though borders on being a
semantic change and should be done with care. In this particular case, I see
no harm in it, but then I haven't tested it on a Py2.3 build with threading
disabled.
As promised in the decimal.py header, the spec updates should all be considered
as bugs and backported at some point after they are fully tested and we're
happy with them all around. Also, as promised, the module should continue to
run on Py2.3.
For the most part, many of the new operations can be implemented in terms of
the existing ops or in terms of the support functions that we already use
internally. Ideally, you can refactor common code while leaving almost all of
the exisiting algorithm implementation code untouched.
The spec's choice of new method names is unfortunate. You'll have to come-up
with something better than copy() and class().
FWIW, I think the new decimal development should probably be done in a branch
off of the current head. That way, you can check-in at will and get feedback
from everyone without risking the integrity of the head.
If you want to discuss anything during development, I'm usually available on
AOL instant messaging with the screename: raymondewt
Likewise, consider soliciting Tim's input on how to implement the ln()
operation. That one will be tricky to get done efficiently and correctly.
Raymond
--- Begin Message ---
2007/4/10, Raymond Hettinger <[EMAIL PROTECTED]>:
I don't think patches like this are a good idea. For almost
zero benefit, we've lost the clean info in "svn ann" and lost
having the code in Py2.6 exactly match Py2.5 and Py2.4
(so it will now be more difficult to backport and validate
real bug fixes).
Well. This is the first step in "me started working on decimal again".
The Decimal spec changed: it has new operations, but also changed the
behaviour of some already-present operations (right now I'm pulling my
hair because of a corner case of rounding that must behave different
in quantize).
What I don't know is: these changes will be considered as "bugs" and
backported to <2.6, or it will be considered as little changes that
will join the bigger changes in 2.6?
If the former, I agree with you that this change should be reversed
(note that I didn't realize these losses at its moment, but everybody
learns, ;).
What do you think?
When the exceptions were changed to new-style, I hope there
was a speed-up, that there is no change in semantics, and
that the code still runs under Py2.3 as promised in the header.
It changed from "ValueError, 'foo'" to "ValueError('foo')". Don't
remember when this was introduced in the language, though (didn't find
it overlooking the "What's new" docs...).
Thank you!
--
. Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
--- End Message ---
_______________________________________________
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
