________________________________________________________________________
ANNOUNCING:
eGenix.com mxODBC Database Package for Python
Version 2.0.1
Full Source Python extensions providing important and useful
services for Python programmers.
________________________________________________________________________
WHAT IS IT ?:
The eGenix.com mxODBC Database Package for Python is part of the
eGenix.com mx Extension Series for Python, a collection of
professional quality software tools which enhance Python's usability
in many important areas such as ODBC database connectivity, fast text
processing, date/time processing and web site programming.
________________________________________________________________________
WHAT'S NEW ?
This patch release fixes a few problems which were found by users on
Windows platforms:
* Execution of SQL commands lead to a hanging Python processes for
some users.
* Handling of date/time values resulted in exceptions on some
Windows configurations.
Due to popular demand, I am now also providing precompiled Windows
binaries for the older Python 1.5.2 version. Binaries for Python 2.1
will be announced after its final release.
________________________________________________________________________
SPECIAL OFFER
theKompany.com has licensed the eGenix.com mx Commercial Package
(which includes mxODBC) for inclusion in their brand new Qt-based
Python IDE BlackAdder. It allows developing portable GUI-based
database applications which run on Windows and Linux platforms without
any change to the source code.
BlackAdder includes a 1 CPU license for this package at no extra cost,
so you may want to check out their great new product. See
http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#BlackAdder
for details.
________________________________________________________________________
EGENIX.COM MX COMMERCIAL PACKAGE OVERVIEW:
mxODBC - Generic ODBC 2.0-3.5 interface for Python
mxODBC is an extension package that provides a Python Database
API compliant interface to ODBC capable database drivers and
managers.
In addition to the capabilities provided through the standard DB
API it also gives access to a rich set of catalog methods which
allow you to scan the database for tables, procedures,
etc. Furthermore, it uses the mxDateTime package for date/time
value interfacing eliminating most of the problems these types
normally introduce (other in/output formats are available too).
mxODBC allows you to interface to more than one database from one
process, making inter-database interfacing very flexible and
reliable.
The source version includes a varity of preconfigured setups for
many commonly used databases such as MySQL, Oracle, Informix,
Solid, SAP DB, Sybase ASA and ASE, DBMaker and many more. The
precompiled versions for Windows and Linux include the interfaces
to the standard ODBC manager on these platforms to allow for a
more easily configurable setup.
More details are available at:
http://www.lemburg.com/files/python/mxODBC.html
________________________________________________________________________
WHERE CAN I GET IT ?
The download archives and instructions for installing the packages can
be found at:
http://www.lemburg.com/files/python/
Note that in order to use mxODBC you will also need to install the
eGenix.com mx BASE package which can be downloaded from the same
location.
________________________________________________________________________
WHAT DOES IT COST ?
mxODBC comes with a licenses which allows non-commercial use at no
charge, but costs a moderate fee for commercial use. Please see
http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#mxCOMMERCIAL
for details. The package comes with full source code.
________________________________________________________________________
WHERE CAN I GET SUPPORT ?
Commercial quality support for these packages is available from
eGenix.com Software GmbH. Please see
http://www.lemburg.com/files/python/eGenix-mx-Extensions.html#Support
for details about the eGenix support offerings.
________________________________________________________________________
REFERENCE:
<P><A HREF="http://www.lemburg.com/files/python/">eGenix.com mxODBC
Package</A> - eGenix.com mxODBC Database Interface 2.0.1 with
distutils support and precompiled binaries for Windows and
Linux. (31-Mar-2001)
________________________________________________________________________
Enjoy,
--
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting: http://www.egenix.com/
Python Pages: http://www.lemburg.com/python/
Scientific Python 2.2
---------------------
Scientific Python is a module library for scientific computing. In
this collection you will find modules that cover basic geometry
(vectors, tensors, transformations, vector and tensor fields),
quaternions, automatic derivatives, (linear) interpolation,
polynomials, elementary statistics, nonlinear least-squares fits, unit
calculations and conversions, Fortran-compatible text formatting, 3D
visualization via VRML, two Tk widgets for simple line plots and 3D
wireframe models. Scientific Python also contains Python interfaces to
the netCDF library (implementing a portable binary format for large
arrays) and the Message Passing Interface, the most widely used
communications library for parallel computers.
Version 2.2 of Scientific Python has just been released. In addition
to numerous small improvents and bug fixes, it contains the first
stable release of the MPI interface. It is also the first release to
use the new distutils package in order to facilitate installation.
For more information and for downloading, see
http://starship.python.net/crew/hinsen/scientific.html
or
http://dirac.cnrs-orleans.fr/programs/scientific.html
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen(a)cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
This is a summary of traffic on the python-dev mailing list between
Mar 15 and Mar 28 (inclusive) 2001. It is intended to inform the
wider Python community of ongoing developments. To comment, just
post to python-list(a)python.org or comp.lang.python in the usual
way. Give your posting a meaningful subject line, and if it's about a
PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep
iteration) All python-dev members are interested in seeing ideas
discussed by the community, so don't hesitate to take a stance on a
PEP if you have an opinion.
This is the fourth summary written by Michael Hudson.
Summaries are archived at:
<http://starship.python.net/crew/mwh/summaries/>
Posting distribution (with apologies to mbm)
Number of articles in summary: 410
50 | [|]
| [|]
| [|]
| [|]
40 | [|]
| [|] [|]
| [|] [|] [|]
| [|] [|] [|] [|] [|]
30 | [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|]
20 | [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
10 | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
0 +-044-024-013-029-059-046-040-022-040-031-007-019-008-028
Thu 15| Sat 17| Mon 19| Wed 21| Fri 23| Sun 25| Tue 27|
Fri 16 Sun 18 Tue 20 Thu 22 Sat 24 Mon 26 Wed 28
Bug-fixing for 2.1 remained a priority for python-dev this fortnight
which saw the release of 2.1b2 last Friday.
* Python 2.0.1 *
Aahz posted his first draft of PEP 6, outlining the process by which
maintenance releases of Python should be made.
<http://python.sourceforge.net/peps/pep-0006.html>
Moshe Zadka has volunteered to be the "Patch Czar" for Python 2.0.1.
<http://mail.python.org/pipermail/python-dev/2001-March/013952.html>
I'm sure we can all join in the thanks due to Moshe for taking up
this tedious but valuable job!
* Simple Generator implementations *
Neil Schemenauer posted links to a couple of "simple" implementations
of generators (a.k.a. resumable functions) that do not depend on the
stackless changes going in.
<http://mail.python.org/pipermail/python-dev/2001-March/013648.html>
<http://mail.python.org/pipermail/python-dev/2001-March/013666.html>
These implementations have the advantage that they might be
applicable to Jython, something that sadly cannot be said of
stackless.
* portable file-system stuff *
The longest thread of the summary period started off with a request
for a portable way to find out free disk space:
<http://mail.python.org/pipermail/python-dev/2001-March/013706.html>
After a slightly acrimonious debate about the nature of Python
development, /F produced a patch that implements partial support for
os.statvfs on Windows:
<http://sourceforge.net/tracker/index.php?func=detail&aid=410547&group_id=54…>
which can be used to extract such information.
A side-product of this discussion was the observation that although
Python has a module that does some file manipulation, shutil, it is
far from being as portable as it might be - in particular it fails
miserably on the Mac where it ignores resource forks. Greg Ward then
pointed out that he had to implement cross-platform file copying for
the distutils
<http://mail.python.org/pipermail/python-dev/2001-March/013962.html>
so perhaps all that needs to be done is for this stuff to be moved
into the core. It seems very unlikely there will be much movement
here before 2.2.
MacPython 2.1b2 is available for download. Get it via
http://www.cwi.nl/~jack/macpython.html .
New in this version:
- A choice of Carbon or Classic runtime, so runs on anything between
MacOS 8.1 and MacOS X
- Distutils support for easy installation of extension packages
- BBedit language plugin
- All the platform-independent Python 2.1 mods
- New version of Numeric
- Lots of bug fixes
- Choice of normal and active installer
Please send feedback on this release to pythonmac-sig(a)python.org,
where all the maccies hang out.
Enjoy,
--
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++
Pymmetry - http://sourceforge.net/projects/pymmetry
dependencies: any version of python that supports the "+=" operator (2.0
and above only?). other than that, it's pretty much self-contained code.
Raph Levien's net_flow.c and tmetric.c - ported to python (from
mod_virgule - running advogato.org)
Contains an implementation of the Ford-Fulkerson Maximum Flow algorithm.
Uses this algorithm in a way that is effectively "Cascading (or
Hierarchical) Access Control".
Pymmetry 1.0 example usage code includes a text-based profile /
user-certifications implementation.
python r0kz.
luke
----- Luke Kenneth Casson Leighton <lkcl(a)samba-tng.org> -----
"i want a world of dreams, run by near-sighted visionaries"
"good. that's them sorted out. now, on _this_ world..."
Greetings, earthlings!
As Guido said in the last conference, there is going to be a bugfix release
of Python 2.0, Python 2.0.1. Originally meant to be only a license bugfix
release, comments in the Python community have indicated a need for a real
bugfix release. PEP 6[1] has been written by Aahz, which outlines a procedure
for such releases. With Guido's blessing, I have volunteered to be the
Patch Czar (see the PEP!) for the 2.0.1 release. In this job, I intend
to be feared and hated throughout the Python community -- men will
tremble to hear the sounds of my footsteps...err...sorry, got sidetracked.
This is the first Python pure bugfix release, and I feel a lot of weight
rests on my shoulders as to whether this experiment is successful. Since
this is the first bugfix release, I intend to be ultra-super-conservative.
I can live with a release that does not fix all the bug, I am very afraid
of a release that breaks a single person's code. Such a thing will give
Python bugfix releases a very bad reputation. So, I am going to be a very
strict Czar.
I will try to follow consistent rules about which patches to integrate,
but I am only human. I will make all my decisions in the public, so they
will be up for review of the community.
There are a few rules I intend to go by
1. No fixes which you have to change your code to enjoy. (E.g., adding a new
function because the previous API was idiotic)
2. No fixes which have not been applied to the main branch, unless they
are not relevant to the main branch at all. I much prefer to get a pointer
to an applied patch or cvs checkin message then a fresh patch. Of course,
there are cases where this is impossible, so this isn't strict.
3. No fixes which have "stricter checking". Stricter checking is a good
thing, but not in bug fix releases.
4. No fixes which have a reasonable chance to break someone's code. That
means that if there's a bug people have a good change of counting on,
it won't be fix.
5. No "improved documentation/error message" patches. This is stuff that
gets in people's eyeballs -- I want bugfix upgrade to be as smooth
as possible.
6. No "internal code was cleaned up". That's a good thing in the development
branch, but not in bug fix releases.
Note that these rules will *not* be made more lenient, but they might
get stricter, if it seems such strictness is needed in order to make
sure bug fix releases are smooth enough.
However, please remember that this is intended to help you -- the Python
using community. So please, let me know of bugfixes that you need or want
in Python 2.0. I promise that I will consider every request.
Note also, that the Patch Czar is given very few responsibilities ---
all my decisions are subject to Guido's approval. That means that he
gets the final word about each patch.
I intend to post a list of patches I intend to integrate soon -- at the
latest, this Friday, hopefully sooner. I expect to have 2.0.1a1 a week
after that, and further schedule requirements will follow from the
quality of that release. Because it has the dual purpose of also being
a license bugfix release, schedule might be influenced by non-technical
issues. As always, Guido will be the final arbitrator.
--
"I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
-- Wichert Akkerman (on debian-private)| easier, more seductive.
For public key, finger moshez(a)debian.org |http://www.{python,debian,gnu}.org
a pythonware newsflash:
Secret Labs AB has released a new, much improved version of
their integrated development environment for Python.
PythonWorks is a rapid application development tool, designed
for efficient development in Python. PythonWorks includes editors,
a debugger, a user-interface design tool, project browser,
deployment tools, integrated on-line help, and a scriptable
environment.
PythonWorks is well suited for many tasks, including:
+ Cross-platform system administration (system automation)
+ Prototyping of user interfaces and full applications
+ Building test frameworks
+ Rapid development and deployment of complete applications
New features in 1.2 include improved support for Python 2.0,
support for multiple pads and views, directory workspaces, lots
of editor improvements, basic class browser, and improved EXE
deployment support.
Beginning with version 1.2, Secret Labs is also offering OEM
versions of PythonWorks, for customers who want to provide a
powerful IDE environment as part of their own Python-powered
applications, or want a customized version of PythonWorks for
use in their organization.
To learn more, visit the PythonWorks product site:
http://www.pythonworks.com
You can also mail us at info(a)pythonware.com
regards,
the pythonworks team
Since there have been no trouble reports for some time I have decided to
shift PyBSDDB 3.0 out of beta and have made a final release. You can get it
here:
http://sourceforge.net/project/showfiles.php?group_id=13900&release_id=28477
Binaries are provided for win32 and Linux (RPMs). The source distribution
should build using distutils anywhere else that Sleepycat DB is supported.
Description:
------------
Berkeley DB is a programmatic toolkit that provides high-performance
built-in database support for desktop and server applications. The Berkeley
DB access methods include B+tree, Extended Linear Hashing, Fixed and
Variable-length records, and Queues. Berkeley DB provides full transactional
support, database recovery, online backups, multi-threaded and multi-process
access, etc.
The Python wrappers allow you to store Python string objects of any length,
keyed either by strings or integers depending on the database access method.
With the use of another module in the package standard shelve-like
functionality is provided allowing you to store any picklable Python object!
Additional details, including online docs, are available here:
http://pybsddb.sourceforge.net/
--
Robin Dunn
Software Craftsman
robin(a)AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!
Announcing the latest version of HappyDoc, a Python documentation
extraction tool.
HappyDoc is a tool for extracting documentation from Python source
code. It differs from other such applications by the fact that it
uses the parse tree for a module to derive the information used in
its output, rather that importing the module directly. This allows
the user to generate documentation for modules which need special
context to be imported.
Version 1.4 --
- Handle Packages separately from Modules. This behavior is
optional and consists mostly of creating intermediate level
TOC pages and not showing subdirectories of a Package on the
Package's parent TOC page.
- Changed default title to include instructions about how to
change the title
- Show exceptions in plugins when there is a problem loading a
module
- Added a command line argument to support ignoring specific
subdirectories.
- Fixed problem with ignoring directories by correcting name
comparison logic.
- Change "link":URL style references which were HTML
quoted back to StructuredText so that hyperlinks can be embedded
within docstrings. (reported by Mihalopoulos Evangelos)
- Changed base class arrangement for docset so the basic interface
is documented as part of the docset base class.
- Moved some formatter functions into the docset, since they match
that API better and more properly belong there.
- Fixed bug 131751, problem with string dereference in
parseinfo.py
- Set the DOCTYPE in hdformatter_htmlfile.py. (Thanks to
Shannon -jj Behrens for the patch.)
- Fixed problem with references to extra files when using output
prefixes.
- Changed test harness to use the HappyDoc class directly instead
of calling out to a separate program.
- Output a oneliner for referenced pre-formatted documents.
- Modified parseinfo.py to improve speed
- Expanded information extracted about exceptions thrown by
functions
- Simplified the regressino test to make it faster by removing
Zope docs from the default regression test suite
Download
Download the latest version of HappyDoc from the home page on
SourceForge:
http://sourceforge.net/projects/happydoc
Doc-string Format
How does an author write documentation so that it will be marked up
and look fancy? This is a perennial question for Python, and seems
to have introduced a roadblock into the development of more robust
and useful documentation tools. By separating the formatter classes
from the docset classes, HappyDoc allows a user to create their own
formatter to interpret comments in any way they see fit.
The default for the HTMLTableFormatter (the default formatter for
HappyDoc) is to treat __doc__ strings as StructuredText. Don't like
StructuredText? Write your own formatter that does something
different and drop it into place.
Documentation not in Doc-strings
It is not always desirable to put all documentation in __doc__
strings. Sometime, notably when working with Zope, special meaning
is attached to the presence of __doc__ strings. For this reason,
and to support existing code which might not have __doc__ strings,
HappyDoc will find and extract documentation in Python comments.
Comment documentation can contain all of the same formatting as
__doc__ strings. The preceding comment marker will be stripped off
and the lines will be assembled and treated as a block of
StructuredText.
To use this feature, it is important to place the comments
**before** the named object which they describe. In this example:
#
# Class documentation goes here
#
class ClassWithNoDocStrings:
"Using __doc__ strings overrides comment documentation."
def method1(self, params):
"This method uses a __doc__ string."
pass
#
# Method2 does not use a __doc__ string.
#
def method2(self):
pass
The output would include the __doc__ strings for the class and for
method1. It would also make it appear that method2 had a __doc__
string with the contents "Method2 does not use a __doc__ string."
Shy of RPMs because of library or other dependancy problems with most of
the RPMs you pick up? The cure, in my experience is to pick up an SRPM.
All you need to do to build a binary package tailored to your system is run
"rpm --rebuild <packagename>.src.rpm".
I've just put up an SRPM of the 2.1b2 release at:
ftp://ftp.tummy.com/pub/tummy/RPMS/SRPMS/
Again, this one builds the executable as "python2.1", and can be installed
along-side your normal Python on the system. Want to check out a great new
feature? Type "python2.1 /usr/bin/pydoc string".
Download the SRPM from above, and most users can install a binary built
against exactly the set of packages on their system by doing:
rpm --rebuild python-2.1b2-1tummy.src.rpm
rpm -i /usr/src/redhat/RPMS/i386/python*2.1b1-1tummy.i386.rpm
Note that this release enables "--with-pymalloc". If you experience
problems with modules you use, please report the module and how it can be
reproduced so that these issues can be taken care of.
Enjoy,
Sean
--
Total strangers need love, too; and I'm stranger than most.
Sean Reifschneider, Inimitably Superfluous <jafo(a)tummy.com>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
