The following are the new operations in the decimal module that we'll
be available according to the last published specification.
I wrote here the proposed name by me, the original name between
parenthesis, where it will be located between square brackets (C for
context and D for the decimal object itself), and a small description
of the operation (I specially trimmed the verbose special cases from
the description, if you want an exact explanation of what does each,
read the spec).
Note that always it says how many operands it takes. The number
implies you're calling it through the context. If called through
Decimal, you have to substract one from it (as the first operand will
be the number itself in this case).
Enjoy it, and any feedback is very appreciated, :)
- compare_signal (compare–signal) [CD]: Takes two operands and
compares their values numerically (pretty much like compare(), but all
NaNs signal, with signaling NaNs taking precedence over quiet NaNs.
- fma (fused-multiply-add) [C]: Takes three operands; the first two are
multiplied together, using multiply, the third operand is then added
to the result of that multiplication, using add, all with only one
- ln (ln) [CD]: Takes one operand, and the result is the natural (base
e) logarithm of the operand.
- log10 (log10) [CD]: Takes one operand, and the result is the base 10
logarithm of the operand.
- max_mag (max–magnitude), and min_mag (min-magnitude) [CD]: Takes two
operands and compares their values numerically with their sign
- next_minus (next–minus) [CD]: Takes one operand and the result is the
largest representable number that is smaller than the operand.
- next_plus (next–plus) [CD]: Takes one operand and the result is the
smallest representable number that is larger than the operand.
- next_toward (next–toward) [CD]: Takes two operands and the result is
the representable number closest to the first operand (but not the
first operand) that is in the direction towards the second operand,
unless the operands have the same value.
- to_integral_exact (round-to-integral-exact) [C]: Takes one operand. It
is similar to the round–to–integral–value (the old to_integral), with
the difference the now Inexact and Rounded flags are allowed in the
The following operations appear in a new section of the specification
called "Miscelaneous Operations". Between these are logical
operations that take logical operands, which are finite positive
non-exponent numbers with a coefficient whose digits must all be either
0 or 1.
- and (and), or (or), xor (xor) [CD]: Takes two logical operands, the
result is the logical operation applied between each digit.
- canonical (canonical) [CD]: Canonical takes one operand, returns the
same Decimal object, as we do not have different encodings for the
- number_class (class) [CD]: Takes one operando, returns an indication
of the class of the operand, where the class is one of the following:
"sNaN", "NaN", "–Infinity", "–Normal", "–Subnormal", "–Zero", "+Zero",
"+Subnormal", "+Normal" or "+Infinity".
- compare_total (compare–total) [CD]: Takes two operands and compares
them using their abstract representation rather than their numerical
value (a total ordering is defined for all possible abstract
- compare_total_mag (compare–total–magnitude) [CD]: Takes two operands
and compares them using their abstract representation rather than
their numerical value, with their sign ignored and assumed to be 0.
- copy_abs (copy-abs) [CD]: Takes one operand, returns a copy of it
with the sign set to 0.
- copy_negate (copy-negate) [CD]: Takes one operand, returns a copy of
it with the sign inverted.
- copy_sign (copy–sign) [CD]: Takes two operands, returns a copy of the
first operand with the sign equal to the sign of the second operand.
- invert (invert) [CD]: Takes one logical operand, the result is the
digit-wise inversion of the operand.
- is-canonical (is–canonical) [CD]: Takes one operand, returns 1 if the
operand is canonical; otherwise returns 0.
- is_finite (is–finite) [CD]: Takes one operand, returns 1 if the
operand is neither infinite nor a NaN, otherwise returns 0.
- is_infinite (is–infinite) [CD]: Takes one operand, returns 1 if the
operand is an Infinite, otherwise returns 0.
- is_nan (is–NaN) [CD]: Takes one operand, returns 1 if the operand is
a quiet or signaling NaN, otherwise returns 0.
- is_normal (is–normal) [CD]: Takes one operand, returns 1 if the
operand is a positive or negative normal number, otherwise returns 0.
- is_qnan (is–qNaN) [CD]: Takes one operand, returns 1 if the operand
is a quiet NaN, otherwise returns 0.
- is_signed (is–signed) [CD]: Takes one operand, returns 1 if the sign
of the operand is 1, otherwise returns 0.
- is_snan (is–sNaN) [CD]: Takes one operand, returns 1 if the operand
is a signaling NaN, otherwise returns 0.
- is_subnormal (is–subnormal) [CD]: Takes one operand, returns 1 if the
operand is a positive or negative subnormal number, otherwise returns
- is_zero (is–zero) [CD]: Takes one operand, returns 1 if the operand
is a zero, otherwise returns 0.
- logb (logb) [CD]: Takes one operand, returns the integer which is the
exponent of the magnitude of the most significant digit of the operand
(as though the operand were truncated to a single digit while
maintaining the value of that digit and without limiting the resulting
- radix (radix) [CD]: Takes no operands, returns 10.
- rotate (rotate) [CD]: Takes two operands. The coefficient of the
result is a rotated copy of the digits in the coefficient of the first
operand. The number of places of rotation is taken from the absolute
value of the second operand, with the rotation being to the left if
the second operand is positive or to the right otherwise.
- scaleb (scaleb) [CD]: Takes two operands. The result is the first
operand modified by adding the value of the second operand to its
- shift (shift) [CD]: Takes two operands. The coefficient of the result
is a shifted copy of the digits in the coefficient of the first
operand. The number of places to shift is taken from the absolute
value of the second operand, with the shift being to the left if the
second operand is positive or to the right otherwise. Digits shifted
into the coefficient are zeros.
I downloaded Python's 2.5.1 (final) bz2 source archive
the other day to try to compile it in MinGW. I have
noted down the following observations that might be of
1. The bz2 archive ships with
\Modules\collectionsmodule.c instead of the
\Modules\_collectionsmodule.c used in the 2.5 SVN
branch. In fact the collectionsmodule.c was removed
some time ago.
2. If _collectionsmodule.c is the one to be used in
branch and source then it follows that \PC\config.c
needs an update.
3. test_1686475 of test_os appears to rely on the
existence of "c:\pagefile.sys" like so:
# Verify that an open file can be stat'ed
except WindowsError, e:
if e == 2: # file does not exist;
cannot run test
self.fail("Could not stat
But since that file does not appear to be in my C
drive and since the Windows error returned is not a
numeric, but rather a string of the sort: "[Error 5]
Access is denied: 'c:\\pagefile.sys'" then that test
fails for me both in the MinGW compiled Python and in
the officially distributed one.
4. Also test_1565150 of test_os which reads as
# Restrict test to Win32, since there is no
# systems support centiseconds
if sys.platform == 'win32':
t1 = 1159195039.25
os.utime(self.fname, (t1, t1))
fails in the MinGW compiled Python with the following
FAIL: test_1565150 (test.test_os.StatAttributeTests)
Traceback (most recent call last):
line 241, in test_1565150
AssertionError: 1159195040 != 1159195039.25
If the same test passes in the official CPython on the
same machine (and it does), can it then be deduced
that this is not a system's issue but a compiler one?
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
I have submitted a patch (http://www.python.org/sf/1704547) that
allows os.rename to replace the destination file if it exists, on
windows. As part of discussion in the tracker, Martin suggested that
python-dev should discuss the change.
Currently, os.rename() on windows uses the API MoveFile() which fails
if the destination file exists. The patch replaces this API with
MoveFileEx() and uses the flag MOVEFILE_REPLACE_EXISTING which causes
the destination file to be replaced if it exists. However, this change
is subtle and if there is any existing code that depends on current
os.rename behaviour on windows, their code is silently broken with
(any) destination file being overwritten. But the functionality of
replacing is important and I would like to know the best of way of
supporting it. If it is deemed that this change is not good to go in
as-is, how about having an optional parameter to os.rename (say,
win_replace) that can be used by callers to explicitly request
I must also point out that the patch uses another flag
MOVEFILE_COPY_ALLOWED effectively allowing renamed files to be on
separate file systems. The renaming in this case is not atomic and I
used this flag only to support current functionality. It is not a bad
idea to disallow such renames which brings it in line with the
behaviour on many unix flavors. This also has the potential to break
code but not silently.
Lastly, I found an old discussion about the same topic by this list.
Even though Guido indicated that he doesn't support API change in this
thread, I am posting again as I did not see any one mention
MoveFileEx() in that thread.
I was hoping you guys would consider creating function in os.path or
otherwise that would find the full path of a file when given only it's base
name and nothing else.I have been made to understand that this is not
currently possible.If it is in any can you please inform me of it[i know
this is not a tutorial] but please i need thiis badly if it's possible.Thank
FREE pop-up blocking with the new MSN Toolbar - get it now!
-----BEGIN PGP SIGNED MESSAGE-----
David Goodger and I have been the PEP editors for ages. Well, mostly
David lately as I've been way too busy to be of much use. David is
also pretty busy, and he lamented that he doesn't have much time for
editing when he put out his call for PEPs earlier this month.
We've now, or will soon have three more experienced Pythonistas
helping out as PEP editors, Georg Brandl, Brett Cannon, and Anthony
Baxter. As long as they've been hacking Python, you'd have thought
they'd have learned their lesson by now, but we'll gladly consume
more of their time and souls.
David and I would like to see some junior Pythonistas join the PEP
editor team, as a great way to gain experience and become more
involved with the community. As David says, PEP editing is something
a tech writer can do; it doesn't require intimate knowledge of
Python's C code base for example. PEP editors don't judge the
worthiness of a PEP -- that's for the Python community to do, but
they do the important work of ensuring that the PEPs are up to the
high quality and consistent standards that have been established over
the years. A PEP editor is sometimes also involved in the meta
process of developing and maintaining the PEPs. A good editor's eye,
excellent written communication skills, and the inhuman amount of
spare time that only the young have are your most important
If you're a budding Pythonista and are interested in becoming a PEP
editor, please send an email to peps(a)python.org. Let us know about
your writing and/or editing experience, how long you've been using
Python, how long you've been programming in general, and how much
cash you'll be sending our way. Kidding about that last bit. python-
dev lurkers are encouraged to apply!
Again, this call is for junior Pythonistas only. I think we have
enough experienced people now to cover our bases and to help mentor
new editors. We're really eager to get some new blood involved in
the Python community. We may not accept all applicants; we're aiming
for two or three additional editors, but that number isn't set in stone.
- -Barry (and David)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
-----END PGP SIGNATURE-----
PEP 11 notes that Mac OS 9 support was unsupported in 2.4. There are
still quite a few places that we check for sys.platform == 'mac'.
There are also (at least) 2 modules (macpath and macurl2path) that
look specific to Mac OS. (OS X has sys.platform == 'darwin'.)
Shall I add a deprecation warning on import to these modules or remove them?
I plan to remove other mac specific code (checking sys.platform) in
the stdlib unless someone beat me to it.
On Mon, Apr 30, 2007 at 08:34:56AM -0400, Calvin Spealman wrote:
> If you want, you can also grab the reference
> implementation from my blog: http://ironfroggy-code.blogspot.com/
This reference implementation is broken. It doesn't pass the following
test, for example:
__metaclass__ = autosuper
if type(self) is B:
return "we've got a B"
assert B().f() == "we've got a B"
I don't honestly think that you can easily fix the implementation to
pass this test, but I'm ready to check proposed fixes and write tests
for them. If there is really no working implementation yet then it
shouldn't have been a PEP posted on python-dev in the first place, IMHO
(and the discussion shouldn't go on on python-dev either).
Jim Jewett wrote:
> On 4/29/07, Tim Delaney <tcdelaney(a)optusnet.com.au> wrote:
>> I've been intending to write up a PEP for fixing super, but I
>> haven't had time to get to it.
> Calvin Spealman has the most recent draft. I hope he will incorporate
> this into his draft.
Sorry about this - wasn't receiving python-dev at home, so didn't
realise Calvin had released the PEP.
I think the current PEP draft is way too complicated - I don't think
there's any need for descriptors, etc. I think we can make things work
in the following way:
1. When a method is defined, the class is bound to it via an attribute
(which in my version is called func_class).
2. Every non-static method has an implicit cell variable called 'super'.
This would preferably not be able to be rebound. I also think it would
be beneficial if the first parameter to the method couldn't be rebound
(point 7 in my original email in this thread).
3. When a method is entered, the 'super' cell variable is populated by a
call equivalent to:
super = __builtin__.super(func_class, first_parameter)
This would result in 'super' being a constant object, within the scope
of the currently-executing method. 'keyword' was perhaps too strong - I
was thinking this would only need to be done if 'super' were actually
used, which would be easier to determine if 'super' actually were a
keyword. This could still be done by not emitting the above call unless
the 'super' cell variable were ever actually used.
I've done bytecode-hacky stuff to do the equivalent of the above (as
much as I've been able to), but a real implementation would just emit
the correct bytecode (or java bytecode, or whatever) in the compiled
The issue of super() vs. super.__call__() ambiguity - I'll need to look
at that when I get home.
I'm a strong -1 against super() automatically passing the parameters
that were passed to the currently-executing method.
All test_os tests pass for me now on WinXP under
MinGW. Please see http://wwww.python.org/sf/1709112
for details and patches.
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around