about presicion
Ali
like to the to the 100 th or more decimal place. if so how?
mensa...@aol.com
> I was wondering if it was posible to get very good presicion. I mean
> like to the to the 100 th or more decimal place. if so how?
Get the gmpy module.
>>> import gmpy
>>> fn = gmpy.mpf(3**1996)
>>> fd = gmpy.mpf(3**2000)
>>> s = fn/fd + 1
>>> gd = gmpy.fdigits(s,10,100)
>>> print gd
1.012345679012345679012345679012345679012345679012345679012345679012345679012345679012345679012345679e0
>>>
Paul Miller
> I was wondering if it was posible to get very good presicion. I mean
> like to the to the 100 th or more decimal place. if so how?
You can have infinite, or at least arbitrary precision, if you do all
calculations on rational numbers. Doing this will probably be very
slow compared to calculations on floats, ints, or longs, however,
especially if implemented in pure Python.
A compromise would be to use a fixed-point representation. If you
needed 100 decimal digits after the decimal point, and say, 10 before
the decimal point, you could accomplish that (and actually a teeny bit
more) using a 368-bit fixed-point representation. This could possibly
be fast in Python, depending on the implementation.
It all depends what your requirements are.
Batista, Facundo
#- I was wondering if it was posible to get very good presicion. I mean
#- like to the to the 100 th or more decimal place. if so how?
In Python 2.4 you'll have the Decimal module:
Python 2.4a2 (#55, Aug 5 2004, 11:42:43) [MSC v.1310 32 bit (Intel)] on
win32
...
>>> import decimal
>>> decimal.getcontext().prec=100
>>> d = decimal.Decimal(2)
>>> d.sqrt()
Decimal("1.41421356237309504880168872420969807856967187537694807317667973799
0732478462107038850387534327641573")
Enjoy it.
. Facundo
Alex Martelli
> [alikak...@hotmail.com]
>
>
> #- I was wondering if it was posible to get very good presicion. I mean
> #- like to the to the 100 th or more decimal place. if so how?
>
> In Python 2.4 you'll have the Decimal module:
...and that's surely the right choice if you want decimal arithmetic.
If you want binary float arithmetic with ridiculous numbers of bits of
precision, that's one of the GMP features wrapped by
gmpy.sourceforce.net ...
Alex
Ali
The decimal module comes with python 2.4? I have 2.3, :(, what do I do?
Peter Hansen
> The decimal module comes with python 2.4? I have 2.3, :(, what do I do?
The obvious answer is, well, obvious. The real question is
what's stopping you from upgrading?
-Peter
Peter Otten
The module's docstring starts with "This is a Py2.3 implementation of
decimal floating point arithmetic", so there is hope you can just drop it
into your 2.3 instalation.
Peter
Mensanator
>From: Peter Hansen pe...@engcorp.com
>Date: 8/28/04 10:31 PM Central Daylight Time
>Message-id: <JN6dnW6HuNi...@powergate.ca>
I just tried it and found out it's not compatible with gmpy.
Of course, I wouldn't need gmpy to get big floats, but I
would then lose all the math functions like linear congruence
and modular inverse that my programs depend on.
So I, for one, will have to wait for the rest of the world to
catch up to 2.4.
>
>-Peter
--
Mensanator
Ace of Clubs
Ali
2.4 version because it seems that it is still in alpha.
Alex Martelli
> >Subject: Re: about presicion
> >From: Peter Hansen pe...@engcorp.com
> >Date: 8/28/04 10:31 PM Central Daylight Time
> >Message-id: <JN6dnW6HuNi...@powergate.ca>
> >
> >Ali wrote:
> >
> >> The decimal module comes with python 2.4? I have 2.3, :(, what do I do?
> >
> >The obvious answer is, well, obvious. The real question is
> >what's stopping you from upgrading?
>
> I just tried it and found out it's not compatible with gmpy.
By "it" do you mean Decimal, or Python 2.4 alpha 2? I think gmpy should
build happily with the latter, and interoperate sensibly with Decimal
anyway -- as gmpy's author I'd be quite happy to fix gmpy if it's broken
in either respect.
> Of course, I wouldn't need gmpy to get big floats, but I
> would then lose all the math functions like linear congruence
> and modular inverse that my programs depend on.
>
> So I, for one, will have to wait for the rest of the world to
> catch up to 2.4.
2.4 is not currently recommended for production work (that's why it's in
Alpha -- very good for an alpha, but it's still not a final release).
But such support modules as gmpy need to get moving to support 2.4 in
order to be ready for it well before final release...
Alex
Alex Martelli
> So the decimal module is in 2.4 but not 2.3? Also I am not geting the
> 2.4 version because it seems that it is still in alpha.
You _SHOULD_ get the 2.4 alpha, and try it out -- that's why alphas get
released, after all! How's the final release going to be perfect unless
people DO get and try the alphas?!
But you shouldn't yet use 2.4 for production work (stuff you ship to
customers, etc).
The Decimal module is in the standard library in 2.4, but Decimal itself
can support 2.3 just fine -- just download and install it.
Alex
mensa...@aol.com
> Mensanator <mensa...@aol.compost> wrote:
>
> > >Subject: Re: about presicion
> > >From: Peter Hansen pe...@engcorp.com
> > >Date: 8/28/04 10:31 PM Central Daylight Time
> > >Message-id: <JN6dnW6HuNi...@powergate.ca>
> > >
> > >Ali wrote:
> > >
> > >> The decimal module comes with python 2.4? I have 2.3, :(, what
do I do?
> > >
> > >The obvious answer is, well, obvious. The real question is
> > >what's stopping you from upgrading?
> >
> > I just tried it and found out it's not compatible with gmpy.
>
> By "it" do you mean Decimal, or Python 2.4 alpha 2?
By "it", I meant gmpy 1.0 and Python 2.4. Trying to import the
module says it can't use the Python23.dll.
> I think gmpy should
> build happily with the latter,
I'm using the pre-built Windows binary distribution. I wouldn't
know how to re-build it. I assume that when Python 2.4 is final,
I newer compatible version of gmpy will become available.
> and interoperate sensibly with Decimal
> anyway -- as gmpy's author I'd be quite happy to fix gmpy if it's
broken
> in either respect.
Were you aware that there is apparently a memory leak in the
gmpy.divm() function? Calling it several million time caused my
computer to run out of virtual memeory. Luckily, I was able to
work around it using the gmpy.invert() which didn't consume any
memory regardless of how many times it was called.
>
> > Of course, I wouldn't need gmpy to get big floats, but I
> > would then lose all the math functions like linear congruence
> > and modular inverse that my programs depend on.
> >
> > So I, for one, will have to wait for the rest of the world to
> > catch up to 2.4.
>
> 2.4 is not currently recommended for production work (that's why it's
in
> Alpha -- very good for an alpha, but it's still not a final release).
I don't do any production work. I'm just a hobbyist, so it's not a
big deal.
Ali
ok but where can i download deciaml? waht about gmpy? which is better?
Batista, Facundo
#- ok but where can i download deciaml? waht about gmpy? which
#- is better?
>From http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/
Don't know gmpy, so I can't compare. But decimal will be in the standard
library, so since Py2.4 you'll not need an external module.
. Facundo
David M. Cooke
--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)physics(dot)mcmaster(dot)ca
Alex Martelli
...
> ok but where can i download deciaml? waht about gmpy? which is better?
Decimal (for 2.3): file decimal.py from:
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/
With 2.4 it will come as part of the standard library.
gmpy: http://gmpy.sourceforge.net.\/
"Which is better" for _WHAT_ task? If you need decimal arithmetic,
obviously Decimal, since gmpy doesn't support it -- gmpy uses binary
throughout. If you need huge-precision binary floats,
unbounded-precision rational numbers, very fast operations such as
factorials and binomial coefficients on unbounded-precision integers,
then obviously gmpy, since Decimal doesn't support any of these --
Decimal does its job, which is decimal arithmetic, period.
I cannot imagine offhand any task for which I would be in doubt between
using Decimal and using gmpy -- sure, they both deal with numbers, but
there's basically no overlap between their functionality.
Alex
Alex Martelli
...
> > > I just tried it and found out it's not compatible with gmpy.
> >
> > By "it" do you mean Decimal, or Python 2.4 alpha 2?
>
> By "it", I meant gmpy 1.0 and Python 2.4. Trying to import the
> module says it can't use the Python23.dll.
_Any_ binary extension Python module compiled for Python 2.3 cannot even
load (on Windows) with Python 2.4 -- this has always been true on
Windows between any two releases of Python and will presumably continue
to be so for the foreseeable future.
This doesn't mean that Python 2.4 "is not compatible with gmpy" or
viceversa: it just means you obviously need to use a gmpy binary (pyd
file) compiled for the version of Python you're using. Just as it would
be the case for any other binary extension module whatsoever.
Unfortunately, compiling any binary extension module on Windows for
Python 2.4 requires Microsoft's very latest C++ compiler -- I do not own
a copy, nor do I have any PC normally running Windows XP, which is
required to run that compiler. Until Pyhon 2.3, I made do with a
Windows 98 session running under win4lin on one of my Linux machines,
and good old Microsoft Visual C++ 6 -- but such limited resources are
not sufficient any longer to compile Python binary extension modules for
Python 2.4. Since in terms of income-making (as well as leisure;-) I
work by now only on MacOSX, Linux, and OpenBSD machines, I am not going
to buy a PC loaded with Microsoft software just to be able to donate
precompiled Python binary extension modules to Windows users.
> > I think gmpy should
> > build happily with the latter,
>
> I'm using the pre-built Windows binary distribution. I wouldn't
> know how to re-build it. I assume that when Python 2.4 is final,
> I newer compatible version of gmpy will become available.
Not by magic -- I hope somebody out there owns all the needed Microsoft
software and is interested in compiling gmpy for Windows under Python
2.4 and making it available, but it won't be me.
> > and interoperate sensibly with Decimal
> > anyway -- as gmpy's author I'd be quite happy to fix gmpy if it's
> broken
> > in either respect.
>
> Were you aware that there is apparently a memory leak in the
> gmpy.divm() function? Calling it several million time caused my
> computer to run out of virtual memeory. Luckily, I was able to
> work around it using the gmpy.invert() which didn't consume any
> memory regardless of how many times it was called.
No, I was not aware of that -- I'll look into it, thanks.
Alex
mensa...@aol.com
> mensa...@aol.com <mensa...@aol.com> wrote:
> ...
> > > > I just tried it and found out it's not compatible with gmpy.
> > >
> > > By "it" do you mean Decimal, or Python 2.4 alpha 2?
> >
> > By "it", I meant gmpy 1.0 and Python 2.4. Trying to import the
> > module says it can't use the Python23.dll.
>
> _Any_ binary extension Python module compiled for Python 2.3 cannot
even
> load (on Windows) with Python 2.4 -- this has always been true on
> Windows between any two releases of Python and will presumably
continue
> to be so for the foreseeable future.
What I meant was the OP can't compare Decimal and gmpy unless he has
a version of gmpy that runs in 2.4. Or has a version of Decimal that
runs in 2.3.
>
> This doesn't mean that Python 2.4 "is not compatible with gmpy" or
> viceversa: it just means you obviously need to use a gmpy binary (pyd
> file) compiled for the version of Python you're using. Just as it
would
> be the case for any other binary extension module whatsoever.
I didn't mean it wasn't compatible. I meant you can't use the
2.3 version of gmpy in the 2.4 alpha that's currently available,
so I can't experiment with 2.4 because all my interesting programs
are dependant on gmpy. Not everyone is a professional software
developer, some of us ignorant users need to be told that.
>
> Unfortunately, compiling any binary extension module on Windows for
> Python 2.4 requires Microsoft's very latest C++ compiler -- I do not
own
> a copy, nor do I have any PC normally running Windows XP, which is
> required to run that compiler. Until Pyhon 2.3, I made do with a
> Windows 98 session running under win4lin on one of my Linux machines,
> and good old Microsoft Visual C++ 6 -- but such limited resources are
> not sufficient any longer to compile Python binary extension modules
for
> Python 2.4. Since in terms of income-making (as well as leisure;-) I
> work by now only on MacOSX, Linux, and OpenBSD machines, I am not
going
> to buy a PC loaded with Microsoft software just to be able to donate
> precompiled Python binary extension modules to Windows users.
How feasible is it that the end user could compile it himself?
Would the command line c compiler from the MS SDK suffice or do you
have to purchase the full .NET package? Would the source files need
a lot of tweaking?
>
>
> > > I think gmpy should
> > > build happily with the latter,
> >
> > I'm using the pre-built Windows binary distribution. I wouldn't
> > know how to re-build it. I assume that when Python 2.4 is final,
> > I newer compatible version of gmpy will become available.
>
> Not by magic -- I hope somebody out there owns all the needed
Microsoft
> software and is interested in compiling gmpy for Windows under Python
> 2.4 and making it available, but it won't be me.
Unfortunately, us ignorant end users depend on the magic that is
supplied by others. But that doesn't mean we're unwilling to help.
I had no clue that there won't be any more Windows gmpy updates
unless someone volunteers to help.
I've got an XP machine and given a choice between abandoning Python
completely and getting a copy of the MS compiler...
Of course, I realize that handing someone a box of wrenches doesn't
make them a mechanic. But we always have this newsgroup. I would
rather try and fail than see gmpy whither away from lack of interest.
Batista, Facundo
#- What I meant was the OP can't compare Decimal and gmpy unless he has
#- a version of gmpy that runs in 2.4. Or has a version of Decimal that
#- runs in 2.3.
Decimal is designed to work in Py2.3 and it will be maintained that way.
. Facundo
Alex Martelli
...
> > > > > I just tried it and found out it's not compatible with gmpy.
> What I meant was the OP can't compare Decimal and gmpy unless he has
> a version of gmpy that runs in 2.4. Or has a version of Decimal that
> runs in 2.3.
Or both 2.3 and 2.4 installed (they coexist).
> I didn't mean it wasn't compatible. I meant you can't use the
Sorry, I read "it's not compatible" as meaning what it says!-)
> 2.3 version of gmpy in the 2.4 alpha that's currently available,
Not the pre-built version, no.
> so I can't experiment with 2.4 because all my interesting programs
> are dependant on gmpy. Not everyone is a professional software
> developer, some of us ignorant users need to be told that.
I'm not sure what being a professional has to do with it -- it's more an
issue of being or not familiar with the specific issues of C-coded
Python extension on Windows.
> > Unfortunately, compiling any binary extension module on Windows for
> > Python 2.4 requires Microsoft's very latest C++ compiler -- I do not
...
> How feasible is it that the end user could compile it himself?
As long as the end user has a correctly installed and compatible
compiler, running "python setup.py install" in the directory where the
gmpy sources have been unpacked (and running it with the version of
Python one wants to build for) is all it takes, so I would say
"perfectly feasible".
> Would the command line c compiler from the MS SDK suffice or do you
> have to purchase the full .NET package? Would the source files need
> a lot of tweaking?
I predict no need for tweaking. I'm not sure what the support for the
MS SDK compiler is currently -- maybe somebody with more current Windows
knowledge can chime in? It used to be that the free C compiler had no
optimization, thus the resulting gmpy would be substantially slower, but
I don't even know if that is still currently the case or not.
> > Not by magic -- I hope somebody out there owns all the needed
> Microsoft
> > software and is interested in compiling gmpy for Windows under Python
> > 2.4 and making it available, but it won't be me.
>
> Unfortunately, us ignorant end users depend on the magic that is
> supplied by others. But that doesn't mean we're unwilling to help.
> I had no clue that there won't be any more Windows gmpy updates
> unless someone volunteers to help.
...or unless I happen to get any kind of paid consultancy contract which
requires me to have the latest MS tools, so I can justify purchasing
them (and a PC to run them on, but that's the least of issues). A
couple of years ago I still made a substantial amount of my income
testing/delivering on Windows, but at the time Win98 (running on win4lin
on my Linux box) and MSVC++6 were sufficient for my clients'
requirements; and lately I've had not much demand for Windows work --
MacOSX, Linux and OpenBSD are it. But that could change, of course,
e.g. if IronPython turns out to be as big as it seems it might become, I
could get to consult on programs using it (and I doubt they'll use Mono
-- MS dotnet will no doubt be required...).
> I've got an XP machine and given a choice between abandoning Python
> completely and getting a copy of the MS compiler...
>
> Of course, I realize that handing someone a box of wrenches doesn't
> make them a mechanic. But we always have this newsgroup. I would
> rather try and fail than see gmpy whither away from lack of interest.
I'm quite willing to offer any help, short of purchasing tools I don't
otherwise need, to make gmpy run on all sorts of platforms, whether I
use them myself or not.
> > > Were you aware that there is apparently a memory leak in the
> > > gmpy.divm() function? Calling it several million time caused my
> > > computer to run out of virtual memeory. Luckily, I was able to
> > > work around it using the gmpy.invert() which didn't consume any
> > > memory regardless of how many times it was called.
> >
> > No, I was not aware of that -- I'll look into it, thanks.
I'm still not aware of any bug in gmpy because I can't reproduce your
observation (on MacOSX 10.3.5, Python 2.3). Try this script...:
import gmpy
tot = 0
while True:
n = input('How many more divm: ')
if n<=0: break
print '%d more...' % n,
for i in xrange(n): gmpy.divm(3,7,9)
tot += n
print '...total %d' % tot
I've used it to perform millions of divm calls and I monitor its virtual
memory usage from the outside, and absolutely no leak shows up. Maybe
it's in the Windows version of the underlying GMP library...? Can any
other gmpy user try this out and report...? Thanks!
Alex
Alex Martelli
I think that's an excellent policy -- Python 2.3 will no doubt remain
widely used for a long time to come. I think it would be nice if
Decimal was packaged up with its own docs for easy download and install
into an existing 2.3 installation, then... make life as easy as possible
for 2.3 users who need to do some decimal arithmetic!
Alex
Anthony Baxter
(VS7.1) and get them to do:
% python setup.py install
% python setup.py bdist_wininst
and then make the windows installer for the gmpy module available.
My understanding is that building 2.4 modules with either mingw or the
freely available MS compiler is still a non-trivial exercise - but
there's enough people interested in this that I suspect it will be
resolved soon enough.
Alex Martelli
> Another approach is to find someone with the appropriate toolchain
> (VS7.1) and get them to do:
>
> % python setup.py install
> % python setup.py bdist_wininst
>
> and then make the windows installer for the gmpy module available.
Sounds good -- are you volunteering?-)
> My understanding is that building 2.4 modules with either mingw or the
> freely available MS compiler is still a non-trivial exercise - but
> there's enough people interested in this that I suspect it will be
> resolved soon enough.
Thanks for the info! And let's indeed hope things get better... if
mingw sufficed I could use it on my old trusty Win98-on-Win4Lin-
on-Linux setup, for example (gmpy does need speed, so maybe it's best to
build it with the best optimizing compiler available, but other modules
may not be quite as speed-critical as that).
Alex
mensa...@aol.com
I tracked your program with Windows task manager and it show a nice
flat memory useage trace. Memory usage started at 185244K and peaked
at 185366K for 10000000 iterations.
Try using larger numbers:
import gmpy
tot = 0
while True:
n = input('How many more divm: ')
if n<=0: break
print '%d more...' % n,
for i in xrange(n): gmpy.divm(81287570543,8589934592,3486784401)
tot += n
print '...total %d' % tot
"""
memory usage trace rocketed upwards at a 45 degree angle.
C:\Python23\user\the_full_monty>python gmpytest.py
How many more divm: 10000000
10000000 more...Fatal Python error: mp_allocate failure
abnormal program termination
peak Commit Charge (K): 792556
"""
David Bolen
> Another approach is to find someone with the appropriate toolchain
> (VS7.1) and get them to do:
>
> % python setup.py install
> % python setup.py bdist_wininst
Note that in the current 2.4 alpha 2, there's a bug in bdist_wininst
that causes that to barf. I went to file a bug report, but it looks
like it was already fixed a few weeks ago in CVS, but in order for
that to work with alpha 2, you need to tweak the bdist_wininst.py
module to actually return installer_name from the get_installer_name
method. Of course, if alpha 3 shows up tomorrow a per Guido's recent
note, this is a moot point :-)
-- David
Andrew Durdin
> mensa...@aol.com <mensa...@aol.com> wrote:
> ...
>
> MS SDK compiler is currently -- maybe somebody with more current Windows
> knowledge can chime in? It used to be that the free C compiler had no
> optimization, thus the resulting gmpy would be substantially slower, but
> I don't even know if that is still currently the case or not.
No: "Microsoft C/C++ Optimizing Compiler and Linker. These are the
same compiler and linker that ship with Visual Studio .NET 2003
Professional!"
--from the (free-of-charge) Visual C++ Toolkit 2003 page at
http://msdn.microsoft.com/visualc/vctoolkit2003/
Michael Foord
Can someone pelase clarify this for me.
Will having this compiler allow python distutils to automagically
compile extension modules without complaining it needs MSVC7 *and*
without tweaking distutils.... ?? (some hope really !!)
If not - what is the magic needed in distutils to make it use it ?
Is the quality of machine code emitted by this compiler any 'better'
than GCC - is this a matter of fact or opinion ?
The difficulty of compiling extensions for windows is still a 'python
wart'. If one goes through the various incantations necesary to use
gcc under mingw then it 'just works' for python 2.3 but it's still
tricky for the newbie to set up and I've heard rumblings that it might
not be possible for 2.4 (which I'm sure is wrong but there we go).
Regards,
Fuzzy
David Bolen
> On Wed, 1 Sep 2004 11:15:29 +0200, Alex Martelli <ale...@yahoo.com> wrote:
> > mensa...@aol.com <mensa...@aol.com> wrote:
> > ...
> >
> > I predict no need for tweaking. I'm not sure what the support for the
> > MS SDK compiler is currently -- maybe somebody with more current Windows
> > knowledge can chime in? It used to be that the free C compiler had no
> > optimization, thus the resulting gmpy would be substantially slower, but
> > I don't even know if that is still currently the case or not.
>
> No: "Microsoft C/C++ Optimizing Compiler and Linker. These are the
> same compiler and linker that ship with Visual Studio .NET 2003
> Professional!"
Yes, but the next bullet on the MS site says:
C Runtime Library and the C++ Standard Library, including the Standard
Template Library. These are the same static-link libraries included
with Visual Studio.
Note the "static-link" part. I don't believe the free compiler comes
with support for building dynamically linked (to the C library)
applications, which is what Python extensions are.
-- David
Mike C. Fletcher
...
>Can someone pelase clarify this for me.
>Will having this compiler allow python distutils to automagically
>compile extension modules without complaining it needs MSVC7 *and*
>without tweaking distutils.... ?? (some hope really !!)
>
>
There's some minor tweaking of distutils required. See the instructions
here:
http://www.vrplumber.com/programming/mstoolkit/
it's not the most convenient situation in the world, but it's doable for
people who are comfortable with a bit of hacking around.
As of yet I've had precisely no-one confirm (or deny, or even mention
trying and failing, for that matter) that they too have been able to use
the process to compile a module, but it seems to work fine with the
modules I've tested.
Have fun,
Mike
________________________________________________
Mike C. Fletcher
Designer, VR Plumber, Coder
http://www.vrplumber.com
http://blog.vrplumber.com
Richie Hindle
[David]
> Note the "static-link" part. I don't believe the free compiler comes
> with support for building dynamically linked (to the C library)
> applications, which is what Python extensions are.
It doesn't directly support the runtime DLL because it doesn't ship with the
import library for it, but the import library is available as part of the
.NET Framework SDK. Mike Fletcher has a HOWTO here:
http://www.vrplumber.com/programming/mstoolkit/index.html
which says "This document describes the process of building Python 2.4
binary extensions with the (free) Microsoft Visual C++ Toolkit Compiler."
--
Richie Hindle
ric...@entrian.com
Mike C. Fletcher
...
>Yes, but the next bullet on the MS site says:
>
> C Runtime Library and the C++ Standard Library, including the Standard
> Template Library. These are the same static-link libraries included
> with Visual Studio.
>
>Note the "static-link" part. I don't believe the free compiler comes
>with support for building dynamically linked (to the C library)
>applications, which is what Python extensions are.
>
>
The compiler package doesn't include the lib needed for the dynamic
modules, but the compiler itself has support *if* you have that library
available, and the .NET Framework SDK has the library. Again, see
http://www.vrplumber.com/programming/mstoolkit/ for all the gory details.
Enjoy,
Michael Foord
> Michael Foord wrote:
> ...
>
> >Can someone pelase clarify this for me.
> >Will having this compiler allow python distutils to automagically
> >compile extension modules without complaining it needs MSVC7 *and*
> >without tweaking distutils.... ?? (some hope really !!)
> >
> >
> There's some minor tweaking of distutils required. See the instructions
> here:
>
> http://www.vrplumber.com/programming/mstoolkit/
>
> it's not the most convenient situation in the world, but it's doable for
> people who are comfortable with a bit of hacking around.
>
> As of yet I've had precisely no-one confirm (or deny, or even mention
> trying and failing, for that matter) that they too have been able to use
> the process to compile a module, but it seems to work fine with the
> modules I've tested.
>
> Have fun,
> Mike
>
Aha... this looks like exactly the answer I was looking for.. and more.
Thanks
Fuzzyman
http://www.voidspace.org.uk/atlantibots/pythonutils.html