Mailman 3 May 2007 - Python-Dev

New operations in Decimal
by Facundo Batista May 1, 2007

May 1, 2007

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/

2 2

PEP index out of date, and work-around
by Guido van Rossum May 1, 2007

May 1, 2007

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/)

1 0

Python 2.5.1
by Khalid A. Bakr May 1, 2007

May 1, 2007

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

8 35

os.rename on windows
by Raghuram Devarakonda May 1, 2007

May 1, 2007

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.

3 4

PEP 366: Main module explicit relative imports
by Nick Coghlan May 1, 2007

May 1, 2007

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

1 0

(no subject)
by JOSHUA ABRAHAM May 1, 2007

May 1, 2007

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/

4 3