Mailman 3 November 2010 - Python-announce-list

ANN: PyPM Index - build notification by author; import data
by Sridhar Ratnakumar Nov. 25, 2010

Nov. 25, 2010

Hi, There are, now, a couple more features to the previously announced PyPM Index that I think would be of interest if you are a developer of Python packages on PyPI. 1. an RSS feed for each author that shows the recently failing builds (eg: to identify bugs in releases) 2. The "import" feature shows if multiple packages provide the same import (eg: site-packages/tests) ... and, map packages to imports and vice-versa. See the "import conflicts" section for interesting set of cases. For more details, see my blog post: http://www.activestate.com/blog/2010/11/python-pypm-index-author-build-noti… -- Sridhar Ratnakumar Python Developer ActiveState, The Dynamic Language Experts http://www.activestate.com/ On 11/10/2010 5:08 PM, Sridhar Ratnakumar wrote: > Hi, > > I'd like to announce the availability of PyPM Index - frontend to > browse/search Python packages available in the PyPM repository: > > http://code.activestate.com/pypm/ > > The site also has some nifty features that, I think, may be of use to > package authors: > > 1. Author pages > 2. Build RSS notification (released with a setup.py bug?) > 3. Dependency information > > For more details, see this blog post: > http://www.activestate.com/blog/2010/11/pypm-index-python-developers >

1 0

ANN: Marrow Suite Releases
by Alice Bevan–McGregor Nov. 24, 2010

Nov. 24, 2010

