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
final rounding.
- 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
ignored.
- 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
result.
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
same number.
- 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
representations).
- 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
0.
- 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
exponent).
- 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
exponent.
- 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.
Regards,
--
. Facundo
.
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
There seems to be an issue with the PEP index:
http://python.org/dev/peps/ lists PEP 3122 as the last PEP (not
counting PEP 3141 which is deliberately out of sequence). As a
work-around, an up to date index is here:
http://python.org/dev/peps/pep-0000/
PEPs 3123-3128 are alive and well and reachable via this index.
One of the webmasters will look into this tonight.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
Hello
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
interest.
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:
def test_1686475(self):
# Verify that an open file can be stat'ed
try:
os.stat(r"c:\pagefile.sys")
except WindowsError, e:
if e == 2: # file does not exist;
cannot run test
return
self.fail("Could not stat
pagefile.sys")
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
follows:
# Restrict test to Win32, since there is no
guarantee other
# systems support centiseconds
if sys.platform == 'win32':
def test_1565150(self):
t1 = 1159195039.25
os.utime(self.fname, (t1, t1))
self.assertEquals(os.stat(self.fname).st_mtime, t1)
fails in the MinGW compiled Python with the following
message:
======================================================================
FAIL: test_1565150 (test.test_os.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "G:\projs\py25\python\r25\lib\test\test_os.py",
line 241, in test_1565150
self.assertEquals(os.stat(self.fname).st_mtime,
t1)
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?
Thanks
Khalid
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi,
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
replacing?
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.
http://mail.python.org/pipermail/python-dev/2001-May/014957.html
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.
Thanks,
Raghu.
Brett's PEP 3122 prompted me to finally PEP'ify my proposed solution for
the current incompatibility between PEP 328 (absolute imports) and PEP
338 (executing modules as scripts).
The only user visible change (other than bug 1510172 going away) would
be the presence of a new module level attribute in the main module.
Regards,
Nick.
PEP: 366
Title: Main module explicit relative imports
Version: $Revision: 55046 $
Last-Modified: $Date: 2007-05-01 21:13:47 +1000 (Tue, 01 May 2007) $
Author: Nick Coghlan <ncoghlan(a)gmail.com>
Status: Final
Type: Standards Track
Content-Type: text/x-rst
Created: 1-May-2007
Python-Version: 2.6
Post-History: 1-May-2007
Abstract
========
This PEP proposes a backwards compatible mechanism that permits
the use of explicit relative imports from executable modules within
packages. Such imports currently fail due to an awkward interaction
between PEP 328 and PEP 338 - this behaviour is the subject of at
least one open SF bug report (#1510172)[1].
With the proposed mechanism, relative imports will work automatically
if the module is executed using the ``-m`` switch. A small amount of
boilerplate will be needed in the module itself to allow the relative
imports to work when the file is executed by name.
Import Statements and the Main Module
=====================================
(This section is taken from the final revision of PEP 338)
The release of 2.5b1 showed a surprising (although obvious in
retrospect) interaction between PEP 338 and PEP 328 - explicit
relative imports don't work from a main module. This is due to
the fact that relative imports rely on ``__name__`` to determine
the current module's position in the package hierarchy. In a main
module, the value of ``__name__`` is always ``'__main__'``, so
explicit relative imports will always fail (as they only work for
a module inside a package).
Investigation into why implicit relative imports *appear* to work when
a main module is executed directly but fail when executed using ``-m``
showed that such imports are actually always treated as absolute
imports. Because of the way direct execution works, the package
containing the executed module is added to sys.path, so its sibling
modules are actually imported as top level modules. This can easily
lead to multiple copies of the sibling modules in the application if
implicit relative imports are used in modules that may be directly
executed (e.g. test modules or utility scripts).
For the 2.5 release, the recommendation is to always use absolute
imports in any module that is intended to be used as a main module.
The ``-m`` switch already provides a benefit here, as it inserts the
current directory into ``sys.path``, instead of the directory contain the
main module. This means that it is possible to run a module from
inside a package using ``-m`` so long as the current directory contains
the top level directory for the package. Absolute imports will work
correctly even if the package isn't installed anywhere else on
sys.path. If the module is executed directly and uses absolute imports
to retrieve its sibling modules, then the top level package directory
needs to be installed somewhere on sys.path (since the current directory
won't be added automatically).
Here's an example file layout::
devel/
pkg/
__init__.py
moduleA.py
moduleB.py
test/
__init__.py
test_A.py
test_B.py
So long as the current directory is ``devel``, or ``devel`` is already
on ``sys.path`` and the test modules use absolute imports (such as
``import pkg.moduleA`` to retrieve the module under test, PEP 338
allows the tests to be run as::
python -m pkg.test.test_A
python -m pkg.test.test_B
Rationale for Change
====================
In rejecting PEP 3122 (which proposed a higher impact solution to this
problem), Guido has indicated that he still isn't particularly keen on
the idea of executing modules inside packages as scripts [2]. Despite
these misgivings he has previously approved the addition of the ``-m``
switch in Python 2.4, and the ``runpy`` module based enhancements
described in PEP 338 for Python 2.5.
The philosophy that motivated those previous additions (i.e. access to
utility or testing scripts without needing to worry about name clashes in
either the OS executable namespace or the top level Python namespace) is
also the motivation behind fixing what I see as a bug in the current
implementation.
This PEP is intended to provide a solution which permits explicit
relative imports from main modules, without incurring any significant
costs during interpreter startup or normal module import.
Proposed Solution
=================
The heart of the proposed solution is a new module attribute
``__package_name__``. This attribute will be defined only in
the main module (i.e. modules where ``__name__ == "__main__"``).
For a directly executed main module, this attribute will be set
to the empty string. For a module executed using
``runpy.run_module()`` with the ``run_name`` parameter set to
``"__main__"``, the attribute will be set to
``mod_name.rpartition('.')[0]`` (i.e., everything up to
but not including the last period).
In the import machinery there is an error handling path which
deals with the case where an explicit relative reference attempts
to go higher than the top level in the package hierarchy. This
error path would be changed to fall back on the ``__package_name__``
attribute for explicit relative imports when the importing module
is called ``"__main__"``.
With this change, explicit relative imports will work automatically
from a script executed with the ``-m`` switch. To allow direct
execution of the module, the following boilerplate would be needed at
the top of the script::
if __name__ == "__main__" and not __package_name__:
__package_name__ = "<expected_pkg_name>"
Note that this boilerplate has the same disadvantage as the use of
absolute imports of sibling modules - if the script is moved to a
different package or subpackage, the boilerplate will need to be
updated manually.
With this feature in place, the test scripts in the package above
would be able to change their import lines to something along the
lines of ``import ..moduleA``. The scripts could then be
executed unmodified even if the name of the package was changed.
(Rev 47142 in SVN implemented an early variant of this proposal
which stored the main module's real module name in the
'__module_name__' attribute. It was reverted due to the fact
that 2.5 was already in beta by that time.)
Alternative Proposals
=====================
PEP 3122 proposed addressing this problem by changing the way
the main module is identified. That's a huge compatibility cost
to incur to fix something that is a pretty minor bug in the overall
scheme of things.
The advantage of the proposal in this PEP is that its only impact on
normal code is the tiny amount of time needed at startup to set the extra
attribute in the main module. The changes to the import machinery are all
in an existing error handling path, so normal imports don't incur any
performance penalty at all.
References
==========
.. [1] Absolute/relative import not working?
(http://www.python.org/sf/1510172)
.. [2] Guido's rejection of PEP 3122
(http://mail.python.org/pipermail/python-3000/2007-April/006793.html)
Copyright
=========
This document has been placed in the public domain.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
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
you
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
