Python-Dev October 2004

python-dev@python.org

105 participants
98 discussions

by A.B., Khalid

[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/

16 years, 4 months

2.4b1 release, this Friday (AU time) -- imminent TRUNK FREEZING

by Anthony Baxter

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.

16 years, 4 months

Re: [Python-checkins] python/dist/src/Lib subprocess.py, NONE, 1.1

by Thomas Heller

effbot(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Lib > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24287/Lib > > Added Files: > subprocess.py > Log Message: > Added Peter Astrand's subprocess module. I suggest to remove the imports of the pywin32 stuff, it's not needed and confuses tools like freeze or py2exe. if mswindows: import threading import msvcrt try: from _subprocess import * class STARTUPINFO: dwFlags = 0 hStdInput = None hStdOutput = None hStdError = None class pywintypes: error = IOError except ImportError: import pywintypes from win32api import GetStdHandle, STD_INPUT_HANDLE, \ STD_OUTPUT_HANDLE, STD_ERROR_HANDLE from win32api import GetCurrentProcess, DuplicateHandle, \ GetModuleFileName, GetVersion from win32con import DUPLICATE_SAME_ACCESS from win32pipe import CreatePipe from win32process import CreateProcess, STARTUPINFO, \ GetExitCodeProcess, STARTF_USESTDHANDLES, \ CREATE_NEW_CONSOLE from win32event import WaitForSingleObject, INFINITE, WAIT_OBJECT_0

16 years, 4 months

Re: [Python-checkins] python/dist/src/Lib/distutils/command __init__.py, 1.19, 1.20 install.py, 1.70, 1.71 checkdep.py, 1.1, NONE

by Fred L. Drake, Jr.

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>

16 years, 4 months

test_cwd of test_subprocess.py fails on Win98

by Khalid A. B.

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/

16 years, 4 months

test_cwd of test_subprocess.py fails on Win98

by Khalid A. B.

Hello On Win98 test_cwd of test_subprocess.py tries to assert that "C:\WINDOWS\TEMP" is equal to "C:\WINDOWS\Temp" but since "TEMP" != "Temp" it fails, even when they are the same directory. 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 >>> 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/

16 years, 4 months

test_pep263.py is "-kb" in CVS

by Michael Hudson

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"

16 years, 4 months

subprocess module test failure when --with-pydebug

by Barry Warsaw

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

16 years, 4 months

Re: [Python-Dev] test_pep263.py is "-kb" in CVS

by Guido van Rossum

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/)

16 years, 4 months

RE: [Python-Dev] scropion

by Michael Chermside

> [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

16 years, 4 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev October 2004