Hi,
Only about a year late, I've fixed everything that's annoyed me about
Mk4py. There's quite a bit here, as I often stumbled on one bug or
brokenness as I was trying to fix another.
Since I've also had to move and rename some files, I don't think it'd
work well to provide a patch, so I've uploaded a new version here:
<http://web.sabi.net/temp/metakit-2.4.9.2+njr1.tar.gz>
In order to run the Python test cases with Python 2.3 or 2.3.1, you
need to replace the shipped version of test/regrtest.py with this one:
<http://web.sabi.net/temp/regrtest.py>
Python 2.2's regrtest works fine, this was a bug that was introduced
in 2.3 and I didn't catch in time. (I've filed it and posted a patch,
but it was too late to get into 2.3.1, apparently.)
I've tested with:
- Mac OS X 10.2, Python 2.3 - everything works. After all the garbage
with using libtool, it does work to create a Mk4py library, but its
composition is suboptimal (-flat_namespace, -bind_at_load are bad).
Distutils works a lot better - and is easier to use and faster.
../unix/configure --with-python=/Library/Frameworks/Python.framework/Versions/2.3
- Debian unstable, Python 2.3 - everything works, make/distutils builds
are equivalent.
../unix/configure --with-python=/usr
- Debian stable, Python 2.2 - make, make test-python works. The version
of distutils shipped with Python 2.2 is buggy; replacing it with a
current version causes 'python setup.py <build|test|install>' to work
fine.
../unix/configure --with-python=/usr/include/python2.2,/usr/lib/site-packages
- Debian stable, Python 1.5.2 - make, make test-python works. Python
1.5.2 doesn't come with distutils; installing the current version
works for build/install targets, but not for test (since some test
code I didn't write already didn't work there, I didn't bother). In
particular, Debian's 'python1.5-distutils' package does not work.
- FreeBSD 5.1-CURRENT, Python 2.3 - everything works, limited testing.
The changes:
- examples/demo.py: import metakit, not Mk4py, better at the claimed
purpose of "verify(ing) proper Mk4py installation".
- python/metakit.py:
- replaced comment at top of file with docstring so it shows up
in pydoc and related things as "DESCRIPTION".
- added metadata for use by pydoc; also referenced through setup.py
for Python package managers (thanks, Bob Ippolito)
- python/PyRowRef.cpp:
- properly handle attempts to store long long-sized values into
Metakit 'I' fields; throw an exception on overflow, instead of
corrupting the value
- properly handle the possibility of int subtypes in Metakit 'L'
fields; reading the value is not guaranteed to succeed any more
- convert Unicode objects to UTF-8 before storing in 'S' fields
- don't silently discard all data after a null character in 'S'
fields; throw an exception instead
- python/PyStorage.cpp:
- satisfy dumb compiler regarding guaranteed function exit from
PyStorage_Description()
- better type-check storage constructor, returning more intelligible
errors and exceptions where appropriate
- python/PyView.cpp:
- check number of arguments in view.setsize() instead of discarding
- clarify docstring for view.insert()
- fix view.insert() to better check arguments, fixes all the cases
I mentioned previously (attempting to insert a raw string or
multiple positional arguments)
- satisfy dumb compiler again in PyView_insert()
- improve consistency in docstring for view.append()
- check number of arguments in view.append() instead of discarding
- clarify error message in PyView_getitem()
- make clear that PyView::makeRowFromDict() is meant to discard
keyword arguments/dictionary keys which don't have corresponding
properties in the view - otherwise, it just looks like an
oversight
- fix PyView::makeRow to work with new-style classes, and still work
back to *sob* Python 1.5.2; also, do the other part of the
view.insert() changes above
- properly check the number of positional arguments in
view.append()/insert()
- python/scxx/PWONumber.h:
- don't assume LONG_LONG is defined if HAVE_LONG_LONG (it actually
means 'long long'); use PY_LONG_LONG instead
- fix PyNumber::operator long() to not assume that conversion to
long will succeed, potentially corrupting data (Python longs are
arbitrary-precision; they may not even fit in a long long)
- python/scxx/PWOSequence.h:
- consistency on PWOString type check failure exception string,
since it's now more prevalent since I changed string handling on
insert to use PWOString instead of raw PyObjects (needed to avoid
the reference counting getting out of control)
- added PWOString::size() for the aforementioned embedded null
checking
- python/setup.py:
- added config command (not user-visible); since Mk4py doesn't
import config.h and may be used on non-autoconf platforms, does a
check for Python unicode support and passes it through to the
build. This is the part that fails on pre-2.3 versions of
distutils, ironically the versions where it'd be most useful.
*sigh* At least it's possible to install the current distutils,
which is kept backwards-compatible to 1.5.2.
- added workaround for linker errors on several platforms. Tries in
two ways to make the C++ libraries be included; first, tries to
override $CC with $CXX (which was $CCC in Python 1.5.2) as defined
at the time Python is compiled. Second, for older Python versions
which may not have $CXX defined at all, or otherwise are broken,
add "-lstdc++" on Linux. Other OSes can be added as needed, but
at this point I gave up.
This is really all a workaround for distutils' inadequate support
for C++ extensions; it assumes the compiler/linker used to compile
Python itself is acceptable for all extensions, when it isn't.
- on Mac OS X with Python 2.3, removes the '-Wl,-x' linker option,
which causes static constructors to break in a particularly nasty
and confusing fashion. Took me three hours just to track down the
problem to this linker option! I've discussed this on the
pythonmac-sig list, it's pretty clear that it will be fixed in a
forthcoming MacPython version, but... :)
- added test command which runs tests with 'python setup.py test',
much like 'make test-python', except even more intelligently
- default to building in ../builds, for consistency with the rest
of Metakit; you can still use build -b to override it
- include package manager metadata (again thanks to Bob Ippolito)
- python/test/all.py:
- make sure we're testing the built modules instead of the installed
modules; do some manipulation of sys.path to ensure this
- fix a couple of occurrences of "MetaKit" -> "Metakit" :)
- fix some comments including a partial sentence I sent in last time
(oops; no idea what I meant to write)
- python/test/leaktest.py: just a simple test I wrote to test Unicode
strings, for which I was leaking memory - no more. May just be
deleted I guess, since it isn't run automatically and is very
Unix-specific.
- python/test/mktestsupport.py:
- moved some test support code here; e.g. testing for int/long
handling and Unicode support
- abstracted the insert/failure handling code from test_inttypes.py
so tests such as test_inttypes.py and test_string.py appear
cleaner and easier to understand.
- python/test/test.py: moved to python/test/test_unittest.py; whoever
created this file didn't bother to test that it broke my exsting
test, and didn't notice the 'test-python' target didn't even
reference it. If you want to run the tests standalone, use
'all.py', which I named as an analog to 'all.tcl' for the Tcl tests.
- python/test/test_inttypes.py:
- test int/long integration, where available
- python/test/test_string.py:
- test regular and Unicode string support, where available
- python/test/test_unittest.py (formerly test.py):
- test a lot more stuff
- unix/aclocal.m4, configure, scripts: updated for Autoconf 2.57, GNU
libtool 1.5 with Fink patches,
- unix/configure.in:
- prefer Python 2.3
- test for Python Unicode support (not used for distutils build)
- unix/Makefile.in
- fix 'clean' target to do a better job, removing libraries
- unix/autogen.sh
- regenerate from autoconf/automake/libtool/etc., since I always
botch the magic command sequence (and doubt I am alone)
That's it. I hope these changes will make it easier for people new to
Mk4py to get up and running, instead of being mired in compilation and
usage problems.
--
=Nicholas Riley <[EMAIL PROTECTED]> | <http://www.uiuc.edu/ph/www/njriley>
_______________________________________________
metakit mailing list - [EMAIL PROTECTED]
http://www.equi4.com/mailman/listinfo/metakit
