Mailman 3 May 2007 - Python-Dev

2.6, x64 and PGO
by Kristján Valur Jónsson May 4, 2007

May 4, 2007

Well, I have checked in the fixes to the trunk to make an x64 build run the testsuite. It works pretty well. I did a quick test and found the x64Release to run 51000 pystones vs. 44000 for the win32Release version, a difference of some 10%. And the x64PGO version ran some 61000 pystones. Some more extensive testing is of course required, but it would seem that gains can be had from both going 64 bit and using PGO. I encourage you to take a look at the PGO build process. It is much simpler … [View More]

2 1

Re: [Python-Dev] PEP 30XZ: Simplified Parsing
by Raymond Hettinger May 3, 2007

May 3, 2007

[Skip] > I use it all the time. For example, to build up (what I consider to be) >readable SQL queries: > > rows = self.executesql("select cities.city, state, country" > " from cities, venues, events, addresses" > " where cities.city like %s" > " and events.active = 1" > " and venues.address = addresses.id" > " and addresses.city = … [View More]

5 7

64 bit warnings
by Kristján Valur Jónsson May 3, 2007

May 3, 2007

There is a considerable amount of warnings present for 64 bit builds on windows. You can see them using VisualStudio 2005 even if you don't have the x64 compilers installed, by turning on "Detect 64 bit portability issues" in the general tab for pythoncore. Now, some of those just need straightforward upgrades of loop counters and so on to Py_ssize_t. Others probably require more judgement. E.g., do we want to change the signature of PyEval_EvalCodeEx() to accept Py_ssize_t counters rather … [View More]

2 1

head crashing (was: Fwd: [Python-checkins] buildbot warnings in x86 mvlgcc trunk)
by Neal Norwitz May 2, 2007

May 2, 2007

This is the third time I've seen a crash on 2 different machines. This is the first time I noticed this unexplained crash: http://python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/1983/step-… That was at r54982. I tried to reproduce this: with a non-debug build, with a debug build, with valgrind with both types of build. I could never reproduce it. Valgrind did not report any errors either. Here is the third failure: http://python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/… [View More]

7 9

Re: [Python-Dev] New operations in Decimal
by Nick Maclaren May 2, 2007

May 2, 2007

Facundo Batista <facundo(a)taniquetil.com.ar> wrote: > > > Am I losing my marbles, or is this a proposal to add the logical > > operations to FLOATING-POINT? > > Sort of. This is a proposal to keep compliant with the General Decimal > Arithmetic Specification, as we promised. > > http://www2.hursley.ibm.com/decimal/ Or, more precisely: http://www2.hursley.ibm.com/decimal/damisc.html All right. Neither you nor I have lost our marbles, but the … [View More]

1 0

New operations in Decimal
by Facundo Batista May 2, 2007

May 2, 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 … [View More]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/ [View Less]

2 2

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

May 2, 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. … [View More]

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. … [View More]

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: … [View More]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 [View Less]

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 … [View More]

4 3