The following packages have been released, each unit tested and/or tested by example (as applicable) on both Python 2.7 and 3.1. All packages, unless otherwise noted, are compatible with Python 2.6+ and 3.1+ and distributed under the MIT license. Versions < 1.0 are missing documentation and/or full unit tests. Documentation, where available, is accessible via the GitHub repository pages in the README.textile files which GitHub automatically renders. marrow.io 1.1 - Tornado IOLoop and IOStream fork with Python 3 support. License: Apache (Tornado's license.) Note: Tornado's documentation and unit tests apply to this package. - http://pypi.python.org/pypi/marrow.io/ - https://github.com/pulp/marrow.io/ marrow.server 0.9 - High-level asynchronous forking/threading Server and Protocol APIs. Note: The forking model is complete and functional, threading is still in development. - http://pypi.python.org/pypi/marrow.server/0.9 - https://github.com/pulp/marrow.server/ marrow.server.http 0.8 - High-performance HTTP/1.1 WSGI 2 server. Note: chunked transfer encoding is missing in this release. Warning: This server conforms to an altered version of PEP 444 and should be considered an experimental technical demonstration of proposed changes to the PEP. - http://pypi.python.org/pypi/marrow.server.http/0.8 - https://github.com/pulp/marrow.server.http/ marrow.util 1.0.1 - Commonly re-implemented Python utility functions, classes, and compatibility code. Compatibility: Python 2.5+, 3.1+ - http://pypi.python.org/pypi/marrow.util/1.0.1 - https://github.com/pulp/marrow.util/ marrow.wsgi.egress.compression 1.1 - GZip compression of WSGI 2 responses. Note: this is a fully functional, fully documented, 100% unit tested demonstration of the proposed filtering API for WSGI 2. - http://pypi.python.org/pypi/marrow.wsgi.egress.compression/1.1 - https://github.com/pulp/marrow.wsgi.egress.compression/ What is Marrow? A collection of related projects with a focus on simplicity, performance, clear separation of tasks, and dual Python 2.6+ / 3.1+ compatibility. For more information and a list of packages in development, see: - https://github.com/pulp/ Why re-invent the wheel? To help encourage web frameworks to adopt Python 3 the Marrow suite brute-forces the chicken-and-egg problem of library compatibility. Clean-room re-implementation of common WSGI middleware and associated utilities allows for lighter-weight code unencumbered by signifigant backwards-compatibility to be developed rapidly, quickly documented, and encourages test-centric development. Are these components production-ready? The short answer: no. marrow.io, being based on Tornado's published codebase is, as is marrow.util. The egress compression filter is, in theory, production ready (having complete documentation and 100% test coverage), though no server currently conforms to the WGSI 2 (PEP 444) API or WSGI 2 filtering API other than marrow.server.http, which is not production ready. It should be possible to adapt this egress filter to WSGI (PEP 333) without too much difficulty and utilize it in Python 2.6+ applications, however. Where do I report problems or request features? Each project has its own issue tracker hosted on GitHub. Please see the GitHub link for each package.

1 0

ANN: fancycompleter 0.2
by Antonio Cuni Nov. 22, 2010

Nov. 22, 2010

Hi, fancycompleter 0.2 has been released. http://bitbucket.org/antocuni/fancycompleter/src >From the README: fancycompleter is a module to improve your experience in Python by adding TAB completion to the interactive prompt. It is an extension of the stdlib's rlcompleter module. Features: * its best feature is that the completions are displayed in different colors, depending on their type. * To save space on screen, fancycompleter only shows the characters "after the dot". * If we press ``<TAB>`` at the beginning of the line, a real tab character is inserted, instead of trying to complete. This is useful when typing function bodies or multi-line statements at the prompt. * Unlike rlcompleter, fancycompleter **does** complete expressions containing dictionary or list indexing. For example, ``mydict['foo'].<TAB>`` works (assuming that mydict is a dictionary and that it contains the key 'foo', of course :-)). * Starting from Python 2.6, is the completed name is a callable, rlcompleter automatically adds an open parenthesis ``(``. This is annoying in case we do not want to really call it, so fancycompleter disable this behaviour. Enjoy, Antonio Cuni

1 0

Pyro 3.11 released
by Irmen de Jong Nov. 22, 2010

Nov. 22, 2010

Hi, Pyro 3.11 has been released! Pyro is a an advanced and powerful Distributed Object Technology system written entirely in Python, that is designed to be very easy to use. Have a look at http://www.xs4all.nl/~irmen/pyro3/ for more information. Highlights of this release are: - improved compatibility with Jython - fixed some threading problems regarding proxy connections - fixed a threading issue that could break COM calls - persistent mode nameserver improved As always the detailed changes are in the change log chapter in the manual. More info and download link available in PyPI: http://pypi.python.org/pypi/Pyro/ Enjoy, Irmen de Jong

1 0

ANN: NumPy 1.5.1
by Ralf Gommers Nov. 21, 2010

Nov. 21, 2010

Hi, I am pleased to announce the availability of NumPy 1.5.1. NumPy is the fundamental package needed for scientific computing with Python. It contains: * a powerful N-dimensional array object * sophisticated (broadcasting) functions * basic linear algebra functions * basic Fourier transforms * sophisticated random number capabilities * tools for integrating Fortran code. Besides it's obvious scientific uses, NumPy can also be used as an efficient multi-dimensional container of generic data. Arbitrary data-types can be defined. This allows NumPy to seamlessly and speedily integrate with a wide-variety of databases. This bug-fix release comes almost 3 months after the 1.5.0 release, it contains no new features compared to 1.5.0. Binaries, sources and release notes can be found at https://sourceforge.net/projects/numpy/files/. Thank you to everyone who contributed to this release. Enjoy, The numpy developers. ========================= NumPy 1.5.1 Release Notes ========================= Numpy 1.5.1 is a bug-fix release with no new features compared to 1.5.0. Numpy source code location changed ============================== ==== Numpy has stopped using SVN as the version control system, and moved to Git. The development source code for Numpy can from now on be found at http://github.com/numpy/numpy Note on GCC versions ==================== On non-x86 platforms, Numpy can trigger a bug in the recent GCC compiler versions 4.5.0 and 4.5.1: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45967 We recommend not using these versions of GCC for compiling Numpy on these platforms. Bugs fixed ========== Of the following, #1605 is important for Cython modules. - #937: linalg: lstsq should always return real residual - #1196: lib: fix negative indices in s_ and index_exp - #1287: core: fix uint64 -> Python int cast - #1491: core: richcompare should return Py_NotImplemented when undefined - #1517: lib: close file handles after use in numpy.lib.npyio.* - #1605: core: ensure PEP 3118 buffers can be released in exception handler - #1617: core: fix clongdouble cast to Python complex() - #1625: core: fix detection for ``isfinite`` routine - #1626: core: fix compilation with Solaris 10 / Sun Studio 12.1 Scipy could not be built against Numpy 1.5.0 on OS X due to a numpy.distutils bug, #1399. This issue is fixed now. - #1399: distutils: use C arch flags for Fortran compilation on OS X. Python 3 specific; #1610 is important for any I/O: - #----: f2py: make f2py script runnable on Python 3 - #1604: distutils: potential infinite loop in numpy.distutils - #1609: core: use accelerated BLAS, when available - #1610: core: ensure tofile and fromfile maintain file handle positions

1 0

[ANN] Call for Papers: Workshop Python for High Performance and Scientific Computing
by Andreas.Schreiber＠dlr.de Nov. 19, 2010

Nov. 19, 2010

Workshop Python for High Performance and Scientific Computing June 1-3, 2011, Tsukuba, Japan part of The International Conference on Computational Science (ICCS 2011) http://www.dlr.de/sc/iccs2011 =============== Call for Papers =============== Introduction ------------ Python is an accepted high-level programming language with a growing community in academia and industry. Beside its original use as a scripting language for web applications, today Python is a general-purpose language adopted by many scientific applications like CFD, bio molecular simulation, AI, scientific visualization etc. More and more industrial domains are turning towards it as well, such as robotics, semiconductor manufacturing, automotive solutions, telecommunication, computer graphics, and games. In all fields, the use of Python for scientific, high performance parallel, and distributed computing, as well as general scripted automation is increasing. Moreover, Python is well-suited for education in scientific computing. The workshop aims at bringing together researchers and practitioners from industry and academia using Python for all aspects of high performance and scientific computing. The goal is to present Python-based scientific applications and libraries, to discuss general topics regarding the use of Python (such as language design and performance issues), and to share experience using Python in scientific computing education. Topics ------ * Python-based scientific applications and libraries * High performance computing * Parallel Python-based programming languages * Scientific visualization * Scientific computing education * Python performance and language issues * Problem solving environments with Python * Performance analysis tools for Python application Papers/Submission ----------------- We invite you to submit a paper of up to 10 pages formatted according to the rules of Procedia Computer Science (http://www.elsevier.com/locate/inca/719435) via the ICCS 2011 conference submission system (http://www.iccs-meeting.org/iccs2011/papers/upload.php) selecting our workshop Python for High Performance and Scientific Computing in the drop-down menu. Important Dates --------------- Full paper submission: January 10, 2011 Notification of acceptance: February 20, 2011 Camera-ready papers: March 7, 2011 Program Committee ----------------- * Achim Basermann, German Aerospace Center, Germany * David Beazley, Dabeaz, LLC, USA * William E. Hart, Sandia National Laboratories, USA * Konrad Hinsen, Centre de Biophysique Moléculaire, CNRS Orléans, France * Andreas Klöckner, New York University, USA * Maurice Ling, Singapore Polytechnic, Singapore * Stuart Mitchell, The University of Auckland, New Zealand * Mike Müller, Python Academy, Germany * Travis Oliphant, Enthought, Inc., USA * Fernando Pérez, University of California, Berkeley, USA * Massimo Di Pierro, DePaul University, USA * Marc Poinot, ONERA, France * William Scullin, Argonne National Laboratory, USA * Gaël Varoquaux, INRIA, France Workshop Organizers ------------------- * Chair: Andreas Schreiber, German Aerospace Center (DLR), Germany E-Mail: iccs2011(a)dlr.de * Co-Chair: Guy K. Kloss, Auckland University of Technology, New Zealand -- Andreas Schreiber Head Distributed Systems and Component Software DLR (German Aerospace Center), Simulation and Software Technology Linder Hoehe, 51147 Cologne, Germany Tel: +49 (0)2203/601-2485 http://www.dlr.de/sc Fax: +49 (0)2203/601-12485 MSN: mailto:Andreas.Schreiber@dlr.de Mobile: +49 (0)173 5231013 ICQ# 324185855 DLR on Twitter: http://twitter.com/DLR_de

1 0

ANN: PyGUI 2.3.1
by Greg Ewing Nov. 19, 2010

Nov. 19, 2010

PyGUI 2.3.1 is available: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ This version incorporates a modification that I hope will improve the behaviour of ScrollableViews on Windows with pywin32 builds later than 212. (There are still problems with it, though. If the Scrollable View doesn't fill all of its containing window, the scroll bars get repositioned incorrectly when the window is resized. This appears to be entirely MFC's doing. I really will have to get away from using CView altogether.) This version also fixes a problem on Windows whereby dismissing a modal dialog with the Return key could spuriously activate a button in another window. What is PyGUI? -------------- PyGUI is a cross-platform GUI toolkit designed to be lightweight and have a highly Pythonic API. -- Gregory Ewing greg.ewing(a)canterbury.ac.nz http://www.cosc.canterbury.ac.nz/greg.ewing/

1 0

[ANN] tperimeter 1.112 Released And Available
by Tim Daneliuk Nov. 19, 2010

Nov. 19, 2010

'tperimeter' Version 1.112 is released and available at: http://www.tundraware.com/Software/tperimeter/ The last public release was 1.110 What's New ---------- The user can now leave either the service name or IP input field blank. A blank service name will default the IP address discovered in the http headers. This is almost always the correct address to open for remote access. Commercial licensing restrictions have been removed. There is no mandatory fee for use by for-profit, government, institutional organizations or individual users. What Is 'tperimeter'? --------------------- Have you ever been away from the office and needed, say, ssh access to your system? Ooops - you can't do that because in your zealous pursuit of security, you set your TCP wrappers to prevent outside access to all but a select group of hosts. Worse still, everywhere you go, your local IP address changes so there is no practical way to open up the wrappers for this situation. 'tperimeter' is a dynamic TCP wrapper control system that gives you (limited) remote control of your TCP wrapper configuration. It does this via a web interface that you've (hopefully) secured with https/SSL. You just log in, specify your current IP address and one of the services you want to access. 'tperimeter' will then briefly open a hole in your wrappers long enough to let you in. It then automatically closes the hole again. Voila! Remote access to your system, wherever you are. You get much of the facility of a VPN or so-called "port knocking" without most of the aggravation. As a side benefit, 'tperimeter' will also simplify management of your standard /etc/hosts.allow TCP wrapper control file. 'tperimeter' is written in python, shell script, and html. It is very small and easy to maintain. It was developed and tested on FreeBSD 4.x/8.x, and apache 1.x/2.x, but should run with very minor (or no) modification on most Unix-like systems like Linux or Mac OS X hosts. It comes complete with documentation in html, pdf, dvi, and Postscript formats. There is no licensing fee any use, commercial, institutional, or personal. -- ---------------------------------------------------------------------------- Tim Daneliuk tundra(a)tundraware.com PGP Key: http://www.tundraware.com/PGP/

1 0

ANN: GMPY 1.14 and GMPY2 alpha1 released
by casevh Nov. 18, 2010

Nov. 18, 2010

Everyone, I'm pleased to annouce the release of both a new production and experimental release of GMPY. GMPY is a wrapper for the MPIR or GMP multiple-precision arithmetic library. The experimental release (GMPY2) now includes support for the MPFR floating-point library. GMPY is available for download from: http://code.google.com/p/gmpy/ Production release ------------------ GMPY 1.14 is the updated stable release. A memory leak was fixed so it is highly recommended that all user upgrade to this version. In addition to a few other bug fixes, GMPY 1.14 is compatible with the changes to the hashing code in Python 3.2a4. The 64-bit Windows installer for Python 3.2 should only be used with 3.2a4 and later. Even though my primary development focus has shifted to GMPY2 (see below), GMPY 1.X will continue to receive bug and compatibility fixes. Experimental release -------------------- To simplify the codebase, allow for changes in the API, and support simultaneous installation, the development version has been renamed to GMPY2. The following is list of changes in GMPY2: In 2.0.0a0 ---------- * support for a mutable integer type "xmpz" * removal of random number functions * "xmpz" supports slices for setting/clearing bits * some methods have been renamed (scan1 -> bit_scan1) * support for Python prior to 2.6 has been removed * support for all division modes has been added * ceiling - round to +Infinity * floor - round to -Infinity * truncate - round to zero * 2exp - division by a power of 2 * support is_even() and is_odd() In 2.0.0a1 ---------- * support for the MPFR floating point library If you use GMPY regularly, please test GMPY2. There have been several requests asking for a mutable integer and I am curious if there are real-world performance improvements. Please report any issues! casevh

1 0

[ANN]: 'tren' Cross-Platform Batch Renaming Tool, Version 1.239 Released
by Tim Daneliuk Nov. 18, 2010

Nov. 18, 2010

'tren' Version 1.239 is now released and available for download at: http://www.tundraware.com/Software/tren The last public release was 1.217. --------------------------------------------------------------------- What's New In This Release? --------------------------- This release fixes several critical bugs and adds a number of new features. Existing users are urged to upgrade at their earliest opportunity: FIXED: Backups weren't being improperly named. FIXED: Changed TREN envvar processing to properly parse quoting. FIXED: Each renaming target must either be something that exists or a wildcard that expands to something that exists. Formerly, nonexistent renaming targets were silently ignored. NEW: Debug now shows the incremental change to each file name as each renaming request is applied left-to-right. Use -dq to see this more clearly. NEW: The environment variable TRENINCL is now supported. This allows you to specify a path to search when looking for include files. NEW: Implemented /NAMESOFAR/ renaming token. NEW: Added -e type case conversion option - new kind of renaming request. c - Capitalize l - Lower s - Swap case t - Title -> Char's followiing non-alpha are capitalized u - Upper NEW: Added -T option to allow user to "target" a substring of the full filename for renaming OTHER: Documentation additions and updates including clarification of old features, description of new features, and improved table-of-contents for PDF and PS document formats. What Is 'tren'? ------------------ 'tren' is a general purpose file and directory renaming tool. Unlike commands like 'mv', 'tren' is particularly well suited for renaming *batches* of files and/or directories with a single command line invocation. 'tren' eliminates the tedium of having to script simpler tools to provide higher-level renaming capabilities. 'tren' is also adept at renaming only *part of an existing file or directory name* either based on a literal string or a regular expression pattern. You can replace any single, group, or all instances of a given string in a file or directory name. 'tren' implements the idea of a *renaming token*. These are special names you can embed in your renaming requests that represent things like the file's original name, its length, date of creation, and so on. There are even renaming tokens that will substitute the content of any environment variable or the results of running a program from a shell back into the new file name. 'tren' can automatically generate *sequences* of file names based on their dates, lengths, times within a given date, and so on. In fact, sequences can be generated on the basis of any of the file's 'stat' information. Sequence "numbers" can be ascending or descending and the count can start at any initial value. Counting can take place in one of several internally defined counting "alphabets" (decimal, hex, octal, alpha, etc.) OR you can define your own counting alphabet. This allows you to create sequences in any base (2 or higher please :) using any symbol set for the count. 'tren' is written in pure Python and requires Python version 2.6.x or later. It is known to run on various Unix-like variants (FreeBSD, Linux, MacOS X) as well as Windows. It will also take advantage of 'win32all' Python extensions on a Windows system, if they are present. --------------------------------------------------------------------- Complete details of all fixes, changes, and new features can be found in the WHATSNEW.txt and documentation files included in the distribution. A FreeBSD port has been submitted as well.

1 0