[Alexandre Parenteau]
>...
>- The ISS files (Inno) do not seem up to date.Is anybody having a ISS
>version of the installer which works for 2.3.4?
Hello Alex,
I have been working on and off on an Inno-Setup installer for the MinGW
compiled
Python I've been working on. The reason being I have Win98 so the Msi.py
approach does not work.
The script is still not finished, nor is it identical to setup script found
in the
Python 2.3.4 sources. Moreover, it does not make any registry entries yet,
which I am thinking and hoping of doing either through a Python script
(which runs after install is finished and before uninstall is started) or an
external DLL so as to be able to revert changes.
But even in its current unfinished form, the script works for me in that it
gathers
all of the needed Python 2.3.4 files into one package and offers to install
Python
and Python's extensions, and uninstalls the files as needed. All the
regrtest
tests pass when Python 2.3.4 is installed from that script.
One can run Python's scripts from the DOS Shell and if file association is
urgently needed then hints from the Python.iss found in the original Python
source distribution can be of immediate help.
Get it here (3.49 KB):
http://jove.prohosting.com/iwave/ipython/Inno-Python234.zip
Regards
Khalid
PS: I have pymingw.py which is enclosed in the zip file where I have
python23.dll and friends. It will be picked up by the script
from there and placed in site-packages for use when uninstalling
Python.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.com/
Ok, I'm going to be cutting the Python release Friday (Australian
time). This means that I'm declaring the trunk frozen for the release
in about 24 hours. Lets say at 18:00 hours UTC on Thursday 14th
(that's 14:00 on the US east coast, if my memory is correct, and
about 04:00 where here in Australia).
No-one except for the usual team (Fred, Martin, myself) should check
into the trunk after that. As per usual, I'll probably keep the trunk
frozen for a time after the release, in case of brown-paper-bag issues.
Note that this is the last chance you have to get those behaviour-
changing bugs^Wfixes introduced, so get to it! After b1, it will
become _much_ harder to get new fixes introduced.
And if there's a pending bug or patch that needs some lovin', add
a comment to it or mail me - I think I've responded to, or fixed,
all the ones I've been told about, but if I missed one, tell me
now.
Anthony
--
Anthony Baxter <anthony(a)interlink.com.au>
It's never too late to have a happy childhood.
On Wednesday 13 October 2004 08:35 am, Anthony Baxter wrote:
> Backing out the basic dependency checking (from pycon sprint).
> This support was only a first cut, and doesn't deserve to be in
> a released version (where we have to support it in an ongoing
> manner)
Thanks, Anthony!
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
Hello.
The test fails because it seems to be comparing "C:\WINDOWS\TEMP" with
"C:\WINDOWS\Temp" and even though they are the same thing in Win98,
they are of cource not equal.
Details follow:
$ python -i
Python 2.4a3 (#56, Oct 13 2004, 02:29:05)
[GCC 3.4.1 (mingw special)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>import os, sys, subprocess
>>>tmpdir = os.getenv("TEMP", "/tmp")
>>>tmpdir = os.path.realpath(tmpdir)
>>>tmpdir
'C:\\WINDOWS\\TEMP'
>>>p = subprocess.Popen([sys.executable, "-c",
... 'import sys,os;' \
... 'sys.stdout.write(os.getcwd())'],
... stdout=subprocess.PIPE,
... cwd=tmpdir)
>>>subProcessTmpDir = p.stdout.read()
>>>subProcessTmpDir
'C:\\WINDOWS\\Temp'
>>>tmpdir == subProcessTmpDir
False
>>>
Although I don't know if this will work in other versions of Windows,
here is what fixed it for me:
Index: python/dist/src/Lib/test/test_subprocess.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/Lib/test/test_subprocess.py,v
retrieving revision 1.4
diff -u -d -r1.4 test_subprocess.py
--- python/dist/src/Lib/test/test_subprocess.py 12 Oct 2004 22:29:54
-0000 1.4
+++ python/dist/src/Lib/test/test_subprocess.py 13 Oct 2004 02:27:13 -0000
@@ -192,9 +192,16 @@
def test_cwd(self):
tmpdir = os.getenv("TEMP", "/tmp")
tmpdir = os.path.realpath(tmpdir)
- p = subprocess.Popen([sys.executable, "-c",
- 'import sys,os;' \
- 'sys.stdout.write(os.getcwd())'],
+ commandStr = [sys.executable, "-c"]
+ if mswindows:
+ tmpdir = tmpdir.upper()
+ commandStr.append('import sys,os;' \
+ 'sys.stdout.write(os.getcwd().upper())')
+ else:
+ commandStr.append('import sys,os;' \
+ 'sys.stdout.write(os.getcwd())')
+
+ p = subprocess.Popen(commandStr,
stdout=subprocess.PIPE,
cwd=tmpdir)
self.assertEqual(p.stdout.read(), tmpdir)
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.com/
As subject. Is this deliberate? It breaks test_compiler, though
that's possibly a bug because test_compiler should be using universal
newlines modes when opening the file, but still...
Cheers,
mwh
--
The word "Fascism" has now no meaning except in so far as it
signifies 'something not desirable'.
-- George Orwell in "Politics and the English Language"
The new subprocess module test is not compatible with a Python built
--with-pydebug because the [xxxx refs] output breaks the comparison.
I've recently been thinking that it would be nice if that [xxxx refs]
output could be suppressed with an envar or a command line switch.
FWIW, I generally build our embedding product with a --with-pydebug
built Python and that output breaks our unit tests too. I work around
this by suppressing the stderr comparison in our testing framework.
Once we decide to do it, and what to wrap that call in, it's likely a
one or two line change to pythonrun.c. Does one of the existing envars
make sense to use?
Barring any change here, we need to at least make sure the subprocess
test doesn't fail for a debug build.
-Barry
In any case, the necessity of -kb for this file (if it is still
necessary) should be documented in a comment inside the file, to
prevent a repeat of this discussion three years from now.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
> [Paul introduces himself]
> My question is for performance: isn't binary code faster than p code?
> So If I can vote, I would vote for c or c++ in the numerics functions and
> data transfer areas.
> even assembler. The quicker the better.
Hello, and welcome.
Thanks for your input on what kinds of things you value in Python. (The
Python developers, who use the python-dev list) DO pay attention to such
opinion (although don't expect sudden changes... you are one in a sea of
users). You are not alone in caring about performance -- it's been a
popular topic lately.
I'll comment briefly on your specific suggestions. Binary code is faster
than "p code" usually, but in some cases the "p code" is more ammenable
to automated optimization. That is why certain kinds of code can run
FASTER in java than in C. Python code too will often run faster than the
equivalent C code... not because of a powerful just-in-time optimizer,
but because the Python code is written using better algorithms and data
structures than one would bother with in C.
But you specifically mention numerics functions and data transfer...
two areas where well-written C code is likely to be much better
performing. We certainly share the goal of better performance (so long
as it doesn't come at the cost of other things like usability and
maintainability). If you know of some specific areas where we could
improve, please submit a patch (through SourceForge's patch manager) --
we'd love to have the help!
Finally, you mention the possibility of dropping into assembler.
Unfortunately, this is sure to be rejected because it conflicts with an
important design principle -- Python is designed to be VERY portable,
and should compile on just about any system with a standards-compliant
C compiler.
-- Michael Chermside