From noreply@sourceforge.net Fri Feb 1 01:04:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 31 Jan 2002 17:04:21 -0800 Subject: [Patches] [ python-Patches-511380 ] add CGIHTTPServer error supt for Win32 Message-ID: Patches item #511380, was opened at 2002-01-31 11:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511380&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Wesley J. Chun (wesc) Assigned to: Nobody/Anonymous (nobody) Summary: add CGIHTTPServer error supt for Win32 Initial Comment: Patch suggestion for CGIHTTPServer.py in the Python Standard Library: "add CGIHTTPServer error supt for Win32" by Wesley J. Chun (wesc@rocketmail.com) Python 2.2: Win32 and Unix (Solaris 2.8) Description =========== The CGIHTTPServer module uses the fork() mechanism provided by Unix to run the CGI script, however, since the Win32 platform does not support fork(), CGIHTTPServer relies on os.popen2() to execute the process and to retrieve the results. This all works however, when you are debugging CGI applications, the information provided by os.popen2() does not suffice because execution errors (i.e., Python tracebacks) are sent to standard error, which are ignored by os.popen2(). The suggested patch is to check first if os.popen3() is available to us (otherwise do the normal check for os.popen2()). If we have access to os.popen3(), use it instead and log any errors which appear via the child's stderr. Without the patch, it makes it much more difficult to debug the same CGI application when run on Win32 because no errors are made apparent in the error log. Examples below -- first a successful call is made (200), followed by a failed call due to a Python error, resulting in a 500 (ISE) appearing back on the web client. The patch would bring the Win32 execution of CGIHTTPServer much closer to its Unix counterpart. A 3-line diff of the changes is available just below the examples. (This patch is valid for all 2.x releases and may be backported to the 2.[012].x releases if necessary.) Unix ==== ** NO PATCH NEEDED ** # cgihttpd.py # from CGIHTTPServer import test; test() Serving HTTP on port 8000 ... localhost - - [30/Jan/2002 10:13:20] "GET /cgi- bin/rwrl.py?admin=1 HTTP/1.0" 200 - Traceback (most recent call last): File "/home/wesc/public_html/cgi-bin/rwrl.py", line 177, in ? main() File "/home/wesc/public_html/cgi-bin/rwrl.py", line 153, in main cd = tag % ('date', title, 'date') UnboundLocalError: local variable 'title' referenced before assignment localhost - - [30/Jan/2002 10:13:20] CGI script exit status 0x100 Windoze ======= ** BEFORE PATCH ** C:\dev>python cgihttpd.py Serving HTTP on 0.0.0.0 port 8000 ... solo - - [30/Jan/2002 21:37:27] "GET /cgi-bin/rwrl.py? admin=-1 HTTP/1.1" 200 - solo - - [30/Jan/2002 21:37:27] command: c:\python22 \python.exe -u C:\dev\cgi-bin\rwrl.py solo - - [30/Jan/2002 21:37:28] CGI script exit status 0x1 ** AFTER PATCH ** C:\dev>python cgihttpd.py Serving HTTP on 0.0.0.0 port 8000 ... solo - - [30/Jan/2002 21:46:22] "GET /cgi-bin/rwrl.py? admin=-1 HTTP/1.1" 200 - solo - - [30/Jan/2002 21:46:22] command: c:\python22 \python.exe -u C:\dev\cgi-bin\rwrl.py solo - - [30/Jan/2002 21:46:23] Traceback (most recent call last): File "C:\dev\cgi-bin\rwrl.py", line 178, in ? main() File "C:\dev\cgi-bin\rwrl.py", line 160, in main cd = tag % ('date', title, 'date') UnboundLocalError: local variable 'title' referenced before assignment solo - - [30/Jan/2002 21:46:23] CGI script exit status 0x1 DIFF -C3 ======== % diff -C3 CGIHTTPServer.py.CVS CGIHTTPServer.py.new *** CGIHTTPServer.py.CVS Fri Oct 26 03:38:14 2001 UTC --- CGIHTTPServer.py.new Thu Jan 31 10:58:16 2002 PST *************** *** 41,46 **** --- 41,47 ---- # Determine platform specifics have_fork = hasattr(os, 'fork') have_popen2 = hasattr(os, 'popen2') + have_popen3 = hasattr(os, 'popen3') # Make rfile unbuffered -- we need to read one line and then pass # the rest to a subprocess, so we can't use buffered input. *************** *** 123,129 **** return ispy = self.is_python(scriptname) if not ispy: ! if not (self.have_fork or self.have_popen2): self.send_error(403, "CGI script is not a Python script (%s)" % `scriptname`) return --- 124,130 ---- return ispy = self.is_python(scriptname) if not ispy: ! if not (self.have_fork or self.have_popen2 or self.have_popen3): self.send_error(403, "CGI script is not a Python script (%s)" % `scriptname`) return *************** *** 214,222 **** self.server.handle_error (self.request, self.client_address) os._exit(127) ! elif self.have_popen2: ! # Windows -- use popen2 to create a subprocess import shutil os.environ.update(env) cmdline = scriptfile if self.is_python(scriptfile): --- 215,227 ---- self.server.handle_error (self.request, self.client_address) os._exit(127) ! elif self.have_popen3 or self.have_popen2: ! # Windows -- use popen2 or popen3 to create a subprocess import shutil + if self.have_popen3: + cmd = os.popen3 + else: + cmd = os.popen2 os.environ.update(env) cmdline = scriptfile if self.is_python(scriptfile): *************** *** 232,238 **** nbytes = int(length) except: nbytes = 0 ! fi, fo = os.popen2(cmdline, 'b') if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) fi.write(data) --- 237,247 ---- nbytes = int(length) except: nbytes = 0 ! files = cmd(cmdline, 'b') ! fi = files[0] ! fo = files[1] ! if self.have_popen3: ! fe = files[2] if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) fi.write(data) *************** *** 239,244 **** --- 248,258 ---- fi.close() shutil.copyfileobj(fo, self.wfile) + if self.have_popen3: + anyerr = fe.read() + fe.close() + if anyerr: + self.log_error('%s', anyerr) sts = fo.close() if sts: self.log_error("CGI script exit status %#x", sts) else: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511380&group_id=5470 From noreply@sourceforge.net Fri Feb 1 16:30:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Feb 2002 08:30:09 -0800 Subject: [Patches] [ python-Patches-511380 ] add CGIHTTPServer error supt for Win32 Message-ID: Patches item #511380, was opened at 2002-01-31 11:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511380&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Wesley J. Chun (wesc) >Assigned to: Guido van Rossum (gvanrossum) Summary: add CGIHTTPServer error supt for Win32 Initial Comment: Patch suggestion for CGIHTTPServer.py in the Python Standard Library: "add CGIHTTPServer error supt for Win32" by Wesley J. Chun (wesc@rocketmail.com) Python 2.2: Win32 and Unix (Solaris 2.8) Description =========== The CGIHTTPServer module uses the fork() mechanism provided by Unix to run the CGI script, however, since the Win32 platform does not support fork(), CGIHTTPServer relies on os.popen2() to execute the process and to retrieve the results. This all works however, when you are debugging CGI applications, the information provided by os.popen2() does not suffice because execution errors (i.e., Python tracebacks) are sent to standard error, which are ignored by os.popen2(). The suggested patch is to check first if os.popen3() is available to us (otherwise do the normal check for os.popen2()). If we have access to os.popen3(), use it instead and log any errors which appear via the child's stderr. Without the patch, it makes it much more difficult to debug the same CGI application when run on Win32 because no errors are made apparent in the error log. Examples below -- first a successful call is made (200), followed by a failed call due to a Python error, resulting in a 500 (ISE) appearing back on the web client. The patch would bring the Win32 execution of CGIHTTPServer much closer to its Unix counterpart. A 3-line diff of the changes is available just below the examples. (This patch is valid for all 2.x releases and may be backported to the 2.[012].x releases if necessary.) Unix ==== ** NO PATCH NEEDED ** # cgihttpd.py # from CGIHTTPServer import test; test() Serving HTTP on port 8000 ... localhost - - [30/Jan/2002 10:13:20] "GET /cgi- bin/rwrl.py?admin=1 HTTP/1.0" 200 - Traceback (most recent call last): File "/home/wesc/public_html/cgi-bin/rwrl.py", line 177, in ? main() File "/home/wesc/public_html/cgi-bin/rwrl.py", line 153, in main cd = tag % ('date', title, 'date') UnboundLocalError: local variable 'title' referenced before assignment localhost - - [30/Jan/2002 10:13:20] CGI script exit status 0x100 Windoze ======= ** BEFORE PATCH ** C:\dev>python cgihttpd.py Serving HTTP on 0.0.0.0 port 8000 ... solo - - [30/Jan/2002 21:37:27] "GET /cgi-bin/rwrl.py? admin=-1 HTTP/1.1" 200 - solo - - [30/Jan/2002 21:37:27] command: c:\python22 \python.exe -u C:\dev\cgi-bin\rwrl.py solo - - [30/Jan/2002 21:37:28] CGI script exit status 0x1 ** AFTER PATCH ** C:\dev>python cgihttpd.py Serving HTTP on 0.0.0.0 port 8000 ... solo - - [30/Jan/2002 21:46:22] "GET /cgi-bin/rwrl.py? admin=-1 HTTP/1.1" 200 - solo - - [30/Jan/2002 21:46:22] command: c:\python22 \python.exe -u C:\dev\cgi-bin\rwrl.py solo - - [30/Jan/2002 21:46:23] Traceback (most recent call last): File "C:\dev\cgi-bin\rwrl.py", line 178, in ? main() File "C:\dev\cgi-bin\rwrl.py", line 160, in main cd = tag % ('date', title, 'date') UnboundLocalError: local variable 'title' referenced before assignment solo - - [30/Jan/2002 21:46:23] CGI script exit status 0x1 DIFF -C3 ======== % diff -C3 CGIHTTPServer.py.CVS CGIHTTPServer.py.new *** CGIHTTPServer.py.CVS Fri Oct 26 03:38:14 2001 UTC --- CGIHTTPServer.py.new Thu Jan 31 10:58:16 2002 PST *************** *** 41,46 **** --- 41,47 ---- # Determine platform specifics have_fork = hasattr(os, 'fork') have_popen2 = hasattr(os, 'popen2') + have_popen3 = hasattr(os, 'popen3') # Make rfile unbuffered -- we need to read one line and then pass # the rest to a subprocess, so we can't use buffered input. *************** *** 123,129 **** return ispy = self.is_python(scriptname) if not ispy: ! if not (self.have_fork or self.have_popen2): self.send_error(403, "CGI script is not a Python script (%s)" % `scriptname`) return --- 124,130 ---- return ispy = self.is_python(scriptname) if not ispy: ! if not (self.have_fork or self.have_popen2 or self.have_popen3): self.send_error(403, "CGI script is not a Python script (%s)" % `scriptname`) return *************** *** 214,222 **** self.server.handle_error (self.request, self.client_address) os._exit(127) ! elif self.have_popen2: ! # Windows -- use popen2 to create a subprocess import shutil os.environ.update(env) cmdline = scriptfile if self.is_python(scriptfile): --- 215,227 ---- self.server.handle_error (self.request, self.client_address) os._exit(127) ! elif self.have_popen3 or self.have_popen2: ! # Windows -- use popen2 or popen3 to create a subprocess import shutil + if self.have_popen3: + cmd = os.popen3 + else: + cmd = os.popen2 os.environ.update(env) cmdline = scriptfile if self.is_python(scriptfile): *************** *** 232,238 **** nbytes = int(length) except: nbytes = 0 ! fi, fo = os.popen2(cmdline, 'b') if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) fi.write(data) --- 237,247 ---- nbytes = int(length) except: nbytes = 0 ! files = cmd(cmdline, 'b') ! fi = files[0] ! fo = files[1] ! if self.have_popen3: ! fe = files[2] if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) fi.write(data) *************** *** 239,244 **** --- 248,258 ---- fi.close() shutil.copyfileobj(fo, self.wfile) + if self.have_popen3: + anyerr = fe.read() + fe.close() + if anyerr: + self.log_error('%s', anyerr) sts = fo.close() if sts: self.log_error("CGI script exit status %#x", sts) else: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-01 08:30 Message: Logged In: YES user_id=6380 Thanks for the patch. Checked in with minor tweaks. Wes, can you check out that what I checked in works? I don't have a Windows box set up to test this right now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511380&group_id=5470 From noreply@sourceforge.net Fri Feb 1 23:29:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Feb 2002 15:29:04 -0800 Subject: [Patches] [ python-Patches-511962 ] Allow sys.setdlopenflags on OSX Message-ID: Patches item #511962, was opened at 2002-02-01 15:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511962&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Allow sys.setdlopenflags on OSX Initial Comment: This patch allows the use of sys.setdlopenflags() on MacOSX, to switch between modules loading into a private symbol table namespace (the default, 0) or into the global namespace (pass value 0x100, RTLD_GLOBAL on dlfcn.h-type systems). Posting it here as a patch because (a) I can't try myself whether it solves what it tries to solve and (b) it's a bit of a hack (on top of the setdlopenflags() method, which is a hack in itself) and I'd like feedback. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511962&group_id=5470 From noreply@sourceforge.net Sat Feb 2 02:41:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 01 Feb 2002 18:41:29 -0800 Subject: [Patches] [ python-Patches-512005 ] getrusage() returns struct-like object. Message-ID: Patches item #512005, was opened at 2002-02-01 18:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512005&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Nobody/Anonymous (nobody) Summary: getrusage() returns struct-like object. Initial Comment: The function resource.getrusage() now returns struct-like object (cf. os.stat() and time.gmtime()). This is my first patch for Python so please don't scorch me if something is wrong ;). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512005&group_id=5470 From noreply@sourceforge.net Sun Feb 3 00:23:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 02 Feb 2002 16:23:36 -0800 Subject: [Patches] [ python-Patches-512256 ] ceval micro optimizations Message-ID: Patches item #512256, was opened at 2002-02-02 16:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512256&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: ceval micro optimizations Initial Comment: These are good for a 5% speed increase according to pystone and pybench. Changes: - move common instructions to top of switch stmt - simplify SET_LINENO block by calling call_trace instead of inlining it - skip "things_to_do" block for a few ops that don't actually do any work (like SET_LINENO and POP_TOP). - tweak if statements so that GCC generates better code ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512256&group_id=5470 From isijang@hotmail.com Sun Feb 3 07:52:43 2002 From: isijang@hotmail.com (i시장넷) Date: Sun, 3 Feb 2002 16:52:43 +0900 Subject: [Patches] ★★★[광고] 설날 선물 촉특가 판매 (단체주문 전문) Message-ID: 설이벤트
금산인삼한과선물셋트
지도표재래김완도돌김
표고버섯영지버섯세트
해표 식용유 선물세트
해표 참기름 선물세트
해표 북한산 참기름
농·수산물 식료품
생활용품
건강 · 미용 · 헤어용품
즐겨찾기에 등록하세요~
표고버섯조미료2호
27,000원
인삼종합한과세트
40,000원
전통민속차세트
10,800원
네떼루마니 B세트
72,600원
백화고 한지상자
100,000원
도브선물세트MD4
39,300원
참기름세트특5호
59,000원
지도표재래김(대)
25,000원

    귀하의 승락없이 홍보성 전자 우편을 보내게 된 점 정중히 사과 드립니다.
    저희는 귀하의 전자우편 주소 외 어떠한 개인정보도 가지고 있지 않으므로 안심하시기 바랍니다.
   이메일 수신을 원치 않으시면   를 클릭해 주십시요!   불편을 드려 죄송합니다.
    i시장넷 주문·상담 080-365-8589(080-365일-바로팔구)

From noreply@sourceforge.net Sun Feb 3 20:17:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Feb 2002 12:17:55 -0800 Subject: [Patches] [ python-Patches-512466 ] Script to move faqwiz entries. Message-ID: Patches item #512466, was opened at 2002-02-03 12:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512466&group_id=5470 Category: Demos and tools Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Christian Reis (kiko_async) Assigned to: Nobody/Anonymous (nobody) Summary: Script to move faqwiz entries. Initial Comment: Moves entries from one section (number actually) to another. Doesn't do anything smart like renumber questions, but at least it doesn't clobber them. Usage: blackjesus:~> ./move-faqwiz.sh 2\.1 3\.2 Moving FAQ question 02.001 to 03.002 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512466&group_id=5470 From noreply@sourceforge.net Sun Feb 3 21:18:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 03 Feb 2002 13:18:07 -0800 Subject: [Patches] [ python-Patches-509975 ] make python-mode play nice with gdb Message-ID: Patches item #509975, was opened at 2002-01-28 17:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=509975&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alex Coventry (alex_coventry) Assigned to: Nobody/Anonymous (nobody) Summary: make python-mode play nice with gdb Initial Comment: if you run gdb (and presumably other debuggers) while python-mode is loaded, the little arrow it uses to indicate the current position in the source code fails to appear. this is because the comint hook py-pdbtrack-track-stack-file wipes it out regardless of whether the current buffer process comes from python. hth. alex ---------------------------------------------------------------------- >Comment By: Alex Coventry (alex_coventry) Date: 2002-02-03 13:18 Message: Logged In: YES user_id=49686 sorry, somehow failed to include the diff :) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=509975&group_id=5470 From noreply@sourceforge.net Mon Feb 4 08:27:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Feb 2002 00:27:29 -0800 Subject: [Patches] [ python-Patches-511380 ] add CGIHTTPServer error supt for Win32 Message-ID: Patches item #511380, was opened at 2002-01-31 11:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511380&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 3 Submitted By: Wesley J. Chun (wesc) Assigned to: Guido van Rossum (gvanrossum) Summary: add CGIHTTPServer error supt for Win32 Initial Comment: Patch suggestion for CGIHTTPServer.py in the Python Standard Library: "add CGIHTTPServer error supt for Win32" by Wesley J. Chun (wesc@rocketmail.com) Python 2.2: Win32 and Unix (Solaris 2.8) Description =========== The CGIHTTPServer module uses the fork() mechanism provided by Unix to run the CGI script, however, since the Win32 platform does not support fork(), CGIHTTPServer relies on os.popen2() to execute the process and to retrieve the results. This all works however, when you are debugging CGI applications, the information provided by os.popen2() does not suffice because execution errors (i.e., Python tracebacks) are sent to standard error, which are ignored by os.popen2(). The suggested patch is to check first if os.popen3() is available to us (otherwise do the normal check for os.popen2()). If we have access to os.popen3(), use it instead and log any errors which appear via the child's stderr. Without the patch, it makes it much more difficult to debug the same CGI application when run on Win32 because no errors are made apparent in the error log. Examples below -- first a successful call is made (200), followed by a failed call due to a Python error, resulting in a 500 (ISE) appearing back on the web client. The patch would bring the Win32 execution of CGIHTTPServer much closer to its Unix counterpart. A 3-line diff of the changes is available just below the examples. (This patch is valid for all 2.x releases and may be backported to the 2.[012].x releases if necessary.) Unix ==== ** NO PATCH NEEDED ** # cgihttpd.py # from CGIHTTPServer import test; test() Serving HTTP on port 8000 ... localhost - - [30/Jan/2002 10:13:20] "GET /cgi- bin/rwrl.py?admin=1 HTTP/1.0" 200 - Traceback (most recent call last): File "/home/wesc/public_html/cgi-bin/rwrl.py", line 177, in ? main() File "/home/wesc/public_html/cgi-bin/rwrl.py", line 153, in main cd = tag % ('date', title, 'date') UnboundLocalError: local variable 'title' referenced before assignment localhost - - [30/Jan/2002 10:13:20] CGI script exit status 0x100 Windoze ======= ** BEFORE PATCH ** C:\dev>python cgihttpd.py Serving HTTP on 0.0.0.0 port 8000 ... solo - - [30/Jan/2002 21:37:27] "GET /cgi-bin/rwrl.py? admin=-1 HTTP/1.1" 200 - solo - - [30/Jan/2002 21:37:27] command: c:\python22 \python.exe -u C:\dev\cgi-bin\rwrl.py solo - - [30/Jan/2002 21:37:28] CGI script exit status 0x1 ** AFTER PATCH ** C:\dev>python cgihttpd.py Serving HTTP on 0.0.0.0 port 8000 ... solo - - [30/Jan/2002 21:46:22] "GET /cgi-bin/rwrl.py? admin=-1 HTTP/1.1" 200 - solo - - [30/Jan/2002 21:46:22] command: c:\python22 \python.exe -u C:\dev\cgi-bin\rwrl.py solo - - [30/Jan/2002 21:46:23] Traceback (most recent call last): File "C:\dev\cgi-bin\rwrl.py", line 178, in ? main() File "C:\dev\cgi-bin\rwrl.py", line 160, in main cd = tag % ('date', title, 'date') UnboundLocalError: local variable 'title' referenced before assignment solo - - [30/Jan/2002 21:46:23] CGI script exit status 0x1 DIFF -C3 ======== % diff -C3 CGIHTTPServer.py.CVS CGIHTTPServer.py.new *** CGIHTTPServer.py.CVS Fri Oct 26 03:38:14 2001 UTC --- CGIHTTPServer.py.new Thu Jan 31 10:58:16 2002 PST *************** *** 41,46 **** --- 41,47 ---- # Determine platform specifics have_fork = hasattr(os, 'fork') have_popen2 = hasattr(os, 'popen2') + have_popen3 = hasattr(os, 'popen3') # Make rfile unbuffered -- we need to read one line and then pass # the rest to a subprocess, so we can't use buffered input. *************** *** 123,129 **** return ispy = self.is_python(scriptname) if not ispy: ! if not (self.have_fork or self.have_popen2): self.send_error(403, "CGI script is not a Python script (%s)" % `scriptname`) return --- 124,130 ---- return ispy = self.is_python(scriptname) if not ispy: ! if not (self.have_fork or self.have_popen2 or self.have_popen3): self.send_error(403, "CGI script is not a Python script (%s)" % `scriptname`) return *************** *** 214,222 **** self.server.handle_error (self.request, self.client_address) os._exit(127) ! elif self.have_popen2: ! # Windows -- use popen2 to create a subprocess import shutil os.environ.update(env) cmdline = scriptfile if self.is_python(scriptfile): --- 215,227 ---- self.server.handle_error (self.request, self.client_address) os._exit(127) ! elif self.have_popen3 or self.have_popen2: ! # Windows -- use popen2 or popen3 to create a subprocess import shutil + if self.have_popen3: + cmd = os.popen3 + else: + cmd = os.popen2 os.environ.update(env) cmdline = scriptfile if self.is_python(scriptfile): *************** *** 232,238 **** nbytes = int(length) except: nbytes = 0 ! fi, fo = os.popen2(cmdline, 'b') if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) fi.write(data) --- 237,247 ---- nbytes = int(length) except: nbytes = 0 ! files = cmd(cmdline, 'b') ! fi = files[0] ! fo = files[1] ! if self.have_popen3: ! fe = files[2] if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) fi.write(data) *************** *** 239,244 **** --- 248,258 ---- fi.close() shutil.copyfileobj(fo, self.wfile) + if self.have_popen3: + anyerr = fe.read() + fe.close() + if anyerr: + self.log_error('%s', anyerr) sts = fo.close() if sts: self.log_error("CGI script exit status %#x", sts) else: ---------------------------------------------------------------------- >Comment By: Wesley J. Chun (wesc) Date: 2002-02-04 00:27 Message: Logged In: YES user_id=445150 Just checked that the patch does work as advertised. -wjc ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-01 08:30 Message: Logged In: YES user_id=6380 Thanks for the patch. Checked in with minor tweaks. Wes, can you check out that what I checked in works? I don't have a Windows box set up to test this right now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511380&group_id=5470 From noreply@sourceforge.net Mon Feb 4 15:40:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Feb 2002 07:40:13 -0800 Subject: [Patches] [ python-Patches-512799 ] webchecker protocol bug Message-ID: Patches item #512799, was opened at 2002-02-04 07:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512799&group_id=5470 Category: Demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: seb bacon (sebbacon) Assigned to: Nobody/Anonymous (nobody) Summary: webchecker protocol bug Initial Comment: Tools/webchecker.py checks protocol of URLs and ignores redundant ones like mailto. However, urllib.splittype returns a tuple where the code expects a string, so it doesn't work. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512799&group_id=5470 From noreply@sourceforge.net Mon Feb 4 21:42:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 04 Feb 2002 13:42:20 -0800 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Tue Feb 5 10:20:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Feb 2002 02:20:54 -0800 Subject: [Patches] [ python-Patches-513235 ] prevent readline filename completion Message-ID: Patches item #513235, was opened at 2002-02-05 02:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513235&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: prevent readline filename completion Initial Comment: This patch is from Simon Budig, and despite him being too lazy to get an sf account, I think it should probably go in. --- readline.c.orig Sat Feb 2 21:44:09 2002 +++ readline.c Sat Feb 2 22:01:16 2002 @@ -346,6 +346,9 @@ lock released! */ save_tstate = PyThreadState_Swap(NULL); PyEval_RestoreThread(tstate); + /* Don't use the default filename completion if we + have a custom completion function... */ + rl_attempted_completion_over = 1; r = PyObject_CallFunction(completer, "si", text, state); if (r == NULL) goto error; afaict, rl_attempted_completion_over has been present in readline since 2.0. objections? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513235&group_id=5470 From noreply@sourceforge.net Tue Feb 5 10:35:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Feb 2002 02:35:29 -0800 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-02-05 02:35 Message: Logged In: YES user_id=6656 Comments: 1) in what ways does this change existing behaviour? I can think of a few, but are there any that will inconvenience existing users 2) why not do the rl_instream = PySys_GetObject("stdin") dance in call_readline()? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Tue Feb 5 15:51:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Feb 2002 07:51:42 -0800 Subject: [Patches] [ python-Patches-513329 ] build, install in HP-UX10.20 Message-ID: Patches item #513329, was opened at 2002-02-05 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513329&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Claudio Scafuri (scafuri) Assigned to: Nobody/Anonymous (nobody) Summary: build, install in HP-UX10.20 Initial Comment: a) python must be linked with c++ because at least one file is compiled with c++. b) in hpux "install -d" does not create a directory. Use "mkdir instead. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513329&group_id=5470 From unscribe127108@yahoo.com Tue Feb 5 17:08:47 2002 From: unscribe127108@yahoo.com (unscribe127108@yahoo.com) Date: Tue, 5 Feb 2002 17:8:47 +-0800 Subject: [Patches] 給幽閃� 쭌袍莘 穽赤攸� 脣 蓴諺寮狀� 紳翟贍茴迹 遵震 흡鎭存奄. Message-ID: <56706702@sidvd> 쿡鎖渾 鴨贓. 쭌袍壬 純夭陝療 穽抑乙侁奄�� 艙凹贍茴�� 脣傲跡狀增� 脣 日謫� 調� 敞言料嶢� 禎遵咸諺前潗 쭌袍莘 焌煜�. 經應姚裝 誼鴨� 禎 蓴諺� 麟宗 穽前桎 張 午筬� � 쭌袍� 穽赤攸�, 軸�� 脣傲跡狀 展孼� 腸輦筬秩� � 桎�, 破� 찰 穽抑乙侁奄�. 悸 穽抑前診瞬�諺 쭌� 艙凹贍茴策 脣傲跡狀增� 哀張增� 哀 쭌鋪� 禎鎭莊歪蟻裝� 幽猥粧荻 蓴� 張翟軸怏壬� 妖切鏃惺療. 經應姚裝 誼鴨� 了 鎭� 增調�, 惟桎終� 쭌� 妖鎭釣卽�, 禎懿妬� 쭌袍 炡贈溢 � 穽展嶢筬� 憶�, 魏� 憙� 遵暈葉 鴨乙奄� 찰. 匿��婆 鎭�, 惟莘 裔妖鎭釣櫛循依 쭌袍 穽抑依蓮杖�, 述藕寀 � 쭌麟 壯 竣�梧. 璥葺荻酷 調葺魂孺 禎 E-mail - 焌荏� 戱輒攸外裝� 楫前翟 釣幽閃�. 昆鋪 墮裝 � 魏輦佃 衆綵齧 翟莘循鳥循�秩� 渟猝佺贍茴�. 腦唯� 蓴憶菴 夭廬秩� 壯 穽賊剡� 竣臆猥 禎破荻酷 蓀晤(橓贈 麟�) � 脣傲跡狀增淆 述灑簇� 禎 誼灑� 增調張. 咬陷� 調傲儼 蓀晤 灑音� 25 麟應姚狀�. 쾰� 惟粧蟾診 � 壯麟 尿禎蟻奧煜� 鷺居干 ICQ. 悸 剪橓震� 壯 蓴� 쭌鋪 脣穽前�. UIN: 127108 콧牆�� 調葺魂魏 穽迪譽抑孼� � 櫛剪橓秩軫僚 � �.4 增.29 嵌章震膣打� 昑. 쭌� 凞焉疾佺裝� 雪釣� 禎懿特� 了 剪愉泓紅 尿桎杷凹荻 (哀仲� 翟��瞬孼僥) � 尿禎蟻奧奄�� 秧� 抑妖料狀� 哀增設孺 櫛翟緘杖�. � 衆綵齧 張蓮乙杖� 禎懿妬潗 惟壹儼特仲猥 穽抑依蓮杖�, 剪橓潗鎭 壯 憙� 炡贈溢 � 禎靭叱迹 � 屢靭 "REMOVE". 쭌� e-mail 修鴨� 昶贍孼 了 蓀晤. From noreply@sourceforge.net Tue Feb 5 18:21:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Feb 2002 10:21:17 -0800 Subject: [Patches] [ python-Patches-512981 ] readline /dev/tty problem Message-ID: Patches item #512981, was opened at 2002-02-04 13:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: readline /dev/tty problem Initial Comment: GNU readline doesn't work if the C symbol "stdin" is not a tty, even if the python symbol sys.stdin is. This will happen, for example, if a program initially receives input from a pipe, but then changes sys.stdin to read from /dev/tty. (This is how programs like "less" work) Here's a sample program that exhibits this behavior: ------------------------------------------------------------------------ #!/usr/bin/env python import sys mail = sys.stdin.read () sys.stdin = open ('/dev/tty', 'r') import readline foo = raw_input ('add_idea> ') print foo ------------------------------------------------------------------------ You can test this by saving the above program to a file (foo.py), piping data to it, then trying to use GNU readline editing commands at the prompt. E.g.: ------------------------------------------------------------------------ liberty:~$ cat ideas.html | ./foo.py add_idea> asdfsdf^Afoo asdfsdffoo ------------------------------------------------------------------------ The patch attached seems to fix the problem. You may want to grep the source for other modules that may have similar bugs. Also, this patch assumes that the readline module is imported *after* sys.stdin is changed. This much better than nothing (particularly if it's documented), but there may be a better solution. -- Agthorr ---------------------------------------------------------------------- >Comment By: Daniel Stutzbach (agthorr) Date: 2002-02-05 10:21 Message: Logged In: YES user_id=6324 1) Well, it lets python treat sys.stdin as a tty even if C stdin != python sys.stdin. It still checks to make sure sys.stdin is a tty using isatty(). If some user changes sys.stdin to point to a tty, but *wants* Python to treat it as a non-tty, then this might cause them some grief. I can't think of any case where they'd want to do that, though. The behavior would be unchanged when sys.stdin points to a regular file. 2) hmm.. I suppose, ideally, the readline module should smoothly handle sys.stdin being changed out from under it. Readline alters various terminal settings on rl_instream during initialization, though. For example, it changes the terminal to raw or cbreak mode from cooked mode, so that it can receive input a character at a time instead of a line at a time. It may be possible to uninitialized and reinitialized terminal each time call_readline is called, I suppose (I believe libreadline provides hooks for this). It would also have to check if sys.stdin is a tty, and call PyFile_GetLine if it is not. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-02-05 02:35 Message: Logged In: YES user_id=6656 Comments: 1) in what ways does this change existing behaviour? I can think of a few, but are there any that will inconvenience existing users 2) why not do the rl_instream = PySys_GetObject("stdin") dance in call_readline()? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512981&group_id=5470 From noreply@sourceforge.net Tue Feb 5 23:07:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Feb 2002 15:07:41 -0800 Subject: [Patches] [ python-Patches-502205 ] Fix webbrowser running on MachoPython Message-ID: Patches item #502205, was opened at 2002-01-10 22:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502205&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven J. Burr (sburrious) Assigned to: Jack Jansen (jackjansen) Summary: Fix webbrowser running on MachoPython Initial Comment: Allows webbrowser.open call in the Unix version of python running on Mac OS X to open a url in Internet Explorer. Presently, a call to webbrowser.open on this platform either runs a terminal-based browser, such as lynx, if available, or fails. The patch is a context diff against version 1.27 of webbrowser, which appears to be the latest version in CVS. It adds a MacOSX browser class and a test for Mac OS X systems running the Unix version of python. I have tested it successfully several times on my Mac OS X system. I included: assert url not in "'" from the 1.27 version in the MacOSX open method, even though the method calls os.popen rather than os.system to launch the browser. It seemed likely os.popen would raise similar security concerns. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-02-05 15:07 Message: Logged In: YES user_id=45365 Steven, there's a few problems with your patch that I'd like you to fix before I check it in (or convince me:-): - There's references to dillo that seem unrelated, could you take them out? - I'm not sure your code correctly handles the case of the Internet Config module being available on OSX. Does it? - The trick with running ps to see whether the finder is there is only half a solution (the finder may be running but you may still not have access to the window manager, for instance when you're ssh'd to someone else's machine) and it's expensive and error prone too. How about trying to send a noop appleevent to the finder and seeing whether that works? - You can probably get rid of the KCGErrorFailure messages by adding a 2>/dev/null the the applescript command. ---------------------------------------------------------------------- Comment By: Steven J. Burr (sburrious) Date: 2002-01-13 19:50 Message: Logged In: YES user_id=322368 I have submitted a new patch which adds the following functionality: -Uses default browser selected in System Preferences if no browser specified. -Allows user to choose any of the following installed browsers: OmniWeb, iCab, Netscape, Opera, Internet Explorer, links, lynx, w3m. -Tests for OS X running without window server as well as Darwin without OS X. (Note that even without this test, use of the module without the window server did not crash Python, but instead generated the following error message: "KCGErrorFailure: initCGDisplayState: No display interlock.") -Opens url in new window with open_new function or method, if the browser supports this behavior. -Adds support for the Unix Dillo browser. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=502205&group_id=5470 From noreply@sourceforge.net Tue Feb 5 23:11:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 05 Feb 2002 15:11:05 -0800 Subject: [Patches] [ python-Patches-488452 ] Webbrowser should use IC on Mac OS X Message-ID: Patches item #488452, was opened at 2001-12-03 07:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488452&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Duplicate Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Webbrowser should use IC on Mac OS X Initial Comment: the webbrowser module should use Internet Config as the default way of finding the users' preferred web browser on Mac OS X. In MacPython it does, but the code needs to be added for Unix. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2002-02-05 15:11 Message: Logged In: YES user_id=45365 Item 502205 addresses this same issue, and actually has a patch attached. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=488452&group_id=5470 From noreply@sourceforge.net Wed Feb 6 14:04:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Feb 2002 06:04:02 -0800 Subject: [Patches] [ python-Patches-513752 ] PEP 279 Simulator Message-ID: Patches item #513752, was opened at 2002-02-06 06:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513752&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 279 Simulator Initial Comment: The download attachment contains a module which simulates every feature proposed in PEP 279, Enhanced Generators. It is provided as a proof-of-concept and as a means for experimenting with the proposed features. It includes: 1. New built-ins: xmap, xfilter, xzip, and indexed 2. Generator comprehensions 3. Generator parameter passing 4. Generator exception passing ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513752&group_id=5470 From noreply@sourceforge.net Wed Feb 6 14:12:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 06 Feb 2002 06:12:40 -0800 Subject: [Patches] [ python-Patches-513756 ] PEP 279 Examples and Test Suite Message-ID: Patches item #513756, was opened at 2002-02-06 06:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513756&group_id=5470 Category: Demos and tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 279 Examples and Test Suite Initial Comment: The download attachment is a module which exercises every feature proposed in PEP 279, Enhanced Generators. It also includes working source code for each example mentioned in the PEP. The module uses Source Forge patch #513752 which simulates each proposed in the PEP. Both modules are written completely in Python and require Python 2.2 to run. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513756&group_id=5470 From noreply@sourceforge.net Thu Feb 7 20:10:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Feb 2002 12:10:28 -0800 Subject: [Patches] [ python-Patches-514490 ] Better pager selection for OS/2 Message-ID: Patches item #514490, was opened at 2002-02-07 12:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514490&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Nobody/Anonymous (nobody) Summary: Better pager selection for OS/2 Initial Comment: With the current implementation (rev. 1.56) of pydoc.py the first call of the help command gives (when the pager environmment variable is not set): Python 2.2 (#0, Dec 24 2001, 18:42:48) [EMX GCC 2.8.1] on os2emx Type "help", "copyright", "credits" or "license" for more information. >>> help(help) SYS0003: The system cannot find the path specified. Help on instance of _Helper: Type help() for interactive help, or help(object) for help about object. >>> After the error message one has to press Ctrl-C. Further invocations of help work, though. The attached patch selects 'more <' as the default pager when no PAGER env. variable is set, like on Windows. I use os.platform.startswith to deal with a possible future port with os.platform == 'os2vac'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514490&group_id=5470 From noreply@sourceforge.net Fri Feb 8 02:09:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Feb 2002 18:09:59 -0800 Subject: [Patches] [ python-Patches-514628 ] bug in pydoc on python 2.2 release Message-ID: Patches item #514628, was opened at 2002-02-07 18:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514628&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Raj Kunjithapadam (mmaster25) Assigned to: Nobody/Anonymous (nobody) Summary: bug in pydoc on python 2.2 release Initial Comment: pydoc has a bug when trying to generate html doc more importantly it has bug in the method writedoc() attached is my fix. Here is the diff between my fix and the regular dist 1338c1338 < def writedoc(thing, forceload=0): --- > def writedoc(key, forceload=0): 1340,1346c1340,1343 < object = thing < if type(thing) is type(''): < try: < object = locate(thing, forceload) < except ErrorDuringImport, value: < print value < return --- > try: > object = locate(key, forceload) > except ErrorDuringImport, value: > print value 1351c1348 < file = open(thing.__name__ + '.html', 'w') --- > file = open(key + '.html', 'w') 1354c1351 < print 'wrote', thing.__name__ + '.html' --- > print 'wrote', key + '.html' 1356c1353 < print 'no Python documentation found for %s' % repr(thing) --- > print 'no Python documentation found for %s' % repr(key) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514628&group_id=5470 From noreply@sourceforge.net Fri Feb 8 03:26:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Feb 2002 19:26:56 -0800 Subject: [Patches] [ python-Patches-514641 ] Negative ob_size of LongObjects Message-ID: Patches item #514641, was opened at 2002-02-07 19:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514641&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Naofumi Honda (naofumi-h) Assigned to: Nobody/Anonymous (nobody) Summary: Negative ob_size of LongObjects Initial Comment: I found the following bugs due to the negative ob_size of LongObjects representing the negative values. 1) The access of attribute "__dict__" causes panic. class A(long): pass x = A(-1) x.__dict__ ==> core dump! 2) pickle neglects the sign of LongObjects import pickle class A(long): pass x = A(-1) pickle.dumps(x) ==> a string containing 1L (not -1L) !!! The patch will resolve the above problems. Naofumi Honda ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514641&group_id=5470 From noreply@sourceforge.net Fri Feb 8 04:49:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 07 Feb 2002 20:49:57 -0800 Subject: [Patches] [ python-Patches-514662 ] On the update_slot() behavior Message-ID: Patches item #514662, was opened at 2002-02-07 20:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514662&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Naofumi Honda (naofumi-h) Assigned to: Nobody/Anonymous (nobody) Summary: On the update_slot() behavior Initial Comment: Inherited method __getitem__ of list type in the new subclass is unexpectedly slow. For example, x = list([1,2,3]) r = xrange(1, 1000000) for i in r: x[1] = 2 ==> excution time: real 0m2.390s class nlist(list): pass x = nlist([1,2,3]) r = xrange(1, 1000000) for i in r: x[1] = 2 ==> excution time: real 0m7.040s about 3times slower!!! The reason is: for the __getitem__ attribute, there are two slotdefs in typeobject.c (one for the mapping type, and the other for the sequence type). In the creation of new_type of list type, fixup_slot_dispatchers() and update_slot() functions in typeobject.c allocate the functions to both sq_item and mp_subscript slots (the mp_subscript slot had originally no function, because the list type is a sequence type), and it's an unexpected allocation for the mapping slot since the descriptor type of __getitem__ is now WrapperType for the sequence operations. If you will trace x[1] using gdb, you will find that in PyObject_GetItem() m->mp_subscript = slot_mp_subscript is called instead of a sequece operation because mp_subscript slot was allocated by fixup_slot_dispatchers(). In the slot_mp_subscirpt(), call_method(self, "__getitem__", ...) is invoked, and turn out to call a wrapper descriptors for the sq_item. As a result, the method of list type finally called, but it needs many unexpected function calls. I will fix the behavior of fixup_slot_dispachers() and update_slot() as follows: Only the case where *) two or more slotdefs have the same attribute name where at most one corresponding slot has a non null pointer *) the descriptor type of the attribute is WrapperType, these functions will allocate the only one function to the apropriate slot. The other case, the behavior not changed to keep compatiblity! (in particular, considering the case where user override methods exist!) The following patch also includes speed up routines to find the slotdef duplications, but it's not essential! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514662&group_id=5470 From noreply@sourceforge.net Fri Feb 8 13:21:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 05:21:12 -0800 Subject: [Patches] [ python-Patches-514641 ] Negative ob_size of LongObjects Message-ID: Patches item #514641, was opened at 2002-02-07 19:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514641&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Naofumi Honda (naofumi-h) Assigned to: Nobody/Anonymous (nobody) Summary: Negative ob_size of LongObjects Initial Comment: I found the following bugs due to the negative ob_size of LongObjects representing the negative values. 1) The access of attribute "__dict__" causes panic. class A(long): pass x = A(-1) x.__dict__ ==> core dump! 2) pickle neglects the sign of LongObjects import pickle class A(long): pass x = A(-1) pickle.dumps(x) ==> a string containing 1L (not -1L) !!! The patch will resolve the above problems. Naofumi Honda ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-08 05:21 Message: Logged In: YES user_id=33168 There is a bug report for this item: #506679. https://sourceforge.net/tracker/index.php?func=detail&aid=506679&group_id=5470&atid=105470 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514641&group_id=5470 From noreply@sourceforge.net Fri Feb 8 21:22:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 13:22:59 -0800 Subject: [Patches] [ python-Patches-514997 ] remove extra SET_LINENOs Message-ID: Patches item #514997, was opened at 2002-02-08 13:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514997&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove extra SET_LINENOs Initial Comment: This patch removes consecutive SET_LINENOs. The patch fixes test_hotspot, but does not fix a failure in inspect. I wasn't sure what was the problem was or why SET_LINENO would matter for inspect. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514997&group_id=5470 From noreply@sourceforge.net Fri Feb 8 21:27:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 13:27:21 -0800 Subject: [Patches] [ python-Patches-515000 ] print result of f.tell() in test Message-ID: Patches item #515000, was opened at 2002-02-08 13:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515000&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: print result of f.tell() in test Initial Comment: Print the result of f.tell() in the StringIO test. (shut up pychecker unused variable) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515000&group_id=5470 From noreply@sourceforge.net Fri Feb 8 21:39:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 13:39:18 -0800 Subject: [Patches] [ python-Patches-515003 ] Added HTTP{,S}ProxyConnection Message-ID: Patches item #515003, was opened at 2002-02-08 13:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: Added HTTP{,S}ProxyConnection Initial Comment: This patch adds HTTP*Connection classes for proxy connections. Authenticated proxies are also supported. One can argue urllib2 already implements this. It does not do HTTPS tunneling through proxies, and this is intended to be lower-level than urllib2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515003&group_id=5470 From noreply@sourceforge.net Fri Feb 8 21:46:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 13:46:32 -0800 Subject: [Patches] [ python-Patches-515004 ] cleanup lib/aifc.py Message-ID: Patches item #515004, was opened at 2002-02-08 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515004&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: cleanup lib/aifc.py Initial Comment: remove unused imports, rename dum -> dummy (shut up pychecker) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515004&group_id=5470 From noreply@sourceforge.net Fri Feb 8 21:48:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 13:48:31 -0800 Subject: [Patches] [ python-Patches-515005 ] remove pychecker warnings in bdb Message-ID: Patches item #515005, was opened at 2002-02-08 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515005&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove pychecker warnings in bdb Initial Comment: Change 1 + '' which pychecker complains about to: raise Exception. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515005&group_id=5470 From noreply@sourceforge.net Fri Feb 8 21:50:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 13:50:28 -0800 Subject: [Patches] [ python-Patches-515006 ] remove unused import in lib/cgi.py Message-ID: Patches item #515006, was opened at 2002-02-08 13:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515006&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove unused import in lib/cgi.py Initial Comment: summary says it all, a warning from pychecker ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515006&group_id=5470 From noreply@sourceforge.net Fri Feb 8 21:52:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 13:52:38 -0800 Subject: [Patches] [ python-Patches-515009 ] remove op global from lib/dis.py Message-ID: Patches item #515009, was opened at 2002-02-08 13:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515009&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove op global from lib/dis.py Initial Comment: op is a temporary variable at module scope, but it is not cleaned up. it generates a shadowing warning in pychecker. this patch deletes op ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515009&group_id=5470 From noreply@sourceforge.net Fri Feb 8 21:54:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 13:54:22 -0800 Subject: [Patches] [ python-Patches-515011 ] remove or 0 from lib/httplib.py Message-ID: Patches item #515011, was opened at 2002-02-08 13:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515011&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove or 0 from lib/httplib.py Initial Comment: pychecker warning for constant condition ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515011&group_id=5470 From noreply@sourceforge.net Fri Feb 8 21:56:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 13:56:28 -0800 Subject: [Patches] [ python-Patches-515012 ] remove unused variable in lib/imputil Message-ID: Patches item #515012, was opened at 2002-02-08 13:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515012&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove unused variable in lib/imputil Initial Comment: local var path is set, but not used ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515012&group_id=5470 From noreply@sourceforge.net Fri Feb 8 22:00:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 14:00:57 -0800 Subject: [Patches] [ python-Patches-515015 ] inspect.py sort suffixes correctly Message-ID: Patches item #515015, was opened at 2002-02-08 14:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515015&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.py sort suffixes correctly Initial Comment: there is a comment which says the suffixes should be sorted by length, but there is no comparison function. this patch adds a comparison (lambda). also, there are two functions which are documented to return IOError if there are problems, but if the function reaches the end, there were no raises. This patch adds raise IOErrors. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515015&group_id=5470 From noreply@sourceforge.net Fri Feb 8 22:07:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 14:07:57 -0800 Subject: [Patches] [ python-Patches-515018 ] lib/pickle.py remove global x Message-ID: Patches item #515018, was opened at 2002-02-08 14:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515018&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: lib/pickle.py remove global x Initial Comment: a temporary global variable is left around. this patch deletes the variable (x). this must have been a pychecker warning (probably shadowing a global) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515018&group_id=5470 From noreply@sourceforge.net Fri Feb 8 22:11:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 14:11:45 -0800 Subject: [Patches] [ python-Patches-515020 ] lib/site.py remove temporary globals Message-ID: Patches item #515020, was opened at 2002-02-08 14:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515020&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: lib/site.py remove temporary globals Initial Comment: I'm not sure if all of these are temporary globals, but they seemed to be: prefix, sitedir, dircase ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515020&group_id=5470 From noreply@sourceforge.net Fri Feb 8 22:14:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 14:14:04 -0800 Subject: [Patches] [ python-Patches-515021 ] lib/smtpd.py print refused addresses Message-ID: Patches item #515021, was opened at 2002-02-08 14:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515021&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: lib/smtpd.py print refused addresses Initial Comment: currently, the refused list is unused. there is a comment which asks what to do with them, this patch at least prints the refused list to the DEBUGSTREAM. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515021&group_id=5470 From noreply@sourceforge.net Fri Feb 8 22:15:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 14:15:37 -0800 Subject: [Patches] [ python-Patches-515022 ] lib/sre_parse has unused var Message-ID: Patches item #515022, was opened at 2002-02-08 14:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515022&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: lib/sre_parse has unused var Initial Comment: this patch removes an unused local variable ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515022&group_id=5470 From noreply@sourceforge.net Fri Feb 8 22:19:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 14:19:15 -0800 Subject: [Patches] [ python-Patches-515023 ] thr.join() signatures are different Message-ID: Patches item #515023, was opened at 2002-02-08 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515023&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: thr.join() signatures are different Initial Comment: the _DummyThread.join() signature doesn't match it's base class. this patch adds a timeout parameter with default value to match Thread. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515023&group_id=5470 From noreply@sourceforge.net Fri Feb 8 22:21:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 14:21:01 -0800 Subject: [Patches] [ python-Patches-515024 ] lib/urllib.py remove unused local Message-ID: Patches item #515024, was opened at 2002-02-08 14:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515024&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: lib/urllib.py remove unused local Initial Comment: remove unused local variable ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515024&group_id=5470 From noreply@sourceforge.net Fri Feb 8 22:22:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 14:22:17 -0800 Subject: [Patches] [ python-Patches-515026 ] webbrowser.py remove temporary global Message-ID: Patches item #515026, was opened at 2002-02-08 14:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515026&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.py remove temporary global Initial Comment: delete temporary global variable cmd ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515026&group_id=5470 From noreply@sourceforge.net Fri Feb 8 22:22:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 14:22:18 -0800 Subject: [Patches] [ python-Patches-515027 ] webbrowser.py remove temporary global Message-ID: Patches item #515027, was opened at 2002-02-08 14:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515027&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.py remove temporary global Initial Comment: delete temporary global variable cmd ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515027&group_id=5470 From noreply@sourceforge.net Fri Feb 8 22:24:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 14:24:02 -0800 Subject: [Patches] [ python-Patches-515027 ] webbrowser.py remove temporary global Message-ID: Patches item #515027, was opened at 2002-02-08 14:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515027&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.py remove temporary global Initial Comment: delete temporary global variable cmd ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-08 14:24 Message: Logged In: YES user_id=33168 somehow this got duplicated ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515027&group_id=5470 From noreply@sourceforge.net Fri Feb 8 22:49:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 14:49:04 -0800 Subject: [Patches] [ python-Patches-515041 ] path in site doc refers to 1.5 Message-ID: Patches item #515041, was opened at 2002-02-08 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515041&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: path in site doc refers to 1.5 Initial Comment: doc for the site module refers to 1.5 in paths, this patch updates the paths to include 2.2 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515041&group_id=5470 From noreply@sourceforge.net Fri Feb 8 23:10:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 08 Feb 2002 15:10:45 -0800 Subject: [Patches] [ python-Patches-515015 ] inspect.py sort suffixes correctly Message-ID: Patches item #515015, was opened at 2002-02-08 14:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515015&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.py sort suffixes correctly Initial Comment: there is a comment which says the suffixes should be sorted by length, but there is no comparison function. this patch adds a comparison (lambda). also, there are two functions which are documented to return IOError if there are problems, but if the function reaches the end, there were no raises. This patch adds raise IOErrors. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-02-08 15:10 Message: Logged In: YES user_id=31435 Please remove the lambda trick from the patch. The comment is explaining why the negation of the length is the first element of the tuples being sorted (that's what guarantees the longest suffix is checked first in case of overlap). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515015&group_id=5470 From noreply@sourceforge.net Sat Feb 9 14:16:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 09 Feb 2002 06:16:40 -0800 Subject: [Patches] [ python-Patches-515015 ] inspect.py raise exception if code not found Message-ID: Patches item #515015, was opened at 2002-02-08 14:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515015&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) >Summary: inspect.py raise exception if code not found Initial Comment: there is a comment which says the suffixes should be sorted by length, but there is no comparison function. this patch adds a comparison (lambda). also, there are two functions which are documented to return IOError if there are problems, but if the function reaches the end, there were no raises. This patch adds raise IOErrors. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-09 06:16 Message: Logged In: YES user_id=33168 Sorry, I saw the map/lambda above, but misread the code. Attached is a new file (just contains the 2 raises). I really need to add a test for this as well. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-08 15:10 Message: Logged In: YES user_id=31435 Please remove the lambda trick from the patch. The comment is explaining why the negation of the length is the first element of the tuples being sorted (that's what guarantees the longest suffix is checked first in case of overlap). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515015&group_id=5470 From Jeff Graysmith Sat Feb 9 18:17:08 2002 From: Jeff Graysmith (Jeff Graysmith) Date: 09 Feb 2002 10:17:08 -0800 Subject: [Patches] You know your email is vulnerable to SPAM Robots? Message-ID: ------=_MmBS95Z1_OZ8h3B8s_MA Content-Type: text/plain Content-Transfer-Encoding: 8bit Hello, Please pardon the intrusion, but I saw that the email address patches@python.org is in plain text on your site at http://python.sourceforge.net/sf-faq.html making it vulnerable to be harvested by SPAM robots. Check this out there's a way to hide your email from robots, but still have it visible to human users. http://www.email-cloak.net Sincerely, Jeff Graysmith ------=_MmBS95Z1_OZ8h3B8s_MA Content-Type: text/html Content-Transfer-Encoding: 8bit Hello,

Please pardon the intrusion, but I saw that the email address patches@python.org is in plain text on your site at http://python.sourceforge.net/sf-faq.html making it vulnerable to be harvested by SPAM robots. Check this out there's a way to hide your email from robots, but still have it visible to human users.
http://www.email-cloak.net

Sincerely,
Jeff Graysmith
 ------=_MmBS95Z1_OZ8h3B8s_MA-- From noreply@sourceforge.net Sun Feb 10 16:24:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Feb 2002 08:24:38 -0800 Subject: [Patches] [ python-Patches-514490 ] Better pager selection for OS/2 Message-ID: Patches item #514490, was opened at 2002-02-07 12:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514490&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) >Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Better pager selection for OS/2 Initial Comment: With the current implementation (rev. 1.56) of pydoc.py the first call of the help command gives (when the pager environmment variable is not set): Python 2.2 (#0, Dec 24 2001, 18:42:48) [EMX GCC 2.8.1] on os2emx Type "help", "copyright", "credits" or "license" for more information. >>> help(help) SYS0003: The system cannot find the path specified. Help on instance of _Helper: Type help() for interactive help, or help(object) for help about object. >>> After the error message one has to press Ctrl-C. Further invocations of help work, though. The attached patch selects 'more <' as the default pager when no PAGER env. variable is set, like on Windows. I use os.platform.startswith to deal with a possible future port with os.platform == 'os2vac'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514490&group_id=5470 From noreply@sourceforge.net Sun Feb 10 19:07:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Feb 2002 11:07:26 -0800 Subject: [Patches] [ python-Patches-515593 ] unused parameter removed tkFileDialog.py Message-ID: Patches item #515593, was opened at 2002-02-10 11:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515593&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: unused parameter removed tkFileDialog.py Initial Comment: The parameter 'widget' is not used in tkFileDialog Directory._fixresult. Removed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515593&group_id=5470 From noreply@sourceforge.net Sun Feb 10 19:16:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Feb 2002 11:16:39 -0800 Subject: [Patches] [ python-Patches-515593 ] unused parameter removed tkFileDialog.py Message-ID: Patches item #515593, was opened at 2002-02-10 11:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515593&group_id=5470 Category: Tkinter Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: unused parameter removed tkFileDialog.py Initial Comment: The parameter 'widget' is not used in tkFileDialog Directory._fixresult. Removed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515593&group_id=5470 From noreply@sourceforge.net Sun Feb 10 19:29:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Feb 2002 11:29:06 -0800 Subject: [Patches] [ python-Patches-515597 ] remove unused parameger tkFileDialog Message-ID: Patches item #515597, was opened at 2002-02-10 11:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515597&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: remove unused parameger tkFileDialog Initial Comment: Python 2.2 (#1, Dec 28 2001, 11:17:23) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Removing an unused 'widget' 'parameter from tkFileDialog Dictionary._fixresult and tkCommonDialog. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515597&group_id=5470 From noreply@sourceforge.net Sun Feb 10 19:36:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Feb 2002 11:36:11 -0800 Subject: [Patches] [ python-Patches-515598 ] removed unused import tkCommonDialog Message-ID: Patches item #515598, was opened at 2002-02-10 11:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515598&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: removed unused import tkCommonDialog Initial Comment: Python 2.2 (#1, Dec 28 2001, 11:17:23) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Unused import os removed from tkCommonDialog.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515598&group_id=5470 From noreply@sourceforge.net Sun Feb 10 19:36:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 10 Feb 2002 11:36:32 -0800 Subject: [Patches] [ python-Patches-515597 ] remove unused parameter tkFileDialog Message-ID: Patches item #515597, was opened at 2002-02-10 11:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515597&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) >Summary: remove unused parameter tkFileDialog Initial Comment: Python 2.2 (#1, Dec 28 2001, 11:17:23) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Removing an unused 'widget' 'parameter from tkFileDialog Dictionary._fixresult and tkCommonDialog. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515597&group_id=5470 From noreply@sourceforge.net Mon Feb 11 17:52:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 09:52:34 -0800 Subject: [Patches] [ python-Patches-515000 ] print result of f.tell() in test Message-ID: Patches item #515000, was opened at 2002-02-08 13:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515000&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: print result of f.tell() in test Initial Comment: Print the result of f.tell() in the StringIO test. (shut up pychecker unused variable) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 09:52 Message: Logged In: YES user_id=33168 Checked in as 1.21 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515000&group_id=5470 From noreply@sourceforge.net Mon Feb 11 17:56:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 09:56:33 -0800 Subject: [Patches] [ python-Patches-515004 ] cleanup lib/aifc.py Message-ID: Patches item #515004, was opened at 2002-02-08 13:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515004&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: cleanup lib/aifc.py Initial Comment: remove unused imports, rename dum -> dummy (shut up pychecker) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 09:56 Message: Logged In: YES user_id=33168 Checked in as 1.41 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515004&group_id=5470 From noreply@sourceforge.net Mon Feb 11 17:58:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 09:58:05 -0800 Subject: [Patches] [ python-Patches-515006 ] remove unused import in lib/cgi.py Message-ID: Patches item #515006, was opened at 2002-02-08 13:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515006&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove unused import in lib/cgi.py Initial Comment: summary says it all, a warning from pychecker ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 09:58 Message: Logged In: YES user_id=33168 Checked in as 1.69 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515006&group_id=5470 From noreply@sourceforge.net Mon Feb 11 18:00:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 10:00:00 -0800 Subject: [Patches] [ python-Patches-515011 ] remove or 0 from lib/httplib.py Message-ID: Patches item #515011, was opened at 2002-02-08 13:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515011&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove or 0 from lib/httplib.py Initial Comment: pychecker warning for constant condition ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 10:00 Message: Logged In: YES user_id=33168 Checked in as 1.43. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515011&group_id=5470 From noreply@sourceforge.net Mon Feb 11 18:01:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 10:01:39 -0800 Subject: [Patches] [ python-Patches-515012 ] remove unused variable in lib/imputil Message-ID: Patches item #515012, was opened at 2002-02-08 13:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515012&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove unused variable in lib/imputil Initial Comment: local var path is set, but not used ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 10:01 Message: Logged In: YES user_id=33168 Checked in as 1.23 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515012&group_id=5470 From noreply@sourceforge.net Mon Feb 11 18:05:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 10:05:24 -0800 Subject: [Patches] [ python-Patches-515021 ] lib/smtpd.py print refused addresses Message-ID: Patches item #515021, was opened at 2002-02-08 14:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515021&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: lib/smtpd.py print refused addresses Initial Comment: currently, the refused list is unused. there is a comment which asks what to do with them, this patch at least prints the refused list to the DEBUGSTREAM. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 10:05 Message: Logged In: YES user_id=33168 Checked in as 1.12 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515021&group_id=5470 From noreply@sourceforge.net Mon Feb 11 18:06:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 10:06:32 -0800 Subject: [Patches] [ python-Patches-515024 ] lib/urllib.py remove unused local Message-ID: Patches item #515024, was opened at 2002-02-08 14:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515024&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: lib/urllib.py remove unused local Initial Comment: remove unused local variable ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 10:06 Message: Logged In: YES user_id=33168 Checked in as 1.136 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515024&group_id=5470 From noreply@sourceforge.net Mon Feb 11 18:11:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 10:11:20 -0800 Subject: [Patches] [ python-Patches-515026 ] webbrowser.py remove temporary global Message-ID: Patches item #515026, was opened at 2002-02-08 14:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515026&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.py remove temporary global Initial Comment: delete temporary global variable cmd ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 10:11 Message: Logged In: YES user_id=33168 Checked in as 1.28. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515026&group_id=5470 From noreply@sourceforge.net Mon Feb 11 18:12:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 10:12:26 -0800 Subject: [Patches] [ python-Patches-515018 ] lib/pickle.py remove global x Message-ID: Patches item #515018, was opened at 2002-02-08 14:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515018&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: lib/pickle.py remove global x Initial Comment: a temporary global variable is left around. this patch deletes the variable (x). this must have been a pychecker warning (probably shadowing a global) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 10:12 Message: Logged In: YES user_id=33168 Checked in as 1.57 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515018&group_id=5470 From noreply@sourceforge.net Mon Feb 11 18:14:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 10:14:29 -0800 Subject: [Patches] [ python-Patches-515009 ] remove op global from lib/dis.py Message-ID: Patches item #515009, was opened at 2002-02-08 13:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515009&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove op global from lib/dis.py Initial Comment: op is a temporary variable at module scope, but it is not cleaned up. it generates a shadowing warning in pychecker. this patch deletes op ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 10:14 Message: Logged In: YES user_id=33168 Checked in as 1.38. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515009&group_id=5470 From noreply@sourceforge.net Mon Feb 11 18:18:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 10:18:34 -0800 Subject: [Patches] [ python-Patches-515022 ] lib/sre_parse has unused var Message-ID: Patches item #515022, was opened at 2002-02-08 14:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515022&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: lib/sre_parse has unused var Initial Comment: this patch removes an unused local variable ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 10:18 Message: Logged In: YES user_id=33168 Checked in as 1.52 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515022&group_id=5470 From noreply@sourceforge.net Mon Feb 11 18:26:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 10:26:09 -0800 Subject: [Patches] [ python-Patches-515005 ] remove pychecker warnings in bdb Message-ID: Patches item #515005, was opened at 2002-02-08 13:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515005&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: remove pychecker warnings in bdb Initial Comment: Change 1 + '' which pychecker complains about to: raise Exception. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 10:26 Message: Logged In: YES user_id=33168 Checked in as 1.34 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515005&group_id=5470 From noreply@sourceforge.net Mon Feb 11 18:34:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 10:34:50 -0800 Subject: [Patches] [ python-Patches-515020 ] lib/site.py remove temporary globals Message-ID: Patches item #515020, was opened at 2002-02-08 14:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515020&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: lib/site.py remove temporary globals Initial Comment: I'm not sure if all of these are temporary globals, but they seemed to be: prefix, sitedir, dircase ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-11 10:34 Message: Logged In: YES user_id=33168 Checked in as 1.40 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515020&group_id=5470 From noreply@sourceforge.net Mon Feb 11 23:17:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 15:17:36 -0800 Subject: [Patches] [ python-Patches-505846 ] pyport.h, Wince and errno getter/setter Message-ID: Patches item #505846, was opened at 2002-01-19 12:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brad Clements (bkc) Assigned to: Nobody/Anonymous (nobody) Summary: pyport.h, Wince and errno getter/setter Initial Comment: Most of the remaining Windows CE diffs are due to the lack of errno on Windows CE. There are other OS's that do not have errno (but they have a workalike method). At first I had simply commented out all references in the code to errno, but that quickly became unworkable. Wince and NetWare use a function to set the per- thread "errno" value. Although errno #defines (like ERANGE) are not defined for Wince, they are defined for NetWare. Removing references to errno would artificially hobble the NetWare port. These platforms also use a function to retrieve the current errno value. The attached diff for pyport.h attempts to standardize the access method for errno (or it's work-alike) by providing SetErrno(), ClearErrno() and GetErrno() macros. ClearErrno() is SetErrno(0) I've found and changed all direct references to errno to use these macros. This patch must be submitted before the patches for other modules. -- I see two negatives with this approach: 1. It will be a pain to think GetErrno() instead of "errno" when modifying/writing new code. 2. Extension modules will need access to pyport.h for the target platform. In the worst case, directly referencing errno instead of using the macros will break only those platforms for which the macros do something different. That is, Wince and NetWare. -- An alternative spelling/capitalization of these macros might make them more appealing. Feel free to make a suggestion. -- It's probably incorrect for me to use SetErrno() as a function, such as SetErrno(1); I think the semi-colon is not needed, but wasn't entirely certain. On better advice, I will fix these statements in the remaining source files if this patch is accepted. ---------------------------------------------------------------------- >Comment By: Brad Clements (bkc) Date: 2002-02-11 15:17 Message: Logged In: YES user_id=4631 Hi folks, I need to proceed with the port to NetWare so I have something to demo at Brainshare in March. Unfortunately future patches from me will include both WINCE and NetWare specific patches, though hopefully there won't be much other than config.h and this patch (which is required for NetWare). Is there anything I can do to make this patch more acceptable? Send a bottle of wine, perhaps? ;-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-28 15:39 Message: Logged In: YES user_id=33168 Tim, I can check in or do whatever else needs to be done to check this in and move this forward. How do you want to procede? Brad, I think most people are pretty busy right now. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-28 15:19 Message: Logged In: YES user_id=4631 Hi folks, just wondering if this patch is going to be rejected, or if you're all too busy and I have to be more patient ;-) I have a passle of Python-CE folks waiting on me to finish checking in patches. This is the worst one, I promise! Let me know what you want me to do, when you get a chance. Thanks ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-20 12:17 Message: Logged In: YES user_id=4631 I've eliminated Py_ClearErrno() and updated all the source to use Py_SetErrno(0). Attached is an updated diff for pyport.h ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-20 11:21 Message: Logged In: YES user_id=31435 Brad, errno is required by ANSI C, which also defines the semantics of a 0 value. Setting errno to 0, and taking errno==0 as meaning "no error", are 100% portable across platforms with a standard-conforming C implementation. If this platform doesn't support standard C, I have to question whether the core should even try to cater to it: the changes needed make no sense to C programmers, so may become a maintenance nightmare. I don't think putting a layer around errno is going to be hard to live with, provided that it merely tries to emulate standard behavior. For that reason, setting errno to 0 is correct, but inventing a new ClearErrno concept is wrong (the latter makes no sense to anyone except its inventor ). ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-20 07:54 Message: Logged In: YES user_id=4631 I can post a new diff for the // or would you be willing to just change the patch you have? I cannot use the same macros for Py_SET_ERANGE_IF_OVERFLOW (X) because Wince doesn't have ERANGE. You'll note the use of Py_SetErrno(1) which is frankly bogus. This is related to your comment on Py_ClearErrno() Using (errno == 0) as meaning "no error" seems to me to be a python source "convention" forced on it by (mostly) floating point side effects. Because the math routines are indicating overflow errors through the side effect of setting errno (rather than returning an explicit NaN that works on all platforms), we must set errno = 0 before calling these math functions. I suppose it's possible that on some platform "clearing the last error value" wouldn't be done this way, but rather might be an explicit function call. Since I was going through the source looking for all errno's, I felt it was clearer to say Py_ClearErrno() rather than Py_SetErrno(0), even though in the end they do the same thing on currently supported platforms. I'm easy, if you want to replace Py_ClearErrno() with Py_SetErrno(0) I can do that too. -- Regarding goto targets.. is it likely that "cleanup" might also collide with local variables? would _cleanup or __cleanup work for you? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-19 14:57 Message: Logged In: YES user_id=33168 Need to change the // comment to /* */. gcc accepts this for C, but it's non-standard (at least it was, it may have changed in C99). You can have 1 Py_SET_ERANGE_IF_OVERFLOW for both platforms if you do this: #ifndef ERANGE #define ERANGE 1 #endif #define Py_SET_ERANGE_IF_OVERFLOW(X) \ do { \ if (Py_GetErrno() == 0 && ((X) == Py_HUGE_VAL || \ (X) == -Py_HUGE_VAL)) \ Py_SetErrno(ERANGE); \ } while(0) I'm not sure of the usefulness of Py_ClearErrno(), since it's the same on all platforms. If errno might be set to something other than 0 in the future, it would be good to make the change now. I would suggest changing finally to cleanup. ---------------------------------------------------------------------- Comment By: Brad Clements (bkc) Date: 2002-01-19 13:47 Message: Logged In: YES user_id=4631 Here is an amended diff with the suggested changes. I've tested the semi-colon handling on EVT, it works as suggested. -- Question: What is the prefered style, #ifdef xyz or #if defined(xyz) ? I try to use #ifdef xyz, but sometimes there's multiple possibilities and #if defined(x) || defined(y) is needed. Is that okay? -- Upcoming issue (hoping you address in your reply). There are many "goto finally" statements in various modules. Unfortunately EVT treats "finally" as a reserved word, even when compiling in non C++ mode. Also, Metrowerks does the same. I've changed all of these to "goto my_finally" as a quick work-around. I know "my_finally" sounds yucky, what's your recommendation for this? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-19 12:52 Message: Logged In: YES user_id=31435 All identifiers defined in pyport.h must begin with "Py_". pyport.h is (and must be) #include'd by extension modules, and we need the prefix to avoid stomping on their namespace, and to make clear (to them and to us) that the gimmicks are part of Python's portability layer. A name like "SetErrno" is certain to conflict with some other package's attempt to worm around errno problems; Py_SetErrno () is not. Agree with Neal's final suggestion about dealing with semicolons. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-01-19 12:28 Message: Logged In: YES user_id=33168 Typically, the semi-colon problem is dealt with as in Py_SET_ERANGE_IF_OVERFLOW. So, #define SetErrno(X) do { SetLastError(X); } while (0) I don't think (but can't remember if) there is any problem for single statements like you have. You could probably do: #ifndef MS_WINCE #define SetErrno(X) errno = (X) /* note no ; */ #else #define SetErrno(X) SetLastError(X) /* note no ; */ #endif ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=505846&group_id=5470 From noreply@sourceforge.net Tue Feb 12 03:56:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 11 Feb 2002 19:56:40 -0800 Subject: [Patches] [ python-Patches-516297 ] iterator for lineinput Message-ID: Patches item #516297, was opened at 2002-02-11 19:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516297&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: iterator for lineinput Initial Comment: Taking the route of least evasiveness, I have come up with a VERY simple iterator interface for fileinput. Basically, __iter__() returns self and next() calls __getitem__() with the proper number. This was done to have the patch only add methods and not change any existing ones, thus minimizing any chance of breaking existing code. Now the module on the whole, however, could possibly stand an update now that generators are coming. I have a recipe up at the Cookbook that uses generators to implement fileinput w/o in-place editing (http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/112506). If there is enough interest, I would be quite willing to rewrite fileinput using generators. And if some of the unneeded methods could be deprecated (__getitem__, readline), then the whole module could probably be cleaned up a decent amount and have a possible speed improvement. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516297&group_id=5470 From biz@6x6.net Sun Feb 10 01:03:28 2002 From: biz@6x6.net (biz@6x6.net) Date: 10 Feb 2002 03:03:28 +0200 Subject: [Patches] ATTENTION! Well-Paid Job in theInternet! Message-ID: ATTENTION! The Well-Paid Job in the Internet!
We wish You a pleasant and successful day!
 
Make money without leaving Your computer!


If You show some interest and patience and understand as IT works, You can earn up to $100,000 and more!!! During the following 120 days - it depends only on You. DOES IT SEEMS TO BE IMPOSSIBLE?? Read this document to be sure there is no catch or deceit. If You are completely lazy - we beg Your pardon for the assumption!!!, then this is not for You!!! You'd better do something like surfing either clicking on banners or not doing anything at all.

!!! If the offer hasn't interested You, we bring our apologies and it is not necessary to get angry - "Spam" has its expenses, just as radio and TV, but do not forget, that the first billionaire of the USA, Dale Carnegie said:

"I'll better earn 1% as a result of the efforts of 100 men, than 100% as a result of my own efforts."


RISE ON THE WAY TO THE FINANCIAL INDEPENDENCE AND FREEDOM!!!
Welcome to the 6X6!
 
It is difficult to believe but nevertheless it is like that! People get richer and richer! Some of them can't recover from the shock which had come together with a heap of crust banknotes even some months later. While the others deliberate and doubt, people that believed in Business System 6X6 bathe now in money!...
 
In view of prompt rates of development of the Internet and electronic commerce the number of users of the "World Wide Web" grows with the great speed. There are more than 15,000 new people who join the Internet daily...
 

Copyright � 2001 6x6 MLM Corporation. All rights reserved.
Ladies and Gentlemen!
 
 


PLEASE READ THOUGHTFULLY AND ATTENTIVELY, TRYING NOT TO DISTRACT YOUR ATTENTION WITH EXTERNAL NOISES AND IRRITANTS, AND YOU'LL UNDERSTAND WHAT WILL MAKE YOU RATHER RICH AND FREE PEOPLE!!!
 

 


It is difficult to believe but nevertheless it is like that! People get richer and richer! Some of them can't recover from the shock which had come together with a heap of crust banknotes even some months later. While the others deliberate and doubt, people that believed in Business System 6X6 bathe now in money! In a literal sense! Have You ever seen how the heap of the $5 bills under which the adult person entirelly finds room looks like?! It is 100 thousand dollars!!! Can You imagine how the heap of $1,000,000 which is earned by each third participant of the superprogram 6X6 looks like?! And what is the feeling when You, not getting troubled with work, start to receive envelopes with six dollars already on the second week and further the profit is much more! And eventually some months later You don't know how to get rid of the money! You even get a bit scary of this avalanches of the money!!!
 

ALL THAT IT WILL NECESSARY TO DO - TO SEND THE ADVERTISING LETTERS VIA E-MAIL AND FROM TIME TO TIME TO CHECK YOUR MAILBOX OR TO GO TO THE BANK! YOU SHOULDN'T EVEN STRAIN THE BRAIN - THE SUPER COMPUTER BUSINESS SYSTEM 6X6 WILL MAKE EVERYTHING ITSELF!!!

SINCE THE MOMENT YOU ENTER THIS BUSINESS YOUR PROFIT SNOWBALLS AND BY THE END OF 4TH MONTH YOU'LL GET AS MINIMUM $100,000. BUT IF YOU DON'T STOP THE RESULTS WILL BE ASTRONOMICAL - $1,000,000 FOR 1 YEAR!!!!


"What is the secret of such dizzy success?" - You ask. This is because there is a new formula in the business system which provides all participants with 100%-s' success due to the account of such special factors which the human brain is simply not capable of grasping. Therefore this excellent program works! And it works brilliantly! This is a prodigy-system in which success is madly infectious! Hurry up to achieve the success too!!!
 

TRY YOURSELF!!!
 
&nbps;


Have You ever wondered why the majority of people achieve nothing in life but only complain? This is because they are ready on a little in their life. They have a ready definitions on everything, but these definitions are formulated not by them and taken from the others. To have Your own opinion is a luxury and rarity. Those who are not afraid to try and work more than doubts very quickly appears at the top of the World! Yes, it is difficult to believe that it is possible to get rich so quickly, difficult to overcome the doubts and find Yourself suddenly fantastically rich. But believe if You will do it, it becomes Your blessing and Your dizzy success! You will not argue that You are worthy of big success and big richness, will You? And so it is vitally necessary for You to do this step to find the financial independence which will bring You co-operation with superprogram 6X6! Your time has come!
 

"Pair words about the system..." - an interview with Igor Tichtchenkov, the founder of the business system
 
 


- In view of prompt rates of development of the Internet and electronic commerce the number of users of the "World Wide Web" grows with the great speed. There are more than 15,000 new people who join the Internet daily. With the growth of number of the Internet's users the number of different types of business programs also grows. Every day their popularity increases too and it is natural because the electronic commerce is the business of the 21st century. But business system 6X6 surpasses all others on some orders - it is possible to judge it by looking at the success it brings to all its participants. What is its advantage above the other business programs of similar type? Why does 6X6 bring success to all its participants - not only for its founder and the people who stand near him?

- Yes, You are absolutely right about the prompt development of electronic commerce and the occurrence of many business systems similar to 6X6.

Before the development of the program 6X6 I had closely studied all systems existing at concurrently and understood the way they had appeared. Probably everyone remembers those bonds which were so popular in 90-s. And so with the development of the Internet someone who knows nothing about computer technologies and of the principles of the "World Wide Web" simply transferred this program with bonds to the network. Yes, the idea is ingenious especially for those times - without the Internet You will hardly find 5 clients, in the network there are millions of users and it is possible to send thousands of advertising letters and find a lot of clients. But this system had setbacks: absence of the description of how to send a bulk mailing of advertising letters, where to take thousands of e-mail addresses etc. The most important deficiency was that this system was designed for extremely honest people. In the advertising letter there was a form similar to our business-table according to which the person who entered that business system had to buy its commodity units (each at the different participant). When he bought them he had to put his postal address for payment opposite to the first commodity unit and shift all other addresses one level below. If nobody supervised him he could change the table somehow. For example if he opened some P.O. boxes with various names at different post offices of the city and put the requisitions of these so-called "dead souls" to the table instead of the previous participants and the process stopped that way. Thus the system worked only at 100% at the first level, 1% -at the second, 0,1% - at the third and 0% at the fourth. Actually the profit came only from the first level, i.e. from direct sales. If You sent about 3,000 advertising letters per day You earned about $300 - $400 per month. But the idea of such kind of business systems - was to bring a maximum of the profit due to the last two levels, i.e. You send a party of letters, for example 10,000, receive 30 orders for the first level commodity unit and further the system works for You for several years. But many people earn these $300 - $400 per month sending 3,000 letters per day, having opened some P.O. boxes and put their requisitions everywhere where only it was possible. The commodity units also didn't contain useful information, excepting the names in the advertising letter. Therefore when You worked with such system You deceived the clients.

Probably, there is no sense to describe all other similar kinds of business systems because they are the copies of previous in literal sense. All they appeared that way - the essence was copied and secondary factors such as the names of commodity units, ways of payment, the contents of the advertising letter etc. were changed. It is possible to tell one about all of them: they are "created" (if it is possible to apply this word to pure plagiarism) by amateurs, that are distant from business in general (what is electronic commerce - they simply don't know!) as well as from computer technologies. But the idea to create such business systems is genious. Especially at our time � a time of the cutting edge Internet development and electronic commerce. Excluding the deficiencies of this system it is invaluable! Can You imagine what will the Internet look like in five years!

Even though the task was very difficult I developed such a business system.

The absence of the description of how to send a bulk mailing of advertising letters, where to take thousands of e-mail addresses and other technical details, I compensated with a specially developed software for automation of this process, that allowed one to send 5,000 to 20,000 advertising letters per day having spent only 30-40 minutes of the time, and with the very detailed description of work with this software, written in language which is comprehensible for users of any level and a plenty of advices and recommendations. I managed to do two things at once: to considerably increase productivity of the business system and to make the commondity units not only useful - required for the every participant of the business system, because they contain this special software and the description of work with it.

I stopped the dishonesty of participants by an obligatory registration at the main office of 6X6 MLM Corporation.

Because the system does not break I have added 2 additional levels and now the system has 6 levels (and the commodity unit of every level costs $6 - therefore and the name "6X6").

I made a more flexible system of the payment for the orders. Now the commodity units can be paid both by the "traditional" first class mail and can be transferred on the bank account. But I forbade to specify P.O. boxes as the address for payment for avoidance of a deceit and that the business system don't lose its attractiveness. Proceeding from the same reasons I forbade WebMoney.

I concluded the contract with iWin Loto Ltd. So with registration in our main office You are automatically included in a lottery and Your chances to win are directly proportional to the amount of sold Chapter#1.
 

The responses of our partners
 
 


My name is Jerry Proctor. Two years ago, the corporation I worked at for the past fifteen years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change Your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year ...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of You I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 30,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I am telling You like it is, I hope it doesn't turn You off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than two weeks, I was starting to receive orders for CHAPTER#1. By January 13, I had received 36 orders for CHAPTER#1. Your goal is to "RECEIVE at least 30 ORDERS FOR CHAPTER#1" My first step in making $100,000 in 120 days was done. By January 30, I had received 246 orders for CHAPTER#2. Your goal is to "RECEIVE AT LEAST 150 ORDERS FOR CHAPTER#2. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 150 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $100,000 GOAL." Well, I had 246 orders for CHAPTER#2, 96 more than I needed. So I sat back and relaxed. By March 30, of my e-mailing of 30,000, I received $118,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read this program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won't work if You don't try it. This program does work, but You must follow it EXACTLY! In order for this program to work, You must meet Your goal of 30+ orders for CHAPTER#1, and 150+ orders for CHAPTER#2 and You will make $100,000 or more in 120 days. I AM LIVING PROOF THAT IT WORKS!!! If You choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to You. If You choose to participate, follow the program and You will be on Your way to financial security. If You are a fellow business owner and are if financial trouble like I was, or You want to start Your own business, consider this a sign. I DID!

Sincerely, Jerry Proctor.

 


This program really works. I live outside the US, in Europe and at first I had doubts, I wasn't sure if it would work and so I didn't take it very seriously. But after a while I figured "Why not?". After all, I can't loose much. I sended the requests for the Chapters (I did everything just like I had to because I wanted to do everything right, so if it wouldn't work it wouldn't be my fault, but the program's) and waited. After a while the Chapters arrived by e-mail and I read them several times, they gave me precise information on how to let the program work and after I knew it all, I started my work. I started searching e-mail addresses everywhere (sites, magazines,...) and made long lists (I really enjoyed this because it was like a new hobby and I had nothing to loose). like crazy I started sending e-mail to people all over the world. I kept doing this and checked the mail every day. After two weeks orders started to arrive. I remember the moment when I went to the mailbox and I found the first order for Chapter#1. I just stood there for a moment and I said to myself: "this works, this thing f..... works!!!" I was so happy that I started sending even more e-mails. The next day, nothing in the mail, I thought "maybe this is it" and I was a bit dissapointed but the next day I received 3 orders for Chapter#1. I sended the Chapters to those people so they could start making money too (for them and for me). Two weeks later I was sitting almost 30 minutes a day before my computer sending Chapters to people that had ordered them. In these two weeks I received 39 orders for Chapter#1. Profit so far: about 240 dollars. After that orders came faster and faster, every week I got hundreds of orders and the dollars kept coming. In total I received 124'000 dollars. can You believe this??? Last week I bought a new motorcycle and I owe it all to this program. if You're reading this letter right now and You're not sure whether to participate or not I can only say one thing: TRY IT, You won't regret. This is Your chance, take it now or You will be sorry for the rest of Your live.

H.J. Moines, France.

 


The main reason for this letter is to convince You that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $136,470 in the first 14 weeks, with money still coming in.

Charles Morris, Esq.

 


Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size mailbox crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where people live. There simply isn't a better investment with a faster return.

Paige Willis, Des Moines, IA.

 


I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program, ...11 months passed then it came... I didn't delete this one! I made more than $141,000 on the first try!!

Violet Wilson, Johnstown, PA.

 


This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for You is if You do it. For Your sake, and for Your family's sake don't pass up this golden opportunity. Good luck and happy spending!

Kerry Ford, Centerport, NY.

We wait for Your responses. Send them to the main office.
What is the 6X6?
 
 


So, let뭩 start earning heaps of money without leaving the house! "This is my chance!", - You exclaim having realized that is not necessary to go anywhere and to persuade somebody - only send advertising letters and receive profits! "And what is necessary to do for this purpose?" - the question is inevitable. Earning a heap of money - from $100,000 up to $1,000,000 - for the beginning You must be registered at the main office of the 6X6 MLM Corporation and receive a personal registration number. Having entered in 6X6, You become the distributor of the Chapters - detailed descriptions of work with business system 6X6 and optimization the computer. Clients of Your business become the people that will be interested in these Chapters. And the Chapters should interest them! People will be interested in business itself and all this is a guaranty that people certainly shall respond to Your letter. What is this letter? This is the advertising letter which You'll receive from the main office of the 6X6 MLM Corporation after the registration (it differs from the letter which You are reading now by the presence of Your registration number in the business table). You simply send it to a lot of people. How to find the endless amount of e-mails, how automatically send the advertising letter to them and many other things You will find out in the Chapters. If You are worried where to find so many e-mail addresses don뭪 bother. There are more than 15,000 new people connecting to the Internet daily!!! It'll be enough for everybody!!! After You send the application for registration, a letter will be sent to You, containing:

1) Your registration number,

2) The advertising letter with Your registration number in the business table. In the future You'll send this letter to thousands of recipients,

3) Postal addresses or bank accounts of other participants of the business system. It is necessary for You to order the Chapters from them, each Chapter from different participant (excepting the Master) according to the deciphered business table, that You had an opportunity to sell them to the customers.

Together with it You will also receive other instructions. Well the thing You'll have to do now is to catch the essence of the algorithm below. So, You have all Chapters and You have to send the letter which contains the foreword to these surprising Chapters as the advertisement. Having read it, the person who has received the letter from You will certainly want to enter to the business system 6X6 and read all Chapters. But even if suddenly he will not want to read the Chapters he'll certainly become interested in a unique opportunity to earn millions practically without any expenses, both on money and on time! I agree, it is just impossible to refuse it! Approximately in 2 weeks from the date of Your first mailing You will receive orders for the first Chapter and a payment for it ($6 for each Chapter) from 30 persons or even more. Thus, Your first income will be $180 or more. This is only the beginning! At registration You will be automatically included in a lottery from iWin Lotto - one of the most popular companies engaged in lotto-business in the World, the main prize is $5,000,000 (it is also played 5 prizes on $1,000,000, 100 prizes on $100,000 and more than 5,000 branded T-shirts from 6X6 MLM Corp., draws are carried out every month) � as much orders You get on Chapter#1, as much chances to win the main prize. Do You see?!!! All that is required of You is to send more advertising letters. All Your work will be to go to the bank from time to time or check Your mailbox for cash, and at home, in silence to count up everytime increasing profit! The guarantor of Your dizzy success and reliable ally becomes the most grandiose in the world computer superprogram 6X6!!!
 

THE CHAPTERS
 
 


The Chapters are the most detailed description of the business system 6X6, they are advices about the way to optimize the work with the system and adjust the computer for it. Having read them You will understand how to improve a connection with the Internet, how to find 5,000 to 20,000 e-mail addresses per day, to sort them, to send 5,000 to 20,000 advertising letters per day, how to increase productivity of the computer on 50% and many others interesting things, not applying special efforts.

The Chapters are written in language that is clear for the users of any levels, therefore for working with the business system 6X6 You don't need to be a programmer or even have computer experience. Moreover, if You have begun to work with the computer just yesterday and don't know anything about it, You should read attentively the Chapters and work some time with the business system 6X6. Thus You will soon become an advanced user who knows everything about Windows and the Internet. In addition You also get the special software with each Chapter that is necessary for work and certain amount of e-mail addresses.

The list of the Chapters:

Chapter#1 밒ntroduction to business system 6�6. Optimization of the Internet connection. How to use the Internet much more effectively.�

+20,000 e-mails
+software for automatic reconnecting to the Internet and its complete description.

Chapter#2 밐ow to find 5,000 to 20,000 e-mails per day, working about 30-40 minutes.�

+10,000 e-mails
+software for automatic inclusion/deenergizing of the program for e-mails searching at connection/break of connection with the Internet described in the previous Chapter.

Chapter#3 밐ow to sort e-mails.�

+10,000 e-mails
+software for automatic e-mails searching described in the previous Chapter.

Chapter#4 밐ow to send 5,000 to 20,000 thousand advertising letters per day, working the same 30-40 minutes.�

+10,000 e-mails
+software for fast e-mails sorting described in the previous Chapter.

Chapter#5 밫he most effective algorithm of the work with the business system 6X6.�

+80,000 e-mails (!)
+software for automatic sending a huge amount of the advertising letters with attachments described in the previous Chapter.

Chapter#6 밢ptimize Your computer, raise its productivity on 50%.�

+100,000 e-mails (!)
+the server part of the software for automatic sending a huge amount of the advertising letters with attachments.

THE RULES OF THE PARTICIPATION IN THE BUSINESS SYSTEM 6X6
 
 


The terms:

The master � Igor Tichtchenkov, the founder of the business system;

referrer � the participant of 6X6 from that You have received this advertising letter and should order the Chapter;

client � the owner of e-mail address where You send the advertising letter;

referral � the participant of 6X6 who has ordered from You the Chapter.

How does the business system 6X6 work
 
 


The following system was developed to earn not only from the direct sales (i.e. when You sell the Chapter#1 to Your referrals) but also from the sales of the referrals (i.e. when Your referrals bring to You buyers on Chapter#2 - Chapter#6). There is a following table (so-called the business table) in the advertising letter:

Chapter#1...............referrer nr.1
Chapter#2...............referrer nr.2
Chapter#3...............referrer nr.3
Chapter#4...............referrer nr.4
Chapter#5...............referrer nr.5
Chapter#6...............referrer nr.6

Opposite to each Chapter there is the essential elements of different participants, i.e. You will buy the Chapter#1 from referrer nr.1, Chapter#2 from referrer nr.2, Chapter#3 from referrer nr.3, Chapter#4 from referrer nr.4, Chapter#5 from referrer nr.5, Chapter#6 from referrer nr.6. When You will be registered You'll receive the advertising letter with the business table changed as follows:

Chapter#1...............You
Chapter#2...............referrer nr.1
Chapter#3...............referrer nr.2
Chapter#4...............referrer nr.3
Chapter#5...............referrer nr.4
Chapter#6...............referrer nr.5

Then You begin to send the advertising letter with such business table. I.e. Your referrals will buy the Chapter#1 from You, Chapter#2 from referrer nr.1, Chapter#3 from referrer nr.2, Chapter#4 from referrer nr.3, Chapter#5 from referrer nr.4, Chapter#6 from referrer nr.5. Your referrals nr.1 (they who will buy Chapter#1 from You) will get similarly transformed business table:

Chapter#1...............referral nr.1
Chapter#2...............You
Chapter#3...............referrer nr.1
Chapter#4...............referrer nr.2
Chapter#5...............referrer nr.3
Chapter#6...............referrer nr.4

Then they begin to send the advertising letter with such business table. I.e. their referrals nr.1 (Your referrals nr.2) will buy the Chapter#1 from them (from Your referrals nr.1), Chapter#2 from You, Chapter#3 from referrer nr.1, Chapter#4 from referrer nr.2, Chapter#5 from referrer nr.3, Chapter#6 from referrer nr.4. And etc...

Thus Your referrals involve the clients to the Chapter#1 for themselves and also involve the clients to the other Chapters for You. That means that a direct task of each participant of business system 6X6 - to get as more as possible orders for Chapter#1.

Let's just count up how much money You will earn if each participant involves 10 referrals nr.1:

You......................10 X $6 = $60
Your referrals nr.1...10 X 10 X $6 = $600
Your referrals nr.2...10 X 10 X 10 X $6 = $6,000
Your referrals nr.3...10 X 10 X 10 X 10 X $6 = $60,000
Your referrals nr.4...10 X 10 X 10 X 10 X 10 X $6 = $600,000
Your referrals nr.5...10 X 10 X 10 X 10 X 10 X 10 X $6 = $6,000,0000

Total You will earn $6,666,660!

The figure is not small and therefore You may have doubts. - Try to figure Yourself and You'll get the same result!

Protection against the fraud
 
 


The following protection was developed to exclude breaking of the system.

In the advertising letter there is such business table:

Chapter#1...............reg. nr. of the 1st referrer
Chapter#2...............reg. nr. of the 2nd referrer
Chapter#3...............reg. nr. of the 3rd referrer
Chapter#4...............reg. nr. of the 4th referrer
Chapter#5...............reg. nr. of the 5th referrer
Chapter#6...............reg. nr. of the 6th referrer

The client who has received this advertising letter knows only registration numbers of the referrers from that he must buy the Chapters. He can't buy all their Chapters directly because he doesn't know their requisitions.

Further he registers at the main office of 6X6 MLM Corporation and gets:

1) His registration number;

2) Addresses and bank accounts of all referrers at that he must buy the Chapters;

3) The advertising letter with the changed business table likes that:

Chapter#1...............His reg. nr.
Chapter#2...............reg. nr. of the 1st referrer
Chapter#3...............reg. nr. of the 2nd referrer
Chapter#4...............reg. nr. of the 3rd referrer
Chapter#5...............reg. nr. of the 4th referrer
Chapter#6...............reg. nr. of the 5th referrer

buys all of the Chapters and begins to send this letter.

Due to this protection he can't stop the process and leave their own referrers without their profit. The process can be stopped only if their requisitions will not be in the business table. It is possible only if he will replace requisitions of all five referrers with his requisitios. But he can't do that because for this purpose it will come to register 6 times, whereas it is possible to register only once.
 

ARE YOU READY TO START WITH THE BUSINESS SYSTEM 6X6! LET'S START!
 
 


Attention! There is an enormous amount of referrals who enter the business system 6X6 and that's why from the 1st of September 2000 the registration costs $5.

WHAT YOU NEED TO DO:

a) Register at the main office of 6X6 MLM Corporation:

1) Write on a sheet of paper:

1) Your name;
2) Your postal address for payment;
3) Your bank account for payment (optional);
4) Your e-mail - write legibly and use it only for communication with the main office;
5) The business table which is below;
6) The date.

2) Put $5 in this sheet of paper and send by the first class mail to the 6x6 MLM Corporation's main office:

Igor Tichtchenkov, Laanemere 20-96, 13913 Tallinn, Estonia.

3) Within one week You'll receive (via e-mail You have written in the registration form) the letter containing:

1) Your registration number;
2) Addresses of the referrers from that You should buy the Chapters;
3) The advertising letter with Your registration number for mailing;
4) The instructions that is necessary for beginning.

b) Buy all of the Chapters according to the business table:

Chapter Nr.
Referrer's reg. nr.
Chapter#1
6x6-000009-z-011
Chapter#2
6x6-000002-z-679
Chapter#3
6x6-000000-z-001
Chapter#4
Master 6x6
Chapter#5
Master 6x6
Chapter#6
Master 6x6

THE NOTE! If several or even all registration numbers are "Master 6X6" - there isn't any mistake. When You join You'll be at the begining of the system and undoubtedly earn the enormous amount of money! Your chances to the success are maximal!

As soon as You do this, start sending the advertising letters (more detailed information about the way to do it You will find at the Chapters). In general You should involve about 30 referrals - i.e. to sell 30 Chapters #1. But the more referrals You involve the more Your profit will be!

Try to send 3,000 or more advertising letters per day - it is very easy to do with the special software which You'll get together with the Chapters. If You can send more - do it! Remember as many advertising letters You send the more orders You will get!

The entire process lasts approximately for 4 months. If You precisely follow all the rules, You undoubtedly will be the owner of several hundreds thousand dollars! We know that it will be like that and we congratulate You!!!

And now let's start!

We wish You Great Success!!!

 
 

Copyright � 2001 6x6 MLM Corporation. All rights reserved.
펙乙諺 쭌� 穽��帙謫� � 埰渟曝謫� 厓�!
 
毘� 裔調灑桎� 悚� 剪終循 剪 溢杖桎調!


퇸泣 찰 穽��淳鎭 張惟桎終� 妖鎭釣� � 鎭卒孼猥, � 紳設狀�, 調詣儼奄嚴�, 魏� 芬� 調灑診奄, 찰 溢蓮鎭 軸尊瀑 裔調灑診潗 � 鎭特杖� 衆抑策陷� 120 厓彦 - 哀 $100.000 � 灑音�!!!, 憙� 裔淳茁� 桎蟻惟 剪 쭌�. 各팍綠� 考쫍핍廣谷�?? 厥展嶢纖鎭 菴牆渾 哀有靭粧 � 찰 愴抑嶢嚴�, 破� � 憙佃 張� 杖魏惟� 魏橓雕� 堯� 翟茵壯. 퇸泣 찰 禎鷹渾 音粧�� - 穽前夭 穽悛孼猥 裔 穽抑依蓮杖�!!!,- 桎 憙� 張 秧� 쭌�!!! 虔坂� 裔杖茵煜嚴� 遵從妖莘� 堯� 幽凹纖鎭 禎 蓀牆儼閃 堯� 蓮 張 裔杖茵煜嚴� 杖特�.

!!!퇸泣 穽抑依蓮杖� 쭌� 杖特� 張 裔妖鎭釣櫛循依, 穽妖前夭 竣迪 了淳張杖� � 張 壯哀 遵遭嶢劃�. "爛閃" 夭檍� 竣迪 了鴨阻孺, 診� 蓮 魏� 調怏� � TV, 狀 張 裔岫循煜�, 破� 仲暹贍 渟躁渾 麟應歪遭儼 懶� 콸雨 間存憶�:

"� 懿坂� 修涯 裔調蓀執循潗 1% � 釣奧蟻診鎭 埰堯僥 100 特依橓�, 特� 100% � 釣奧蟻診鎭 竣迪� 櫛衰軫孼裝� 埰堯僥."


쫓弩鵠瑙 痼 鞠農 � 焞痼錮侊炚 考퓽쪘騎勍喫� � 豈适匡�!!!
쿡鎖� 禎縯依循潗 � 6X6!
 
� 憙� 疾昶狀 禎橓鳥潗, 狀, 鎭� 張 靭張�, 憙� 竣儼鋪馴僥�� 牒攸! 檢怏 灑侁鎭�� 壯 紳暹性! 袞惟桎終� 菴蓮 靭��濯 楫埰�� 張 溢身� 全調淳潗�� 剪 瀑魏, 穽曜抑袍莘 筍嚴鎭 � 有特� 春埰��陷� 蓀檣狀�! 淃魏 前診蟻裝� 調醴脹顥筬� � 櫛日億筬秩�, 禎橓鳥馴猥 � 罷哀 쥡午嚴 酪增諺� 6�6 有檉�秩� � 鴨贓侁�!...
 
羸衆� 禎蟻吾循鎭音� "蓴諺寮狀� 檉寀妖�" 調增奄 � 溢鷹猥狀卽迹 岫增尊桎�. 臺� 遵暈葉 桎蟻惟 � 嗜葺僚 � 遵震 흡鎭存奄 臆抑張純� 禎殃誼妬�秩� 灑音� 2000 特依橓�, 壯 행檉鴨 � � 懶� 憙� 打替� � 張仲鏑獪� 調� 灑蟻袍...
 

Copyright � 2001 6x6 MLM Corporation. All rights reserved.
컥梗 � 촘拮匡�!
 
 


國愧蘆瑙 芬� 쩡畓律쫍, 쫌훠잃탸補�, 考 乖쫀탱잘羅 痼 쫌텍苦� 芒梗 � 隙픔隙팔瑙槪, � 쬠 鷗�謙瑙, 稜� 錡탸읖� 쩜� 鷗-痼喫交芼徑 죔쳄膿京 � 豈适匡谷京 拒콘京!!!
 

 


� 憙� 疾昶狀 禎橓鳥潗, 狀, 鎭� 張 靭張�, 憙� 竣儼鋪馴僥�� 牒攸! 檢怏 灑侁鎭�� 壯 紳暹性! 袞惟桎終� 菴蓮 靭��濯 楫埰�� 張 溢身� 全調淳潗�� 剪 瀑魏, 穽曜抑袍莘 筍嚴鎭 � 有特� 春埰��陷� 蓀檣狀�! 淃魏 前診蟻裝� 調醴脹顥筬� � 櫛日億筬秩�, 禎橓鳥馴猥 � 罷哀 쥡午嚴 酪增諺� 6�6 有檉�秩� � 鴨贓侁�! � 修侑贍茴佃 重汞音 衆荻�! 찰 惟宸�-杖修縊 淳鴨泣, 魏� 述紳�怏� 脣尊� 櫛鎭牆紅 有靖�, 禎� 惟桎終� 墮泣惟� 脹余齧秩� 洵尊衆渾 特依橓�?! 毘� 100 執��� 哀應燮荻! 輕蓮鎭 遵悚 穽抑增設嶢�, 魏� 岫 述紳�鴨乙 有妬 了 麟應姚壯 哀應燮荻, 惟桎終� 裔調蓀執循奄 魏輦渾 疾奄僥 綵葉帙凹 憎渟卒尊藎閃荏 6�6? � 魏惟脣 悛蔡孼猥, 惟宸� 執, 前翟� 張 寀宗輦�� 遵�� 調灑桎�, 槍� 壯 蕣典迹 張鴨音 壯婆壯予� 禎懿妬潗 惟將儼執 � 袍增淆 哀應燮閃�, � 特� 菴蟻袍, 鎭� 灑蟻袍! �, � 惟莊� 惟莊荻, 壯 3-�, 壯 4-� 靭��墮 執 槍� 張 午齧飇, 有菴 剪 杖� 鴨循潗��! 콧蓮 涯� 裔騶城顥齧� 剪 憙迹 乙淳裝 鴨張�!
 

쫓�, 稜� 쩜� 顧팠� 죡컵� 컵价農, 芬� 隙金湃잃� 촘鷺쬠� 邱羅缺 鷗 E-MAIL � 쫑턍� 乖 쫑턍터� 來컹農 痼 鷗稜� 훙� � 좇菰 퓽 컵鵠쳄京! 쩜� 컥팍 考 痼켑 痼國喪잃� 豈炚 勍플 � 퓽 쩜� 쫓� 錡탸읖� 干卿輹瑙謹잘 儺購� 좨핏턺 騎喫턍� 6�6!

� 勍謙雇� 쩜唜촘 쫓錄駒터휵 � 좨핏턺 國횰湃� 痼隙喫읖�, 各� 佶탬谷� 干�, � � 干哭� 4-촘 謙裸聆 쬠 鷗喀律瑙 各� 京苦徑� 100.000 켑皆읽侊. � 턺槪 쬠 考 罫弩誥쪘瑙羅 痼 켑喫횻顧鷺�, 鷺 斤핥居弩鷺� 죡켤� 읾祿胱筐휙턺閣� 1.000.000 켑皆읽侊 퓽 촘�!


벬 淪� 錤懇텀 弩干촘 촘芥쫍懇蕁훽탸補光� 堂購藍?�, � 拮近騎瑙 쬠. 컵芥 � 鷺�, 稜� � 國光隙儆� 6�6 퓽芥팍痼 誥쩜� 仝覲沓�, 干鷺隙� 适턺購律쩜텀 100%-谷� 堂購� 쫓턍 當읾魯훗이 좨핏턺� 퓽 懦텀 當텀� 弩閣� 塘胱淪袴配 纛杆掛侊, 干鷺衿� 淪芥쩨淪驥훔 勍플 國罫鷺 考 拮罫适터 壞쩜蘆農. 鷗芬筐� 國光隙儆� 隙죔弩텀! � 隙죔弩텀 죄턺磊芼! 芬� � 綾켑-騎喫턍�, � 干鷺近� 堂購� 좝핥勁� 퓽隙픕�! 拮텍훽� 퓽隙픽農裸 � 쬠!
 

쫌훠익훅!!!
 
 


� 价죔隙鷺瑾� 吉澧珖光휙턺閣� 훼麒탠侊익훔 � 懶� 줆� 國侊탠터 扮拮털훠터�: 國光隙儆� 6�6 줆价 퓽鞠芼痼 16 隙� � 記梗� 隙핌휙谷� 堂芥쪘箱 � � 記梗京 隙핏焙� 拒콘京 � 各淪喫쩨 當읾魯훗侊 좨핏턺�, � 쫓� 16 隙� 胱� 國훤罫훙� 匡훤읨侊排 堂購�, � 考 줆芥 苦 匡誥촘 淪芥쩨各, 干鷺衿� 줆 綾쫓擄侊읫 錤중 适컵愾袴焙 � 适훈터谷�. 弩覺� 拮텅횬槪喫� 國洸픈탸� 痼當谷� 익읫훌 旽誥謙痼 6�6 � 堂弩誥쪘槪, 稜�, 考緊乖伋 痼 쫌텍考� 奈匡喫쫍, 鷗 豈壙� 京懇罫祿錟錄斤 胱� � 干謹� 乖槪戮텀裸 乖 錤瑙쫍촘 缺芹텀훤쳄 � 國횹匡훽 � 考桔읓苦勍 죔愾� 쬠吉閣�, � 記勍� 촉읓誥� � 컵勍懇잃휙谷� 斤핥居弩弩�, �.�. 쫓� 當읾魯훗� 芬光� 좨핏턺� 훠텡� 켑來�. 桔탠� 이털훗익驥휑 좨핏턺謙誥� 芬� 儺購饉近촛이缺 國洸픈탸� 痼喫交謨� 憧近�: 胱� 國曠쩜槪 탤 밆IAMOND STREAM�, 稜� 購斤쫍컹綠� 各� 벪盖의谷� 鷗鷺��. 볁乖狂� � 鷗鷺徑 稜� 컵鵠쳰 瑙柬� 斤干�, � 벪盖의谷�� � 鷗鷺徑 稜� 芬乖 堂購� 弩干� 팍 國愧谷� � 考핼죄턍排, 各� 읫缺�!� � 乖쩨蘆� 匡훤 훌 좨핏턺謙誥� 痼 쫍國罫 干契턺鷗羔터弩 밡EW-YORK TIMES�.
 

&nbps;


찰 杖惟宸� 張 裔涯荏循泣贈, 禎特壬 灑蟻鋪章軫� 誼鴨� 杖特莘 張 哀增嵬筬� � 鍊午�, � 桎蟻惟 遵膣��? 콧 禎桎壬 破� 佺� 茵依 壯 破� � 鍊午� 釣胞�秩�. 昆 蓴� � 杖� 嚴潗 莘桎述� 全釣鴨音杖�, 穽料諺 曾典壬泣尊循牆酷 張 夭� 焌麟麟, � 埰薏胞牆酷 剪 崖昌撓. 孔 夭奄� 竣赤 穽荻儼孼狀� 日孼猥 � 憙� 灑蟻胞� 尊仲廛� � 釣殃前潗. 屢 蓮, 攸� 張 灑嶢�� 穽翟荻城� � 鍊橓� 灑蟻袍 鴨栯軫��麟, 特� 櫛日孼��麟, 展孼� 岫增尊 適暹顥筬秩� 壯 橓淙妖� 麟調! 콧, 疾昶狀 禎橓鳥潗, 破� 溢悅� 診� 岫增尊 調詣謫城奄�, 疾昶狀 穽蘖哀音潗 竣迪 櫛日孼��, 疾昶狀 穽抑增設嶢� 遵�� 楯宗� 仲暹展狀 灑侁執�. 孔 禎橓綜鎭, 嚴泣 찰 憙� 逡言齧鎭, 憙� 增陝奄 循鋪� 頌說佃 � 循鋪� 莘依脣愉槍嶢言茴忽 埰渟軸�! 찰 橓縊 張 修鴨鎭 楫典嶢� � 鎭�, 破� 찰 哀增迹裝 灑蟻瀑莘 埰渟鎚 � 灑蟻瀑莘 灑侁秩軫�? � 禎憙佃� 쭌� 鍊午孼狀 張翟軸怏溢 逡言城� 憙剪 胞� 壯 蓴疾円� � 淸壯章荻迹 張裔淳茁溢增�, � 惟桎尊� 穽外抑奄 쭌� 櫛疾昶杖特增脣 � 憎渟卒尊藎閃溢� 6�6! 淃桎壬 破� 循袍 荀諺� 壯增贍�!
 

"宮調 衆荻 � 茁增諺�..." - 妖鎭躁淆 � 前狀循鎭音� 訟午嚴 茁增諺� 6�6, 漏緘檣荻忽 �.�.
 
 


- 쭘巍� 增釣麟鎭蟻裝� 鎭逸荻 調譽嶢�� 遵震 흡鎭存奄 � 凞焉疾佺狀� 惟壹儼打� 婆衆� 禎蟻吾循鎭音� "蓴諺寮狀� 檉寀妖�" 調增奄 � 溢鷹猥狀卽迹 岫增尊桎�. 臺� 遵暈葉 桎蟻惟 � 嗜葺僚 � 遵震 흡鎭存奄 臆抑張純� 禎殃誼妬�秩� 灑音� 2000 特依橓�, 壯 행檉鴨 � � 懶� 憙� 打替� � 張仲鏑獪� 調� 灑蟻袍. � 尊增佃 婆衆� 禎蟻吾循鎭音� 흡鎭存奄 調增奄 � 惟泣特增脣 調俉料狀莘 震檉 訟午嚴 穽謫調壹. � 魏輦忽 厓諺 佺� 禎蟻奧�秩� 蓴� 灑蟻袍� 禎艇��存前潗� � 憙� 嚴鎭增橓牆�, 橓縊 凞焉疾佺壯� 惟壹儼打� - 訟午嚴 21 橓魏. 孔 訟午嚴 茁增諺� 6�6 穽億前軸怏� 蓴� 前診蟻裝� 壯 張仲鏑獪� 禎��殃荻 - 翟 憙佃 溢悅� 憎怏潗 紳��� 壯 桎 魏惟� 埰渟� 佺� 穽妖前嶢 蓴諺 檍 惟逸陝蛔壯�. � 蓴� 蓮 � 特� 檍 穽堰壬緘增脣 壯� 崖昌夭� 訟午嚴 穽謫調壹閃� 陝贍謫料狀莘 震檉, 禎特壬 佺� 穽妖前嶢 埰渟� 蓴諺 檍 綵葉帙凹閃, � 張 桎蟻惟 檍 前狀循鎭誼 � 鎭� 攸� "增迪� � 尿桎惟�"?

- 콧, 찰 櫛橓淙孼狀 穽設� 壯甑奄 增釣麟鎭蟻狀莘 調譽嶢�� 凞焉疾佺狀� 惟壹儼打� � 禎�瞬孼�� 灑蟻瀑莘 惟泣特增循 訟午嚴 茁增諺 陝贍謫料裝� 6�6.

厥臆鴨 特� 調嗚褻剪城� 穽謫調壹� 6�6 � 純夭城言茴� 了綵堯 蓴� 憎緘增詢�陷� 壯 菴牆渾 溢靭粧 茁增諺� � 禎��� 魏� 佺� 禎�淳泣贈. 昆橓存赤 蓴� 禎日�� 鎭 翟泣侁打�, 惟桎終� 岫泣 診� 禎艇��存� � 壯� � 90-� 莘液. 腦� 脣� � 調譽嶢猥� 흡鎭存奄 攸�-桎 菴音孺� 剪 惟逸淆鎭存紅 鎭蹴鏑謫僥 � 午陝僥 穽妖打檉 調灑執 "蓴諺寮狀� 檉寀妖�" 穽前桎 渟釣張� 憙� 穽謫調壹� � 翟泣侁打�麟 � 遵潗. 콧, 巍�� 愼杖贍茴�, 前翟孼狀 秧� 鎭� 荀諺孼 - 診� 찰 荀�� 泣 壯藕奄� � 5 幽猥粧荻, � 遵震 蓮 溢悅� 調葺魂城� 執��婆 釣幽閃裝� 炡遵�. 孔 憙� 茁增諺� 夭言� 日跡嚴軫� 張哀增城惟�: 張哀有靭粧寮荻陝狀增� 桎莘, 魏� 調葺魂城� 灑蟻瀑� 惟泣特增脣 釣幽閃�, 宸� 鎖城� 執��婆 雪釣櫛� 凞焉疾佺狀� 禎破� � �.�. 邏荏� 紳設裝� 張哀增城惟� 岫依 桎, 破� 憙� 穽謫調壹� 岫乙 調葺婆診壯 壯 衆曜惟� 特增裝� 誼鴨�. � 釣幽閃狀� 炡贈靭 櫛鴨阻贍葉� 切鏃�, 陝贍謫料壯� 壯袍� 訟午嚴-診頌擾�, 櫛紳葉狀 惟桎尊� 蓴膣檉馴猥 � 茁增諺� 哀飮裝 岫泣 禎有檉潗 桎循存酷 抑妖擾� 茁增諺� (魏輦策 � 調午謫� 綵葉帙凹�). 柑炡� 撓 佺� 哀飮裝 岫泣 增設嶢� 竣迪 釣侑了嶢� 壯穽剪外 渟躁迹 桎循存迹 抑妖擾�, � 蓴嶪 前診蟻裝� 逡淳侁潗 壯 賊妖 債荻孼� 杖蓮. 腦� 魏� 撓 杖攸� 張 惟粧尊泣尊循� � 撓 脣音 岫依 了靭��潗 診頌擾� 魏� 昌賊狀. 絞� 剪愉顥贍� 張仲鏑獪� 褻佺孼帙紅 �陷惟� 壯 調俉料裝� 夭孼� � 調午紅 禎破荻紅 剪鴨音杖�� 莘尊菴 � 增設堯� 釣侑了嶢� 憙撓 �.�. "靭倧述� 涯�" � 診頌擾� 筍嚴桎 穽抑或蔡撓 綵葉帙凹荻, �.�. 茁增諺� 翟終循乙贈. 흔-裔 憙謫� 佺� 調灑診乙 桎蟻惟 壯 100% 壯 渟躁佃 債荻張, 1% - 壯 蕣典佃, 0,1% - 壯 疾奄會� � 0% - 壯 特軫儼桎�. 厥蟾震特仲� 裔調灑桎� 袍� 桎蟻惟 � 渟躁謫� 債荻��, �.�. � 穽�荏� 穽賊剡, 破� 穽� 調葺魂劉 3.000 釣幽閃裝� 炡遵� � 鴨贓 櫛增設��依 適鏑� $300 - $400 � 靭���. 孔 憎潗 訟午嚴 茁增諺 診惟莘 震檉 - 穽妖前嶢� 茵揄夭脹 穽矮魂� 裔 甑奄 2-� 禎衆抑杖� 債荻張�. �.�. 찰 調葺魂齧鎭 檉倧療 炡遵� � 釣幽閃迹, 壯穽夭儼, 10.000 剽., 禎懿妬奄� 30 裔魏吾� 壯 桎循存策 抑妖擾� 渟躁謫� 債荻�� � 菴蟻袍 � 鎭特杖� 張仲鏑獪撓 音� 茁增諺� 調灑診奄 壯 쭌�. 孔 日謫撓 埰疾殲循泣 憙� $300 - $400 � 靭���, � 佺� 調葺魂贍� 禎 3.000 炡遵� � 鴨贓, 剪愉顥 張仲鏑獪� 褻佺孼帙紅 �陷惟� � 禎增設外 竣迪 釣侑了嶢� 橓醴�, 宸� 桎蟻惟 溢悅�. 腦� 魏� 桎循存酷 抑妖擾� 禎 竣赤� 憎震 杖特莘 張 櫛鴨阻贍�, 愉佃� 壯譽陝�� � 釣幽閃狀� 炡贈靭, 桎 禎懿妬依贈, 破� 調灑診� � 診惟� 茁增諺迹 찰, 惟 蓴諺� 穽展諺�, 余� � 翟茵裝循泣 竣迪� 幽猥粧荻.

昆橓存赤, 張� 重汞乙 全尿顥城� 蓴� 前診蟻裝� 陝贍謫料狀莘 震檉 訟午嚴 茁增諺� - �.�. 佺� � 修侑贍茴佃 重汞音 �瞬��秩� 惟炡�麟 穽抑或蔡彦. 콧, 夭孼狀 診� 佺� � 禎�淳泣贈 - 惟炡尊循乙贈 憎潗 � 了靭��泣贈 蕣典前鎭渟牆酷 牒攸典�, 診孺� 魏�, 壯譽陝�� 桎循存紅 抑妖擾, 楫前翟� 全乙執, 櫛鴨阻陝猥 釣幽閃狀莘 炡贈茵 � �.�. � 杖� 蓴嶪 溢悅� 仲暹城� 賊狀: 蓴� 佺� "櫛醴陝�" (嚴泣 溢悅� 穽夭孼嶢� 憙� 衆荻� � 婆增迹 脣液 町說歪膣) 張穽塼嚴茁佺贍閃�, 誼縊麟 菴音孺麟 魏� 剪 訟午嚴� 脣翟緘 (破� 診惟� 凞焉疾佺壯� 惟壹儼打� - 佺� � 禎��震� 張 夭廬�!), 診� � 剪 惟逸淆鎭存紅 鎭蹴鏑謫僥 � 遵震 흡鎭存奄. 孔 焌茵 巍�� 櫛醴城� 診惟莘 尊菴 訟午嚴 茁增諺� - 愼杖贍茴�. 蛟翟孼狀 � 壯袍 荀諺� - 荀諺� 修存謫� 調譽嶢�� 遵震 흡鎭存奄 � 凞焉疾佺狀� 惟壹儼打�. � 嚴泣 尿幽�婆潗 張哀增城孺, 桎 診惟� 茁增諺� 墮裝 張�! 찰 桎蟻惟 穽抑增設獲� 遵悚 特� 修鴨� 흡鎭存奄 軸�� 岫 音� 特釣� ��潗!

� 艇增� 裔菴妬 岫乙 張音神迹, 蓴� 蓮 日� 昶贍前� 調嗚褻剪城� 夭孼狀 診有� 訟午嚴 茁增諺�.

袞哀有靭粧寮荻陝狀增� 桎莘 宸� � 魏� 壯軸怏潗 雪釣焌 凞焉疾佺狀� 禎破�, 魏� 壯 杖� 調葺魂城� 謫尊日赤 惟泣特增脣 釣幽閃裝� 炡遵� � 穽展猥 鎭蹴料嚴孺� 鴨診泣 � 惟逸孼茁尊循� 楫業歪蟻狀 調嗚褻剪陝裝麟 穽謫調壹閃� 秧� 設桎茵震裔打� 憙謫� 穽專嚴焌, 禎譽鏑外鋪麟 調葺魂城� 5-20 執��� 釣幽閃裝� 炡遵� � 鴨贓, 裔疾城外 蓴憶� 30-40 麟腸� 櫛衰軫孼狀莘 荀諺孼�, 壯寥賊尊殺彦鋪� 全尿陝猥� 調灑執 � 杖麟, 壯炡焌牆忽 �晤惟� 禎��帙忽 秧� 禎蟻吾循鎭�� 誼灑莘 債荻�� � 灑蟻鋪� 惟泣特增脣� 櫛橓桎� � 釣惟靭庄惺僥. 痢� 禎 憎震 愴堯 汁暹� 壓採 裔云億: 午成嶢言茴� 禎述茁� 穽迪譽賊嶢言茴前潗 訟午嚴 茁增諺� � 逡言贍 桎循存酷 抑妖擾� 張 桎 破� 禎音午忽� - 穽前桎 張翟軸怏荏麟 秧� 綵葉帙凹� 訟午嚴 茁增諺� (舜尊特�, 魏� � 秧� 誼灑莘 裔杖茵�緘莘�� 釣幽閃迹 � 遵震 흡鎭存奄), �.�. 夭孼狀 佺� 櫛鴨阻城 楫業歪蟻裝� 穽謫調壹� � 全尿陝猥 調灑執 � 杖麟.

袞特增狀增� 綵葉帙凹荻 穽嚴焉 翟�裔鎭蟻狀� 釣燼增調打彦 � 紳設狀� 惟粧典� 6X6 MLM Corporation (禎崖翟張� � 調醴言� "행陷診 剪 翟茵壯").

�.�. 茁增諺� 張 翟終循奄��, 哀蓀淳� 余� 2 債荻��, �.�. 蓴憶� � 茁增諺� 6 債荻張� (禎 $6 裔 桎循存策 抑妖擾� 魏輦謫� 債荻�� - 剪只菴 � 壯譽陝猥 "6X6").

烙言贍 灑音� 燼送迹 茁增諺� 全乙執 裔魏吾�. 屢渟綜 桎循存酷 抑妖擾� 溢悅� 全乙婆循潗 魏� "疾雪擾姚牆忽" 裔魏午忽 設歪炡贈溢�, 診� � 渟釣脣哀� 壯 蓀檣荻仲僥 甑奄. 孔 裔穽奄堯 瘡暹顥城� � 魏特增橓 雪釣焌 秧� 全乙執 褻佺孼帙酷 �陷孺 - 脣-渟躁紅, 秧� 了悚縯杖� 翟茵壯, 脣-蕣典紅, 破翟� 訟午嚴 茁增諺� 張 鎭��乙 竣赤� 穽外音魏鎭蟻狀增�. 희軸�� 了 診孺� 蓮 櫛翟調蓮杖�, 裔穽奄堯 茁增諺� 全乙執 WebMoney.

행幽�婆� 哀莘脣� � iWin Loto Ltd. 腦� 破� 穽� 釣燼增調打� � 壯袍� 紳設狀� 惟粧典� 찰 設桎茵震特仲� 盾誼妬奄嚴� � 依鎭釣�, 穽料諺 쭌鋪 胞章� 述嵬調潗 穽�溢 穽全典打佺贍茴� 惟泣特增詢 穽賊陝裝� Chapter#1.
 

較晤述 壯鋪� 惟逸陝蛔狀�
 
 


찔諺 穽外奄! 爛予� 禎鴨泣潗�� � 쭌麟 舜円城音杖諺 剪 穽謫調壹� 6�6, 破翟� 찰, 張 菴� 즈�, 張 穽廛泣 麟溢. 勸贈溢 穽曜依 壯 e-mail 溢諺� 壬閱. 絞 釣鋪� 禎橓遵泣潗 靭�� � 禎譽贍 禎婆診潗, 볤蟾策 乙酊� 遵暈葉 壯 菜� 橓胞���. � 張 前翟� 純凹乙 � 茁增諺�, 菴 前翟� � 張 增燮贍葉� 破�-桎 禎��潗, 禎桎壬 破� 張 橓鳥乙 � 診惟莘 尊菴 楫前翟� 裔調灑叱�, �.�. 張 裔軸鎭乙 裔調灑診潗 100.000 哀應燮荻. 孔, � 溢諺� 甑葉潗�, 憙� 打替� 蓴� 愉寀堯葉� � 溢諺 溢豫� � 張 菴循乙 楫城�. � 蓴�-診孺, � 惟莊� 惟莊荻, � 釣鋪乙 剪循悅� 鎖前嶢劃� 壯 炡贈溢. � 甑葉潗�, 壬� 憶� 余� 張 增儼. � 竣赤壬 昶外音杖�, 婆診� 2-� 調�, � 蓴� 禎杖茵乙. � 焌溢� 紳設狀�, 破� � ��卽堯�, 憙� 桎, 破� 壯穽�侁潗��-桎 禎破� 張 壯哀! � 荀諺孼� � 鴨張蓮� 竣迪� 桎蓮 禎破� 疾城嶢� 張 壯哀. � 桎壬 蓮 靭��, 魏� � 쭌�, 穽外音幽� 桎, 破� 蓴� 鴨乙奄 惟逸獲儼 � 破� 張 腸悅� 杖特壬 綵嶢劃�, �.�. 贍莘鳥嫉 調灑執 禎崖翟狀 全尿陝 � Chapter`性! � 翟緘�, 釣鋪乙 �, 岫乙 � 張 岫乙. 淃穽翟策! 행 壓� 張鴨泣 � 調吾衆贍� 適鏑� 30.000 炡遵� � 釣鋪乙, 破� � 靭�� 騶城嶢. 痢釣� 張仲鏑獪� 厓彦 增贍� 穽撓賊嶢� 裔魏晤 � 穽曜言 31 裔魏� 壯 1-策 妬增� � $186 哀 惟莊� 靭��稱. 벾�, - 涯茵�, - 禎幅� 鴨依�. � 鎭特杖� 衆抑策陷� 壓採 靭��墮� 穽撓賊堯� 余� 裔魏晤 壯 1 妬增� � 穽曜依 適鏑� 5.000 裔魏吾� 壯 2,3,4 � 5 妬增� � $30.000! 光�! 竟��� 楫埰�� � 靭�� 岫依 槍� 灑音� $110.000! 控, � 禎桎� 增贍� 櫛蓴諺 幽葉卽� � � 裝張曝諺� 溢靭粧� 鴨贓燼 穽賊鏑縯�� 穽矮顥城�, � � 靭�� 賊壯 穽翟音茵 � 有菴 岫 撓 鴨潗?! � 涯茵�, 牒粧暹�� � 쭌� 調灑診奄, � 찰 溢蓮鎭 遵悚 穽抑增設嶢�, 仲鏑獪� 昶荻鏑劃軫僥 溢悅� 哀增設��潗 遵悚, 夭�� 診孺� 鴨贓燼!

쭌音粧妖�, �. 輕仲循.

 


헉調蓴軫猖鎭, 敞剡齧荏� 莘楫賊� � 菴荏! 袞 診� 菴純� � 禎蔭賊� 壯裔� �, 診� 蓮 魏� � 찰, 茁鴨� � 婆診� 炡贈溢, 穽曜抑袍� 壯 溢� e-mail. �, 魏� 灑蟻鋪章軫� 了 쭌�, � 鎭雕贍�� 櫛日孼��麟. 蠣��, 嚴泣 禎重剪釣潗 疾偃脣 � 張禎��帙� 禎特壬. 쮜厓�, 診� 穽外琿 特依橓�, 蓴憶� 灑�潗�� � 增調鋪潗��. 콧, 橓泣孺 岫泣 紳暹� � 溢憶� 增調鎚, 狀 � 釣鋪� 禎穽翟荻城�. 쭤縊 � 焌溢� 槍葉狀� 衆綵齧 � 杖特莘 張 禎鎭���, 愉佃� 張仲鏑獪撓 妬櫛� 荀諺孼�, 惟桎尊� � 診� � 靭�� 疾城嶢劃� 悚葺荏衆孼狀, � 桎蟻惟 滄壯� 禎灑蟻袍 � 調灑鎭 惟逸淆鎭調 � 憶� 全震麟裔打�. � 桎壬 蓮 � 禎涯茵�, 破� 軸潗 賊狀莘 特依橓魏 � 桎杷� 壯藕�, 破翟� 橓存寀� 竣迪 $6 裔 渟躁策 妬增�. 袞 修涯 寀佃��潗 쭌� 禎崖翟狀增�麟. � 穽前桎 特叱� � 哀仲佺贍茴� 述禎鷹�� 蓴� 穽設堯� 訟午嚴 茁增諺� 6�6. � � 鎭特杖� 4-� 靭��墮� � 裔調灑診� 120.000 哀應燮荻! � 憙� � 溢� 25 音�! 屢渟綜 � 修涯 惟應焉打佺寮荻城� 穽迪譽抑孼�� 尿有葺軫�! 咬 憙佃 蓴憶菴 � 靭破贍. 控 � 遵暈葉 � 抑�, 張 重彦鎭贈, 壯 璥蟻典有 � 竣雪齬狀� 艇鎭袍增淳� � 誼訟溢�, 惟桎調� 張 埰桎�乙 渟釣� 溢夭 灑侁秩軫佃. 屢渟綜 � 蓴� 鍊午� 舜儼抑�! 憾葉外�� � 甑葉姪外��, � 灑侁秩軫� � 尊仲廛� � 6�6!!!

잼焉焌庄�, �. 邏檣�-躬鎭趙債�.

 


� 渟躁渾 調� � 惟檣釣帙� 增典溢預�, 昶贍外 炡贈溢 � 穽謫調壹� 6�6. � 余� 禎重��宜� 壯� 鎭�, 破� 攸�-桎 楯宗� 增陝奄 日� 衆城� 鴨贓燼. � 魏� 蓮 � 穽適泣壯� 竣澱 張哀橓棕外前潗, 惟宸� 禎譽佺堯 鎖城 了 孔脣尊葺僥仲� � 調葺魏裔� 日� 魏� 調� 翟 憙佃 訟午嚴� � � 桎�, 魏魏� 憙� 幽葉卽�� 剽瘡�! 間惟� � 涯調�! 쭤縊 � 蓮 焌� 靭破贍 增城� 灑侁執�, 魏� 蓮 余� � 溢身 岫增尊 調詣謫城奄�, 嚴泣 張 � 禎溢缸� 脣� 診惟莘 訟午嚴�? � 惟宸� 特釣� 靭��� 炡贈溢 卽荻� 壯幅� 靭��, � 槍� 岫� 脹張�. 凌� 蓮 洵�宜� 裔 鴨依 � 調吾衆贍 適鏑� 70 執��� 炡遵� 禎 凞焉疾佺狀� 禎破�. 較幽凹 岫� 禎破� 認狀橓牆忽 (嚴潗 余� 脹裝� 誼怏 壯 竣奄�!). � 剪 Chapter`荻 � 全尿陝猥� � 脣翟緘 翟贍鴨�, 前翟孼狀 剪 禎衆抑張莘! 璥依 桎莘 破� � 汁暹� 禎��� 魏� 調灑診潗 � 茁增諺迹, 鎭渟綜 � 溢� Celeron 300 調灑診奄 岫增釣�, 特� Celeron 466 溢憶� 崖昌�! 毘� 昶外嶢言茴� � 疾城曜� 張 灑蟻袍 禎懿妬焌 � 鴨贓 壯 調灑膣 � 6�6 � 禎懿妬予� 診孺� 鴨贓燼!!! 嵌尊特, 菴蟻袍 蓴� 禎幅� 魏� 禎 茵衆�. 톤抑張純� 禎破贍蛔� 穽妖前堯 禎 10 - 15 惟將儼桎�, � 魏輦佃 了 惟桎終� 禎 $6! Yes-s! 毘� 剽瘡� 裔調灑診乙!!! � � 余� 張 橓鳥�! 찌�, 頌妖, 渟贓! 厥設 岫� 鎖城言乙! � 破� 壯妬依贈 禎桎�! 嵌宸� � 增贍 穽賊設城� 2 妬增�, 魏輦渾 鴨贓 日� 穽妖前堯� 禎 20-30 惟將儼桎� � 有靖調麟. 控, � 惟宸� � 裔��宜� 3, 4, 5 � 6 妬增�麟, � 穽前桎 張 午贍 有菴 剪 杖� 鴨循潗��! 昆 穽廛依� 張鴨音 � 有炡� 遵悚 狀述� 밚incoln Navigator�. 勘葉卽渾 仰寥! 찔憶菴 靭破贍 � 診惟�! � 魏惟� 岫 涯存佃 壯增尊孼僚 � 杖 穽前腸宜� 寀尊�, 增迪� 日� 蓴禎日嶢� � 溢諺 竣儼魏�緘� 壯 櫛鷹墮 仰寥�, � 壯婆壯� 罷蓴軫荻城� 遵�� 焌荏� 甑葉姪外忽 特依橓惟� 壯 樂奄�! � 蓴� � 頌說賊燮� 憎渟卒尊藎閃靭 6�6!!! 勸彪 憙� � 壯鴨輦迹, 破� 溢� 債適 張橓鳥� 禎藕奄 쭌� 壯 禎蟻奧, � 述 張 增陝奄�, 魏� � � 渟躁渾 調�, 昶贍�潗 了 竣赤莘 惟逸淆鎭調 憙� 炡贈溢, 惟桎尊� 夭檍� 穽��帙赤 竣迹增脣 穽億調咸潗�� � 張謫調杖特牆赤 惟泣特增脣 鴨張�! 擡成� 쭌�!

흇典�, �. 찌蔭謫調�.

 


� 汁暹� 遵遭墮� 悛寀堯�, 破� 憙� 溢� 胞章! 昆惟張�-桎 尿禎鷹嶢�� 裔橓帙�� 靭破� 溢憶� 鴨秩軫� � 蒸偃怏潗 � 잽儼凹�! � � 昶荻鏑劃軫猥� 穽妖�乙贈 綵葉軫荻城� � 穽謫調壹� 6�6. 孔 禎 壯妬懿 櫛日億贍葉�, 昶葉潗�� 泣 日� 壯煜� 診� 日謫� 雪釣櫛� e-mail. 嶠壯惟, 惟宸� 穽曜泣 Chapter`� � 全尿陝猥�, 桎 筍嚴鎭 � 杖麟 穽曜依 翟��卽孼猥, 魏� 音神�, 悚� 蓴�孺� 穽翟音� 溢悅� 壯煜� 仲鏑獪� 昌賊狀 雪釣櫛� 凞焉疾佺狀� 禎破�. 행 靭��� � 調吾衆贍� 灑音� 150.000 炡遵�, � 戱輒攸 張 裔增設堯 遵�� 哀蔭� 輦城� � � 禎懿婆乙 68 裔魏吾� 壯 渟躁策 紳設�! � 惟莊� 惟莊荻, � 裔調灑診乙 170 執��� 哀應燮荻!!! 屢渟綜 �, 禎縯懿�, 渟釣悚宗贈 � 잽儼凹� 壯 櫛蓴諺. 那魂葉� 溢� 莘懿蓀� 靭破�! 爛葉矮�, 哀尊侁� 6�6! � 余� 楫葉矮� 裔 昶外嶢言茴赤 全尿陝猥 調灑執 � 茁增諺迹. 펙乙� 蓴諺 쭌� 增城� 診孺麟 蓮 甑葉姪外忽�, 魏� � �, 頌說賊燮� 憎渟卒尊藎閃靭 6�6!

璥鳥壯, �. 矜侁.

페諺 쭌鋪� 剪晤脣�. 厥尿魂纖鎭 撓 壯 雪釣� 紳設狀� 惟粧典�.
稜� 팍 弩干� 6�6?
 
 


흰蟾, 裔調蓀執循潗 有婆 鴨張�, 張 述軸�� 了 哀茵! 벬剪 憙� 胞章!�, � 脣仲泣悠嶢� 찰, 前蹟壯�, 破� 杖有菴 張 腸悅� 軸怏潗, 杖惟莘 張 腸悅� 昌荻燮外城�, � 桎蟻惟 午纖 遵悚 � 禎證乙� e-mail`� � 禎懿妬� 穽矮魂�! 벪 破� 蓮 秧� 憙謫� 腸悅� 鴨乙潗?� � 張了悚蓮� 脣穽前. 쾰� 桎莘, 破翟 裔調灑診潗 有罷 鴨張�, � 夭孼狀 � 100.000 哀應燮荻 � 灑音�, 秧� 壯妬乙 쭌� 腸悅� 修鴨� 裔釣燼增鳥尊循潗�� � 紳設狀� 惟粧典� 6�6 MLM Corporation � 禎懿婆潗 竣迹 泣杷渾 釣燼增調打佺裝� 狀靭�. 찔膣炡� � 6�6, 찰 增陝荻嶢嚴� 調楫尊增調杖鎭音� 禎 흡鎭存奄� Chapter`荻 (紳設) � 壯寥賊尊殺彦鋪� 全尿陝猥� 調灑執 � 訟午嚴 茁增諺迹 6�6 � 全震麟裔打� 惟逸淆鎭調 (禎崖翟張� � 杖� � 衆抑策緘� 調醴言�). 勘猥粧閃� 쭌袍莘 訟午嚴� 增陝荻�秩� 誼怏, 惟桎終� 憙� 紳設� 裔妖鎭釣憎��. � 紳設� 穽前桎 張 溢身� 張 裔妖鎭釣櫛循潗 - 佺� 櫛鴨阻城 艙凹贍茴策 妖切鏃惺療, 穽前桎 張翟軸怏壬� 秧� 誼灑莘, 攸� 軸特� 哀訟潗�� 埰渟鎚 � 遵鎭脣� 茵簇奄妖愼! 憾佃� 桎莘, 誼鴨� 裔妖鎭釣憎奄 焌� 訟午嚴, � 蓴� 憙� �瞬�奄�� 侁調粧猥� 桎莘, 破� 誼怏 張穽諺孼狀 修涯� 剪幽凹城劃� 壯 쭌袍 炡贈溢. 燐� 憙� 裔 炡贈溢? 毘� � 桎 焌溢� 炡贈溢, 惟桎尊� 찰 禎懿婆鎭 禎衆� 釣燼增調打� � 紳設狀� 惟粧典� 6�6 MLM Corporation (剪泣妬奄�� 剪 炡贈茵, 惟桎尊� 찰 遵暈葉 婆診奄�, 穽尿寀增淳諺 쭌袍莘 釣燼增調打佺狀莘 狀靭調 � 訟午嚴-診頌擾�). 찰 穽前桎 剪穽設��奄� 憶� 魏� 溢悅� 灑蟻袍壬 惟泣特增詢 誼鴨�. 淃崖翟張� � 桎�, 魏� 壯煜� 悚仲佺円狀� 惟泣特增脣 e-mail`荻, 設桎茵震特仲� 調吾衆城� 壯 杖� 釣幽閃狀� 炡贈溢 � 日謫赤 崖昌赤 찰 滄壯奄� 張禎汁抑增橓牆� � 焌麟� 紳設性. 퇸泣 찰 涯茵奄�: 벿叱昶� 脣梧靭秩� 診� 日謫� 雪釣櫛�?�, 桎 憙� 張 增迪� 桎莘, 破翟� 悚楫適迪潗��. 톤抑張純� 桎蟻惟 � 嗜葺僚 � 흡鎭存奄� 禎殃誼妬�秩� 麟杖壬� 2000 狀述� 禎蟻吾循鎭音�!!! 昆 蓴嶪 騶城嶢! 淃衆� 桎莘 魏� 찰 剪穽設嶢� 裔�盾� 壯 釣燼增調打�, 쭌� 穽僥鴨� 炡贈溢, 櫛鴨阻晟檍:

1) 쭌� 釣燼增調打佺裝� 狀靭�,

2) 給幽閃狀� 炡贈溢 � 쭌鋪� 釣燼增調打佺裝� 狀靭尊� � 訟午嚴-診頌擾�, 惟桎尊� 찰 修鴨鎭 調葺魂城�,

3) 給侑了嶢� 前診蟻裝� 綵葉帙凹荻 訟午嚴 茁增諺� 6�6, � 惟桎終� 쭌� 張翟軸怏溢 裔魏裔潗 Chapter`�, 魏輦渾 � 調午謫� (尿幽�特杖� 櫛增設��奄 桎蟻惟 茵增儼) � 櫛剪橓秩軫僚 � 調症搖尊循牆迹 訟午嚴-診頌擾彦, 破翟� 찰 焌麟 夭言� 脣傲跡狀增� 穽賊設城� 撓 竣迪� 裔魏惡凹閃.

쯧嚴鎭 � 憙夭 찰 禎懿婆鎭 診唯� � 菴蟻張橒猥 瘡暹陝�� 穽謫調壹� 6�6. 控 � 桎, 破� 쭌� 腸悅� 修鴨� 逡言城� 汁暹� 遵暈葉, 全尿陝� 杖蓮 � 淳鴨 特叱謫� 贍莘鳥嫉�, 禎憙佃� 禎魏 穽前桎 窓荻嶢� 憎潗. 흰蟾, 찰 翟乙菴奄� 蓴諺� 紳設閃� � 調葺魂齧鎭 炡贈溢, � 惟桎尊� � 魏特增橓 釣幽閃� 櫛鴨阻嶢�� 穽抑尿依淳� � 憙夭 昶外嶢言茴忽 紳設閃. 厥展嶢設 憶�, 特依橓�, 禎懿婆馴僥 剪 쭌� 炡贈溢, 張穽諺孼狀 裔軸特� 蓴膣炡潗 � 訟午嚴 茁增諺� 6�6 � 穽展嶢城� 蓴� 紳設�. 孔 菴蓮 嚴泣 楯宗� 佺 張 裔軸特� 婆診潗 Chapter`�, 佺 壯橓存�魏 裔妖鎭釣憎奄�� 艙凹贍茴迹 脣傲跡狀增淆 裔調灑診潗 麟應姚裝 穽蟾震特仲� 悚� 蓴�孺� 裔疾城, 魏� 禎 鴨贓侁�, 診� � 禎 荀諺孼�! 煖紳葉嶢嚴�, 剪 憙謫� 穽前桎 張脣傲跡狀 剪魏裔潗��! 厥夭儼狀 特釣� 2 張鴨泣 櫛 厓� 壯妬乙 調葺魂孺 찰 禎懿婆鎭 裔魏晤 壯 渟躁策 紳設� � 町城� 裔 張� (� 調傲儼� 6 哀應燮荻 懶�) 剪 30-震 特依橓� � 灑音�. 腦孺� 翟調吾�, 쭌� 渟躁渾 哀軸� 櫛增設嶢 麟杖壬� � $180. � 憙� � 桎蟻惟 壯妬依! 厥� 釣燼增調打� 찰 修鴨鎭 設桎茵震特仲� 盾誼特裝 � 依鎭釣� 剪 iWin Loto - 賊狀� 了 焌荏� 禎艇��存紅 壯 행檉鴨 � � 懶� 惟逸陝僥 裔杖茵�陷椿� 依桎-訟午嚴佃, 紳設裝� 穽了 惟桎尊� - $5.000.000 (診唯� 調晤藎顥齧秩� 5 穽了荻 禎 $1.000.000, 100 穽了荻 禎 $100.000 � 灑音� 5 執��� 淸鏃孼裝� 締賑鏑適 剪 6�6 MLM Corporation, 尊晤藎鴻� 穽荻賊�秩� 魏輦渾 靭���) � 特� 灑蟻袍 찰 禎懿婆鎭 裔魏吾� 壯 Chapter#1, 鎭� 灑蟻袍 胞章荻 述嵬調潗 紳設裝� 穽了. 찰 淳怏鎭?!!! 찔�, 破� 剪 쭌� 疾齬暢秩�, 憙� 調吾衆城� 禎灑蟻袍 釣幽閃裝� 炡遵�. 찔� 쭌胞 調灑診 修鴨� 裔幽�妬潗�� 桎蟻惟 � 桎�, 破翟� 荀諺� 剪 荀諺孼� 穽荻儼�潗 竣迹 禎破荻渾 �陷� 堯� 軸怏潗 � 蓀檣 裔 壯泣杷忽� � 哀茵, � 震鋪張 禎愛婆執循潗 蓴� 壯調增筬姮� 穽矮魂�! 축調粧佃 쭌袍莘 莘依脣愉槍嶢言茴謫� 埰渟鎚 � 壯鴨悅忽 櫛�午凹佃 增陝荻嶢�� 焌茵� 藎陝怏蹟壯� � 麟釣 惟逸淆鎭存�� 憎渟卒尊藎閃茵 6�6!!!
 

CHAPTER`�
 
 


Chapter`� (堯� 紳設�) � 憙� 禎崖翟張橒檍 全尿陝猥 訟午嚴 茁增諺� 6�6, 櫛橓執 � 桎� 魏� 全震茵蟻狀 調灑診潗 � 茁增諺迹 � 壯增尊嶢� 秧� 憙謫� 竣迹 惟逸淆鎭�. 厥展嶢設 撓 찰 禎雩奄� 魏� 張 穽堯說�� 前翟紅 埰堯僥 窓綵鋪潗 竣�梧 � 흡鎭存奄, 壯軸怏潗 禎 5-20 執�. e-mail`荻 � 鴨贓, 翟調蓀執循潗 撓, 調葺魂城� 禎 5-20 釣幽閃裝� 炡遵� � 鴨贓, 禎述茁潗 穽迪譽賊嶢言茴前潗 竣赤莘 惟逸淆鎭調 壯 50% � 日謫赤 崖昌赤.

Chapter`� 壯炡焌裝 �晤惟� 禎��帙忽 秧� 禎蟻吾循鎭�� 誼灑莘 債荻��, 禎憙佃� 秧� 調灑執 � 訟午嚴 茁增諺迹 6�6 쭌� 張 腸悅� 岫潗 穽謫調壹尿桎� 堯� 夭奄� 全泓 調灑執 � 惟逸淆鎭尊�. 즈音� 桎莘, 嚴泣 찰 桎蟻惟 順儼� 遵泣 裔 惟逸淆鎭� � 脣翟緘 張 午齧鎭 杖特莘 � 調灑鎭 � 杖�, 桎 穽展嶢設 純夭城言茴� 紳設� � 禎調灑診� 張惟桎尊� 荀諺� � 訟午嚴 茁增諺迹 6�6 찰 蓴惟釣 增陝奄� 穽賊淳腸執� 禎蟻吾循鎭音�, 午筬陷� 蓴� 翟 全儼惺姚牆迹 茁增諺� Windows � 흡鎭存奄�. 憾佃� 桎莘 � 魏輦迹 紳設� 穽堯說齧秩� 穽謫調壹� 秧� 調灑執 � 茁增諺迹 6�6 � 張惟桎尊� 惟泣特增脣 e-mail`荻.

爛尿適 Chapter`荻:

Chapter#1 벬橓鴨杖� � 訟午嚴 茁增諺� 6�6. 膠震麟裔打� 妖鎭存奄 櫛抑妖孼��. 及打佺贍茴赤 尿禎蟻吾循杖� 妖鎭存奄 荀諺孼�.�

+20.000 e-mail 雪釣櫛�
+穽謫調壹� 秧� 禎狎儼列� 增褻堯茴謫� 櫛抑妖孼�� � 흡鎭存奄, 設桎茵震特仲謫� 脣葺診狀瞬孼�� 竣�預 穽� 檍 翟終循�, 哀譽佺�/調嗚顥� 竣�預 � 裔菴牆赤 荀諺� � 裔艇仲� 哀禎鷹嶢言茴紅 穽謫調� 穽� 壯妬音 櫛抑妖孼�� � 調嗚顥性 竣�預/渟釣譽佺性, � 禎鷹赤 全尿陝猥 調灑執 � 穽謫調壹迹.

Chapter#2 벹蟾 壯軸怏潗 5-20 執��� e-mail 雪釣櫛� � 鴨贓, 茁�� 裔 惟逸淆鎭尊� 30-40 麟腸�.�

+10.000 e-mail 雪釣櫛�
+穽謫調壹� 秧� 設桎茵震特仲謫� 盾誼特杖�/述幽�特杖� 穽謫調壹� 秧� 禎尿魏 e-mail`荻 穽� 櫛抑妖孼僚/調嗚顥� 竣�預 � 흡鎭存奄, 禎崖翟狀 全尿陝壯� � 穽抑或蔡彦 紳設�.

Chapter#3 벹蟾 翟調蓀執循潗 壯藕孼裝� e-mail 雪釣焌.�

+10.000 e-mail 雪釣櫛�
+穽謫調壹� 秧� 設桎茵震特仲謫� 禎尿魏 e-mail 雪釣櫛�, 禎崖翟狀 全尿陝壯� � 穽抑或蔡彦 紳設�.

Chapter#4 벹蟾 調葺魂城� 禎 5-20 執��� 釣幽閃裝� 炡遵� � 鴨贓, 茁�� 裔 惟逸淆鎭尊� 蓴� 鎭 蓮 30-40 麟腸�.�

+10.000 e-mail 雪釣櫛�
+穽謫調壹� 秧� 岫增尊� 翟調灑叱� e-mail 雪釣櫛�, 禎崖翟狀 全尿陝壯� � 穽抑或蔡彦 紳設�.

Chapter#5 벪蔭典嶢� 調灑執, 堯� 魏� 壯矮鏑檍 戱輒攸外狀 尿禎蟻吾循潗 訟午嚴 茁增諺� 6�6.�

+80.000 e-mail 雪釣櫛� (!)
+穽謫調壹� 秧� 設桎茵震特仲迹 調葺魂孺 謫尊日謫� 惟泣特增循 釣幽閃裝� 炡遵� � 瞬跡孼��麟, 禎崖翟狀 全尿陝壯� � 穽抑或蔡彦 紳設�.

Chapter#6 벿綎夭了寮暢� 쭌� 惟逸淆鎭�, 禎述胞諺 憶� 穽迪譽賊嶢言茴前潗 壯 50%, 堯� 魏� 裔增設嶢� Pentium 166 調灑診潗 魏� Pentium II-300.�

+100.000 e-mail 雪釣櫛� (!)
+珞躁儼壯� 妬增� 穽謫調壹� 秧� 設桎茵震特仲迹 調葺魂孺 謫尊日謫� 惟泣特增循 釣幽閃裝� 炡遵� � 瞬跡孼��麟, 禎崖翟狀 全尿陝壯� � 4-迹 紳設�.

國읓훙� 當읾蘆� � 國光隙儆� 6�6
 
 


屢鏃妖�:

璥增儼 � 漏緘檣荻 흇典� 잼焉焌庄尊淳�, 前狀循鎭蟻 訟午嚴 茁增諺�;

釣輒釣� � 綵葉帙凹 6�6, 剪 惟桎尊莘 찰 禎懿婆泣 憙� 炡贈溢 � � 惟桎尊莘 찰 哀飮裝 裔魏裔潗 Chapter;

幽猥粧 � 軸��妖 e-mail, 壯 惟桎終� 찰 剪穽設��奄� 炡贈溢;

釣輒調� � 綵葉帙凹 6�6, 惟桎終� 裔魏裔� � 쭌� Chapter.

間� 調灑診奄 訟午嚴 茁增諺� 6�6
 
 


쾰� 桎莘, 破翟� 裔調蓀執循潗 張 桎蟻惟 � 穽�荏� 穽賊剡 (�.�. 惟宸� 찰 焌麟 穽賊齧鎭 Chapter#1 竣迪 釣輒調乙�), 狀 � � 穽賊剡 竣迪� 釣輒調依� (�.�. 惟宸� 쭌鋪 釣輒調薏 穽外賊�� 쭌� 禎有檉鎭音� 壯 Chapter#2 - Chapter#6) 岫乙 調嗚褻剪陝� 衆抑策咸� 茁增諺� � � 釣幽閃狀� 炡贈靭 櫛鴨阻嶢�� 診魏� 診頌擾� (�.�. 訟午嚴-診頌擾�):

Chapter#1...............釣輒釣� �1
Chapter#2...............釣輒釣� �2
Chapter#3...............釣輒釣� �3
Chapter#4...............釣輒釣� �4
Chapter#5...............釣輒釣� �5
Chapter#6...............釣輒釣� �6

昆穽剪外 魏輦謫� Chapter`� 增��� 釣侑了嶢� 調午紅 誼鴨�, �.�. 찰 修鴨鎭 禎有檉潗 Chapter#1 � 釣輒釣調 �1, Chapter#2 � 釣輒釣調 �2, Chapter#3 � 釣輒釣調 �3, Chapter#4 � 釣輒釣調 �4, Chapter#5 � 釣輒釣調 �5, Chapter#6 � 釣輒釣調 �6. 행釣燼增鳥尊循馴尿� 찰 禎懿婆鎭 釣幽閃狀� 炡贈溢 � 訟午嚴-診頌擾彦, 了靭張牆迹 衆抑策陷� 翟調吾�:

Chapter#1...............찰
Chapter#2...............釣輒釣� �1
Chapter#3...............釣輒釣� �2
Chapter#4...............釣輒釣� �3
Chapter#5...............釣輒釣� �4
Chapter#6...............釣輒釣� �5

� 壯杷奄� 調葺魂城� 釣幽閃狀� 炡贈溢 � 診惟� 訟午嚴-診頌擾彦. �.�. 쭌鋪 釣輒調薏 修涯� 禎有檉潗 � 쭌� Chapter#1, � 釣輒釣調 �1 � Chapter#2, � 釣輒釣調 �2 � Chapter#3, � 釣輒釣調 �3 � Chapter#4, � 釣輒釣調 �4 � Chapter#5, � 釣輒釣調 �5 � Chapter#6. 쭌鋪 釣輒調薏 �1 (鎭, 攸� 有��� � 쭌� Chapter#1) 穽� 釣燼增調打� 禎懿妬� 釣幽閃狀� 炡贈溢 � 陝贍謫料狀 穽蘖鎖暹荻陝狀� 訟午嚴-診頌擾彦:

Chapter#1...............釣輒調� �1
Chapter#2...............찰
Chapter#3...............釣輒釣� �1
Chapter#4...............釣輒釣� �2
Chapter#5...............釣輒釣� �3
Chapter#6...............釣輒釣� �4

� 壯杷寀 調葺魂城� 釣幽閃狀� 炡贈溢 � 診惟� 訟午嚴-診頌擾彦. �.�. 撓 釣輒調薏 �1 (쭌鋪 釣輒調薏 �2) 修涯� 禎有檉潗 Chapter#1 � 杖� (쭌鋪� 釣輒調依� �1), Chapter#2 � � 쭌�, Chapter#3 � � 釣輒釣調 �1, Chapter#4 � � 釣輒釣調 �2, Chapter#5 � � 釣輒釣調 �3, Chapter#6 � � 釣輒釣調 �4. � �.�...

�.�. 診孺� 脣� 翟調吾� 쭌鋪 釣輒調薏, 穽外音魏� 遵悚 幽猥粧荻 壯 Chapter#1 修涯� 賊狀荀諺孼狀 穽外音魏潗 쭌� 幽猥粧荻 壯 Chapter#2 - Chapter#6. 較只菴 衆抑暢�, 破� 穽�溢� 裔菴特� 魏輦謫� 綵葉帙凹� 訟午嚴 茁增諺� 6�6 �瞬�奄�� 穽外音特杖� 禎有檉鎭音� 壯 Chapter#1 � 釣輒調依� �1.

屢渟綜 菴循煜� 穽前桎 穽凹妖諺, 仲鏑獪� 鴨張� 찰 裔調灑診奄� 嚴泣 魏輦渾 綵葉帙凹 穽外音特� 禎 10 釣輒調依� �1:

찰...........................10 � $6 = $60
쭌鋪 釣輒調薏 �1...10 X 10 X $6 = $600
쭌鋪 釣輒調薏 �2...10 X 10 X 10 X $6 = $6.000
쭌鋪 釣輒調薏 �3...10 X 10 X 10 X 10 X $6 = $60.000
쭌鋪 釣輒調薏 �4...10 X 10 X 10 X 10 X 10 X $6 = $600.000
쭌鋪 釣輒調薏 �5...10 X 10 X 10 X 10 X 10 X 10 X $6 = $6.000.0000

�.�. 蓴憶� 찰 裔調灑診奄� $6.666.660!

朧替� 張 茵乙� � 脣傲跡狀 禎憙佃� � 쭌� 脣午凹腸� 櫛日孼��. - 쯩凹杖鎭 � 調葺特執 � � 憎潗 調灑執 茁增諺�, 穽前婆診煜� 蓴� 焌麟 � 찰 禎懿婆鎭 桎� 蓮 釣奧蟻診�!

행陷診 剪 翟茵壯
 
 


쾰� 桎莘, 破翟� 尿幽�婆潗 翟終循諺前潗 茁增諺� 岫乙 調嗚褻剪陝� 衆抑策咸� 裔陷診:

� 釣幽閃狀� 炡贈溢 禎靭咸奄�� 診魏� 訟午嚴-診頌擾�:

Chapter#1...............釣燼增�. 狀靭� 釣輒釣調 �1
Chapter#2...............釣燼增�. 狀靭� 釣輒釣調 �2
Chapter#3...............釣燼增�. 狀靭� 釣輒釣調 �3
Chapter#4...............釣燼增�. 狀靭� 釣輒釣調 �4
Chapter#5...............釣燼增�. 狀靭� 釣輒釣調 �5
Chapter#6...............釣燼增�. 狀靭� 釣輒釣調 �6

�.�. 幽猥粧 � 惟桎尊壬 穽曜依 憙� 釣幽閃狀� 炡贈溢 午齧� 桎蟻惟 釣燼增調打佺裝� 狀靭調 釣輒釣尊� � 惟桎終� 佺 哀飮孼 有炡潗 Chapter`�. 柑炡潗 蓴� Chapter`� � 杖� 壯穽�壬� � 菴牆渾 溢靭粧 佺 張 溢蓮� 診� 魏� 張 午齧� 撓 釣侑了嶢荻.

콧音� 佺 釣燼增鳥宗奄�� � 紳設狀� 惟粧典� 6�6 MLM Corporation � 禎懿妬奄:

1) C脣� 釣燼增調打佺裝� 狀靭�.

2) 잤釣焌 蓴嶪 釣輒釣尊�, � 惟桎終� 哀飮孼 有炡潗 Chapter#1 - Chapter#6.

3) 給幽閃狀� 炡贈溢 秧� 調葺魂孺 � 了靭張牆迹 訟午嚴-診頌擾彦 衆抑策緘莘 淳菴:

Chapter#1...............釣燼增�. 狀靭� 菴牆謫� 幽猥粧�
Chapter#2...............釣燼增�. 狀靭� 釣輒釣調 �1
Chapter#3...............釣燼增�. 狀靭� 釣輒釣調 �2
Chapter#4...............釣燼增�. 狀靭� 釣輒釣調 �3
Chapter#5...............釣燼增�. 狀靭� 釣輒釣調 �4
Chapter#6...............釣燼增�. 狀靭� 釣輒釣調 �5

禎有檉奄 蓴� Chapter`� � 壯婆壯奄 調葺魂有.

쥰說賊燮� 憙迹 裔陷鎭, 佺 穽前桎 張 溢蓮� 翟典循潗 墮錠 � 前診淳潗 竣迪� 釣輒釣尊� 悚� 穽料嶢筬緘栯� 夭 穽矮魂�. 쭤縊 墮錠 溢蓮� 翟典循潗�� 桎蟻惟 桎宸�, 惟宸� 撓 釣侑了嶢荻 張 修鴨� � 訟午嚴-診頌擾�. 燐� 脣傲跡狀, 桎蟻惟 嚴泣 佺 裔靭杖� 釣侑了嶢� 蓴嶪 ��震 釣輒釣尊� 竣迪麟 釣侑了嶢閃�. 痢莘 佺 逡言城� 穽前桎 張 溢蓮�, �.�. 秧� 憙謫� 諺� 穽巍奄�� 裔釣燼增鳥尊循潗�� 余� ��潗 調�, 桎宸� 魏� 釣燼增鳥尊循潗�� 溢悅� 桎蟻惟 賊妖 調�.
 

쬠 촘鷺쬠 痼戮農 좨핏턺 � 6�6?!
훽읨, 國훼錄舅턍!
 
 


쯩夭陝猥! � 竣�預 � 謫尊日忽 穽嶢適佃 釣輒調依� � 1/IX-2000 釣燼增調打� 增贍� 町城狀� � 增迪� 5 哀應燮荻 懶�.

稜� 쩜� 考适來컹勍 錡탸잃�:

�) 행釣燼增鳥宗煜嚴� � 紳設狀� 惟粧典� 6�6 MLM Corporation:

1) 昆炡鋪鎭 壯 泣增� 修茵燼 (陝紳僥仲夭� 修侑閃�):

1) 쭌鋪 �.�.�.,
2) 淃破荻渾 雪釣� 秧� 全乙執,
3) 줘檣荻仲猥 釣侑了嶢� 秧� 全乙執 (張翟�裔鎭蟻狀),
4) 쭌� e-mail - 炡鋪鎭 調詣典婆脣 � � 菴蟻張橒諺 尿禎蟻奧煜� 憶� 桎蟻惟 秧� 竣�預 � 紳設狀� 惟粧典迹 6�6,
5) 昆軸��姮��� 杖蓮 訟午嚴-診頌擾� � 釣燼增調打佺狀-狀靭存佃 淳鴨,
6) 콧膣 剪穽設音杖� 炡贈茵.

2) 쯤跡嶢� � 張莘 $5 � 剪穽設獲� 禎 禎破� 裔魏午忽 設歪炡贈溢� 壯 雪釣� 紳設狀� 惟粧典� 6x6 MLM Corporation:

Igor Tichtchenkov, Laanemere 20-96, 13913 Tallinn, Estonia.

3) � 鎭特杖� 張鴨泣 쭌� 穽僥鴨� (壯 e-mail, 惟桎終� 찰 瘡暹贍� � 釣燼增調打佺狀� 切鏃�) 炡贈溢, 櫛鴨阻晟檍:

1) 쭌� 釣燼增調打佺裝� 狀靭�.
2) 잤釣焌 蓴嶪 釣輒釣尊�, � 惟桎終� 찰 哀飮裝 有炡潗 Chapter`�.
3) 給幽閃狀� 炡贈溢 � 了靭張牆迹 訟午嚴-診頌擾彦, 櫛鴨阻晟彦 쭌� 釣燼增調打佺裝� 狀靭�, 惟桎尊� 찰 修鴨鎭 調葺魂城�.
4) 袞翟軸怏荏� 秧� 壯妬乙 調灑執 妖增宗柚僚.

�) 蘭暹� 有炡鎭 Chapter`� � 櫛剪橓秩軫僚 � 訟午嚴-診頌擾彦:

취設� �
給�. � 給輒釣調
Chapter#1
6x6-000009-z-011
Chapter#2
6x6-000002-z-679
Chapter#3
6x6-000000-z-001
Chapter#4
Master 6x6
Chapter#5
Master 6x6
Chapter#6
Master 6x6

國훠테익훅! 퇸泣 � 訟午嚴-診頌擾� 張仲鏑獪� 堯� 菴蓮 蓴� 釣燼疾惺姚牆酷 狀靭調 - Master 6x6, 桎 杖魏惟� 廛矮孺 � 憙佃 張�, 穽前桎 쭌� 禎橓俉� �.�. 穽尿赤怏杖馴尿� 찰 修鴨鎭 � 焌溢� 壯妬音 訟午嚴 茁增諺� - �.�. 쭌鋪 胞章� 壯 埰渟� 茵揄夭贍茴�.

間� 桎蟻惟 찰 憙� 逡言齧鎭 汁暹� 壯婆壯煜� 調葺魂有. 淃崖翟張� 翟 憙佃 찰 滄壯奄� 張禎汁抑增橓牆� 了 Chapter`荻. 찔憶� 쭌� 蓮乙鎭蟻狀 穽外音販 適鏑� 30 釣輒調依� �1 - �.�. 穽賊城� 30 Chapter#1. 蠣�� 特� 灑蟻袍 찰 撓 穽外音特鎭, 鎭� 灑蟻袍 穽矮魂� 禎懿婆鎭.

淃增燮纖鎭贈 調葺魂城� 張 靭張� 3.000 釣幽閃裝� 炡遵� � 鴨贓 (櫛 楫業歪蟻裝麟 穽謫調壹閃�, 惟桎終� 찰 禎懿婆鎭 筍嚴鎭 � Chapter`閃�, 張 櫛增設嶢 疾昶� 調葺魂城� � 禎 20.000 炡遵� � 鴨贓). 퇸泣 溢蓮鎭 灑蟻袍, 調葺魂纖鎭 灑蟻袍 (禎崖翟張� � Chapter#5).

� 菴蟻張橒撓 胞侁� 찰 滄壯奄� � Chapter`性. 쭤贈 穽專嚴� 調增�燼循奄�� 穽夭儼狀 壯 4 靭��稱 櫛 厓� 壯妬乙 訟午嚴�. 퇸泣 찰 修鴨鎭 特叱� 衆抑荻城� 蓴諺 穽設堯閃, 桎 純� 蓴�孺� 櫛日孼僥 修鴨鎭 翟乙菴鎭音� 張仲鏑獪撓 櫛鎭� 執��� 哀應燮荻! 悸 午齧�, 破� 憙� 修鴨� 夭孼狀 診�, � 壯� 前診奄�� 桎蟻惟 禎醴調淳潗 쭌�!

� 鎭渟綜 裔 鴨依!

펙乙諺 쭌� 謫尊日紅 埰渟軸�!!!

 
 

Copyright � 2001 6x6 MLM Corporation. All rights reserved.
From noreply@sourceforge.net Tue Feb 12 20:13:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Feb 2002 12:13:36 -0800 Subject: [Patches] [ python-Patches-512256 ] ceval micro optimizations Message-ID: Patches item #512256, was opened at 2002-02-02 16:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512256&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None >Priority: 6 Submitted By: Neil Schemenauer (nascheme) Assigned to: Tim Peters (tim_one) Summary: ceval micro optimizations Initial Comment: These are good for a 5% speed increase according to pystone and pybench. Changes: - move common instructions to top of switch stmt - simplify SET_LINENO block by calling call_trace instead of inlining it - skip "things_to_do" block for a few ops that don't actually do any work (like SET_LINENO and POP_TOP). - tweak if statements so that GCC generates better code ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-02-12 12:13 Message: Logged In: YES user_id=31435 Boosted priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512256&group_id=5470 From noreply@sourceforge.net Tue Feb 12 23:44:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Feb 2002 15:44:53 -0800 Subject: [Patches] [ python-Patches-516715 ] HTTPConnection.send() fails large reques Message-ID: Patches item #516715, was opened at 2002-02-12 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection.send() fails large reques Initial Comment: The present implementation of HTTPConnection.send() in httplib.py does not handle the case of less than the number of requested bytes being sent via socket.send(). Indeed, this condition occurs for fairly large requests. In my environment, socket.send() will max out at transferring 33011 bytes. The routine needs to check how many bytes where actually transferred and make subsequent socket.send() calls until all of the data makes it through. In the patch I've supplied, I send slices of a particular maximum size in each iteration, rather than attempting to send the entire remainder of data, for efficiency (it proved expensive to have big slices being created per call, which would happen otherwise). I noticed that in the description of recent patches it appears that an attempt has made to address this, but the version of httplib.py that supposedly provides a fix appears to make invalid references to socket.py. If what's there is actually suitable, please do disregard. The submitted diff is against version 1.34.2.1 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 From noreply@sourceforge.net Wed Feb 13 01:20:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Feb 2002 17:20:11 -0800 Subject: [Patches] [ python-Patches-515023 ] thr.join() signatures are different Message-ID: Patches item #515023, was opened at 2002-02-08 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515023&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: thr.join() signatures are different Initial Comment: the _DummyThread.join() signature doesn't match it's base class. this patch adds a timeout parameter with default value to match Thread. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:20 Message: Logged In: YES user_id=21627 This patch looks fine, please apply. It should also go into 2.2.1 (being a bug fix); either commit it their yourself, or indicate in your checkin message that it is a bugfix candidate. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515023&group_id=5470 From noreply@sourceforge.net Wed Feb 13 01:21:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Feb 2002 17:21:22 -0800 Subject: [Patches] [ python-Patches-515041 ] path in site doc refers to 1.5 Message-ID: Patches item #515041, was opened at 2002-02-08 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515041&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: path in site doc refers to 1.5 Initial Comment: doc for the site module refers to 1.5 in paths, this patch updates the paths to include 2.2 ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:21 Message: Logged In: YES user_id=21627 Please apply this to the 2.2 maintainance branch; for the trunk, please apply an equivalent 2.3 patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515041&group_id=5470 From noreply@sourceforge.net Wed Feb 13 01:25:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Feb 2002 17:25:39 -0800 Subject: [Patches] [ python-Patches-513329 ] build, install in HP-UX10.20 Message-ID: Patches item #513329, was opened at 2002-02-05 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513329&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Claudio Scafuri (scafuri) Assigned to: Nobody/Anonymous (nobody) Summary: build, install in HP-UX10.20 Initial Comment: a) python must be linked with c++ because at least one file is compiled with c++. b) in hpux "install -d" does not create a directory. Use "mkdir instead. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:25 Message: Logged In: YES user_id=21627 There is already code in configure[.in] that tests whether using c++ to link is needed (it isn't needed on all systems). Please report why this test fails on HP-UX, and try providing a patch that corrects the test. The relevant code is after the comment # If CXX is set, and if it is needed to link a main function that was # compiled with CXX, LINKCC is CXX instead. Also, please contribute changes as unified or context diffs; see the Python SourceForge usage guidelines for details. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513329&group_id=5470 From noreply@sourceforge.net Wed Feb 13 01:28:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Feb 2002 17:28:00 -0800 Subject: [Patches] [ python-Patches-513235 ] prevent readline filename completion Message-ID: Patches item #513235, was opened at 2002-02-05 02:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513235&group_id=5470 Category: Modules Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) Summary: prevent readline filename completion Initial Comment: This patch is from Simon Budig, and despite him being too lazy to get an sf account, I think it should probably go in. --- readline.c.orig Sat Feb 2 21:44:09 2002 +++ readline.c Sat Feb 2 22:01:16 2002 @@ -346,6 +346,9 @@ lock released! */ save_tstate = PyThreadState_Swap(NULL); PyEval_RestoreThread(tstate); + /* Don't use the default filename completion if we + have a custom completion function... */ + rl_attempted_completion_over = 1; r = PyObject_CallFunction(completer, "si", text, state); if (r == NULL) goto error; afaict, rl_attempted_completion_over has been present in readline since 2.0. objections? ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:28 Message: Logged In: YES user_id=21627 The patch looks fine to me, please apply it. If you want this in 2.2.1 also, I'd rather have definitive success reports on using this patch on very old readline installations. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513235&group_id=5470 From noreply@sourceforge.net Wed Feb 13 01:30:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Feb 2002 17:30:13 -0800 Subject: [Patches] [ python-Patches-512466 ] Script to move faqwiz entries. Message-ID: Patches item #512466, was opened at 2002-02-03 12:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512466&group_id=5470 Category: Demos and tools Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Christian Reis (kiko_async) Assigned to: Nobody/Anonymous (nobody) Summary: Script to move faqwiz entries. Initial Comment: Moves entries from one section (number actually) to another. Doesn't do anything smart like renumber questions, but at least it doesn't clobber them. Usage: blackjesus:~> ./move-faqwiz.sh 2\.1 3\.2 Moving FAQ question 02.001 to 03.002 ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:30 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512466&group_id=5470 From noreply@sourceforge.net Wed Feb 13 01:31:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Feb 2002 17:31:06 -0800 Subject: [Patches] [ python-Patches-511193 ] Implement killpg in posixmodule Message-ID: Patches item #511193, was opened at 2002-01-31 05:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511193&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Implement killpg in posixmodule Initial Comment: killpg is currently not accessible from python standard library. Since process group handling functions are accessible (setsid, setpgrp, getpgrp, setpgid), this one should probably be there as well. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:31 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511193&group_id=5470 From noreply@sourceforge.net Wed Feb 13 02:23:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Feb 2002 18:23:02 -0800 Subject: [Patches] [ python-Patches-512466 ] Script to move faqwiz entries. Message-ID: Patches item #512466, was opened at 2002-02-03 12:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512466&group_id=5470 Category: Demos and tools Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Christian Reis (kiko_async) Assigned to: Nobody/Anonymous (nobody) Summary: Script to move faqwiz entries. Initial Comment: Moves entries from one section (number actually) to another. Doesn't do anything smart like renumber questions, but at least it doesn't clobber them. Usage: blackjesus:~> ./move-faqwiz.sh 2\.1 3\.2 Moving FAQ question 02.001 to 03.002 ---------------------------------------------------------------------- >Comment By: Christian Reis (kiko_async) Date: 2002-02-12 18:23 Message: Logged In: YES user_id=222305 Added file (duh). And of course you can: use Bugzilla :-) it's free software. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:30 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512466&group_id=5470 From noreply@sourceforge.net Wed Feb 13 03:16:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 12 Feb 2002 19:16:23 -0800 Subject: [Patches] [ python-Patches-511193 ] Implement killpg in posixmodule Message-ID: Patches item #511193, was opened at 2002-01-31 05:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511193&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Implement killpg in posixmodule Initial Comment: killpg is currently not accessible from python standard library. Since process group handling functions are accessible (setsid, setpgrp, getpgrp, setpgid), this one should probably be there as well. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-02-12 19:16 Message: Logged In: YES user_id=7887 Oops... my fault, sorry! Now the file is there (I hope.. :-). ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:31 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511193&group_id=5470 From noreply@sourceforge.net Wed Feb 13 12:00:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Feb 2002 04:00:24 -0800 Subject: [Patches] [ python-Patches-513235 ] prevent readline filename completion Message-ID: Patches item #513235, was opened at 2002-02-05 02:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513235&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: prevent readline filename completion Initial Comment: This patch is from Simon Budig, and despite him being too lazy to get an sf account, I think it should probably go in. --- readline.c.orig Sat Feb 2 21:44:09 2002 +++ readline.c Sat Feb 2 22:01:16 2002 @@ -346,6 +346,9 @@ lock released! */ save_tstate = PyThreadState_Swap(NULL); PyEval_RestoreThread(tstate); + /* Don't use the default filename completion if we + have a custom completion function... */ + rl_attempted_completion_over = 1; r = PyObject_CallFunction(completer, "si", text, state); if (r == NULL) goto error; afaict, rl_attempted_completion_over has been present in readline since 2.0. objections? ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-02-13 04:00 Message: Logged In: YES user_id=6656 OK, checked in as revision 2.43 of Modules/readline.c. I wasn't proposing to check this into 2.2.1. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:28 Message: Logged In: YES user_id=21627 The patch looks fine to me, please apply it. If you want this in 2.2.1 also, I'd rather have definitive success reports on using this patch on very old readline installations. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513235&group_id=5470 From Promo3000"

     Spettabile Azienda,

Vi presentiamo il software professionale per l'e-commerce:

   i p e r 1 � la soluzione migliore per aprire un negozio su internet, � un programma completo e potente ed allo stesso tempo semplice e facile nell'utilizzo e nella navigazione.

  • Perfetto sia per la vendita al dettaglio e sia per la vendita all'ingrosso: 6 listini prezzi, con la possibilità di abbinare ad ogni cliente il relativo listino;
    si può scegliere se far visionare il negozio a tutti o solo ai clienti registrati ed attivati, per esempio solo ai rivenditori, previo riconoscimento tramite password;
    si può far visionare i prodotti a tutti senza i relativi prezzi, e far vedere i prezzi con la possibilità di acquisto solo ai rivenditori.
  • � completo:
    carrello della spesa;
    stato degli ordini, il cliente può seguire in linea lo stato di avanzamento della consegna del prodotto;
    illimitato numero di prodotti;
    illimitato numero di varianti e di opzioni per ogni prodotto;
    illimitato numero di categorie e livelli di sottocategorie;
    calcolo delle spese di trasporto tenendo conto del corriere, della distanza, del peso e dell'importo della spesa;
    qualsiasi tipo di pagamento: sono compresi i moduli per il collegamento, per far pagare i clienti con la carta di credito, con i server sicuri di oltre 70 banche italiane e con le più importanti banche internazionali, è stato previsto anche il pagamento con forma mista: acconto con carta di credito o con le nuove carte prepagate e il resto contrassegno.
  • � immediato: avviene tutto in tempo reale, appena inserito un nuovo prodotto � subito in linea, il negozio è gestibile, tramite password, da qualsiasi computer collegato ad internet, ovunque Vi troviate.
  • � ideale:
    per chi vuole realizzare personalmente il proprio negozio senza dover scrivere nessuna riga di codice.
  • � indispensabile:
    per gli studi grafici che costruiscono negozi per i loro clienti, con questo programma si possono occupare solo della parte grafica senza addentrarsi nella programmazione, il programma non ha .dll o .exe che riscrivono il tutto ad ogni inserimento. � costruito in linguaggio HTML ed in ASP ed il tutto � collegato ad un database in formato Microsoft Access, la parte amministrativa pu� restare uguale per tutti i negozi, per la parte che vede il cliente finale vengono fornite tutte le informazioni necessarie per adattare il tutto a qualsiasi grafica.
  • � multilingua:
    � pronto per creare negozi in italiano, inglese, francese, tedesco e spagnolo.
  • Con una sola copia del programma si può creare un intero CENTRO COMMERCIALE, si possono creare un numero illimitato di negozi (sotto un unico dominio), ed ogni esercente di ogni negozio può amministrare completamente il propro negozio.
  • È economico, ci sono 3 versioni: Light 100  Euro, Completa per la vendita al dettaglio 200  Euro e 300  Euro la versione PRO per il commercio al dettaglio ed all'ingrosso.
  • Eccezionali soluzioni per i rivenditori e gli studi grafici.
  • È gia usato con soddisfazione da centinaia di aziende.

Distinti Saluti

Promo3000
 
 
From noreply@sourceforge.net Wed Feb 13 12:34:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Feb 2002 04:34:46 -0800 Subject: [Patches] [ python-Patches-435381 ] Distutils patches for OS/2+EMX support Message-ID: Patches item #435381, was opened at 2001-06-22 01:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Closed Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: M.-A. Lemburg (lemburg) Summary: Distutils patches for OS/2+EMX support Initial Comment: The attached patch file is against the code released with Python 2.1. The changes are included in the binary installation package of the OS/2+EMX port of Python 2.1 I released on June 17, 2001. With these changes, I have successfully built and installed the Numeric 20.0.0 extention, and created a bdist_dumb distribution package of it. The installed extention tests successfully using the supplied test routines. Particular items of note:- - OS/2 limits DLLs to 8.3 filenames :-( :-( - ld is not used to link, instead gcc is used with the -Zomf option which invokes the LINK386 linker native to OS/2 - I haven't made any attempt to merge cloned code back into the parent code where it would make sense, which I think is in a few places. Feedback appreciated. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-02-13 04:34 Message: Logged In: YES user_id=250749 As I responded to Marc-Andre privately, I do intend to maintain the OS/2 port. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-31 10:56 Message: Logged In: YES user_id=38388 Checked in. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-31 04:32 Message: Logged In: YES user_id=38388 The last patch looks good to me. I don't have OS/2 installed anywhere, so can't test the patch, but the approach looks reasonable. Andrew, will you be able to maintain this port to OS/2 ? About the refactoring of the compiler classes: I think we need to go a little further on this one, since it should be possible to override the compiler classes in setup.py. Currently this is only possible by hacking the raw classes -- that's not a good design. Let's discuss these bits on the mailing list. If there are no objections and the patch applies cleanly to current CVS, I'll check it in later today. Thanks, Andrew ! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-31 02:41 Message: Logged In: YES user_id=6656 Are you going to get to this soon, Marc? Assign it to me if you want rid of it :) ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-01-26 21:33 Message: Logged In: YES user_id=250749 The updated patch against post-2.2 CVS has had some minor cleanups, compared to the earlier versions. emxccompiler is still standalone, on the basis that it works and is independent of any changes that might happen in the Cygwin/MinGW support, given that EMX is not changing much (and not likely to). ---------------------------------------------------------------------- Comment By: Rene Liebscher (rliebscher) Date: 2001-08-29 01:39 Message: Logged In: YES user_id=28463 Would it be possible to subclass cygwinccomplier (as mingwcompiler does?) Or maybe create a better class structure like this GCCCompiler / \ / \ CygwinCCompiler EMXCCompiler / / MinGWCCompiler GCCCompiler would never be used directly by anyone, it only collects all common code. The other class would only configure the GCCCompiler class in their __init__ methods. (And maybe override some [small] methods if really necessary.) ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2001-08-12 04:01 Message: Logged In: YES user_id=250749 The only real change in this updated patch is the compiler optimisation switches in emxccompiler.py. No attempted merging of changes. Suggestions/advice in this regard sought. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:38 Message: Logged In: YES user_id=3066 The third item in the list of issues at the end of the initial comment indicates that the patch isn't ready for inclusion. Assigning to Greg Ward for review. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470 From noreply@sourceforge.net Wed Feb 13 12:39:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Feb 2002 04:39:59 -0800 Subject: [Patches] [ python-Patches-435381 ] Distutils patches for OS/2+EMX support Message-ID: Patches item #435381, was opened at 2001-06-22 01:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: M.-A. Lemburg (lemburg) Summary: Distutils patches for OS/2+EMX support Initial Comment: The attached patch file is against the code released with Python 2.1. The changes are included in the binary installation package of the OS/2+EMX port of Python 2.1 I released on June 17, 2001. With these changes, I have successfully built and installed the Numeric 20.0.0 extention, and created a bdist_dumb distribution package of it. The installed extention tests successfully using the supplied test routines. Particular items of note:- - OS/2 limits DLLs to 8.3 filenames :-( :-( - ld is not used to link, instead gcc is used with the -Zomf option which invokes the LINK386 linker native to OS/2 - I haven't made any attempt to merge cloned code back into the parent code where it would make sense, which I think is in a few places. Feedback appreciated. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-02-13 04:34 Message: Logged In: YES user_id=250749 As I responded to Marc-Andre privately, I do intend to maintain the OS/2 port. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-31 10:56 Message: Logged In: YES user_id=38388 Checked in. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-01-31 04:32 Message: Logged In: YES user_id=38388 The last patch looks good to me. I don't have OS/2 installed anywhere, so can't test the patch, but the approach looks reasonable. Andrew, will you be able to maintain this port to OS/2 ? About the refactoring of the compiler classes: I think we need to go a little further on this one, since it should be possible to override the compiler classes in setup.py. Currently this is only possible by hacking the raw classes -- that's not a good design. Let's discuss these bits on the mailing list. If there are no objections and the patch applies cleanly to current CVS, I'll check it in later today. Thanks, Andrew ! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-01-31 02:41 Message: Logged In: YES user_id=6656 Are you going to get to this soon, Marc? Assign it to me if you want rid of it :) ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-01-26 21:33 Message: Logged In: YES user_id=250749 The updated patch against post-2.2 CVS has had some minor cleanups, compared to the earlier versions. emxccompiler is still standalone, on the basis that it works and is independent of any changes that might happen in the Cygwin/MinGW support, given that EMX is not changing much (and not likely to). ---------------------------------------------------------------------- Comment By: Rene Liebscher (rliebscher) Date: 2001-08-29 01:39 Message: Logged In: YES user_id=28463 Would it be possible to subclass cygwinccomplier (as mingwcompiler does?) Or maybe create a better class structure like this GCCCompiler / \ / \ CygwinCCompiler EMXCCompiler / / MinGWCCompiler GCCCompiler would never be used directly by anyone, it only collects all common code. The other class would only configure the GCCCompiler class in their __init__ methods. (And maybe override some [small] methods if really necessary.) ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2001-08-12 04:01 Message: Logged In: YES user_id=250749 The only real change in this updated patch is the compiler optimisation switches in emxccompiler.py. No attempted merging of changes. Suggestions/advice in this regard sought. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-07-03 21:38 Message: Logged In: YES user_id=3066 The third item in the list of issues at the end of the initial comment indicates that the patch isn't ready for inclusion. Assigning to Greg Ward for review. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=435381&group_id=5470 From noreply@sourceforge.net Wed Feb 13 12:40:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Feb 2002 04:40:13 -0800 Subject: [Patches] [ python-Patches-514490 ] Better pager selection for OS/2 Message-ID: Patches item #514490, was opened at 2002-02-07 12:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514490&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: Better pager selection for OS/2 Initial Comment: With the current implementation (rev. 1.56) of pydoc.py the first call of the help command gives (when the pager environmment variable is not set): Python 2.2 (#0, Dec 24 2001, 18:42:48) [EMX GCC 2.8.1] on os2emx Type "help", "copyright", "credits" or "license" for more information. >>> help(help) SYS0003: The system cannot find the path specified. Help on instance of _Helper: Type help() for interactive help, or help(object) for help about object. >>> After the error message one has to press Ctrl-C. Further invocations of help work, though. The attached patch selects 'more <' as the default pager when no PAGER env. variable is set, like on Windows. I use os.platform.startswith to deal with a possible future port with os.platform == 'os2vac'. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-02-13 04:40 Message: Logged In: YES user_id=250749 The patch looks Ok to me. I plan to apply it after I have all the EMX port patches into CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=514490&group_id=5470 From noreply@sourceforge.net Wed Feb 13 23:18:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Feb 2002 15:18:03 -0800 Subject: [Patches] [ python-Patches-517245 ] fix for mpzmodule.c Message-ID: Patches item #517245, was opened at 2002-02-13 15:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517245&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: fix for mpzmodule.c Initial Comment: This a one line to get mpzmodule compiled with GMP version >= 2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517245&group_id=5470 From noreply@sourceforge.net Wed Feb 13 23:18:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Feb 2002 15:18:43 -0800 Subject: [Patches] [ python-Patches-517245 ] fix for mpzmodule.c Message-ID: Patches item #517245, was opened at 2002-02-13 15:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517245&group_id=5470 >Category: Modules >Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: fix for mpzmodule.c Initial Comment: This a one line to get mpzmodule compiled with GMP version >= 2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517245&group_id=5470 From noreply@sourceforge.net Wed Feb 13 23:48:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 13 Feb 2002 15:48:28 -0800 Subject: [Patches] [ python-Patches-517256 ] poor performance in xmlrpc response Message-ID: Patches item #517256, was opened at 2002-02-13 15:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517256&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: poor performance in xmlrpc response Initial Comment: xmlrpclib.Transport.parse_response() (called from xmlrpclib.Transport.request()) is exhibiting poor performance - approx. 10x slower than expected. I investigated based on using a simple app that sent a msg to a server, where all the server did was return the message back to the caller. From profiling, it became clear that the return trip was taken 10x the time consumed by the client->server trip, and that the time was spent getting things across the wire. parse_response() reads from a file object created via socket.makefile(), and as a result exhibits performance that is about an order of magnitude worse than what it would be if socket.recv() were used on the socket. The patch provided uses socket.recv() when possible, to improve performance. The patch provided is against revision 1.15. Its use provides performance for the return trip that is more or less equivalent to that of the forward trip. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517256&group_id=5470 From iteducation@frontier.co.kr Thu Feb 14 08:25:51 2002 From: iteducation@frontier.co.kr (iteducation@frontier.co.kr) Date: Thu, 14 Feb 2002 17:25:51 +0900 Subject: [Patches] =?euc-kr?B?KluxpCCw7V0qILOqtMIgwd+xub+hvK0gucy3obimIMHYuvHH0bTZLiA=?= Message-ID: <6319592.1013675149465.JavaMail.root@localhost.localdomain> ICAKWyDBpjKx4iDB37G5IMf2wfYgwd+xub7uICYgSVQgtb+9wyCxs8CwsPrBpCC/rLz2u/0gvLG5 3yBdIAoKwd+xuSC/5LPnvLogwaS6ziDIxL/4wLi3ziDHwbfQxry+7r3DvbrF2yjB1im0wiDB37G5 IL3Jvue068fQsbO/zSDH1LKyIMHfsblJVMD8ua6woSCw+sGkwLsguPDB/cfVtM+02S4gCiAKu+fB +MDat+EssPy3w7Hiu+cgudcgwNq8vMfRIMDat+G0wiBodHRwOi8vd3d3LmZyb250aWVyLmNvLmty IMC7IML8sO3Hz73KvcO/wC4KIAoKuPDB/cDOv/ggCgk4MLjtICgyMLjtwMwgMbCzud3AuLfOveEg NLCzud0gvLHC+Lz4ILjwwf0pICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAq/rLz2 seKwoyAKCTaws7/5ICgyMDAys+IgMr/5IDI4wM+6zsXNIDIwMDKz4iA4v/kgMjnAz7HuwfYpIAoK v6y89rD6uPEgCgnB37G5vu4sIMHfsbm+7iDIuMitLCDB37G5x9AsIMTEx7vFzSCx4sPKLCBKYXZh IMfBt86x17ehudYgIAoKv6y89rO7v+sgCqGhCTIwMDIuIDIuIDI4fjIwMDIuIDguIDI5IC0gwd+x ub7uILHiw8p+wd+x3rD6waQgCgkJCQktIL3Hv+sgx6XB2MHfsbm+7iwgyLjIrSwgua65/SwgwNu5 riAKCQkJCS0gSFNLvcPH6Cjx6c/Q+dPl3uKp+MHNxePLKSAxwM8gNL3DsKMgKL/AwPwpIAoKCTIw MDIuIDIuIDI4fjIwMDIuIDUuIDMwIC0gwd+xucfQILCtwMcov6q75ywgwfa4riwgsObBpiwgua7I rSwguf23/CwgsbPAsLXuKSAKCQkJCS0gvcm+57Trx9CxsyDD38O1ILTrx9C7/bD6IEZyZWUgVGFs a2luZyAxwM8gMr3DsKMgKL/AyMQpIAoKCTIwMDIuIDUuIDMxfjIwMDIuIDguIDMwIC0gxMTHu8XN ILHiw8qxs8CwICjB37G5IMTEx7vFzSDIr7DmvPfB9ikgCgkJCQktIEpBVkEgUHJvZ3JhbW1pbmcg KFNDSlCw+sGkKSAxwM8gMr3DsKMgKL/AyMQpIAoKoaEJMjAwMi4gNyAtIMHfsbm5rsitIMCvwPvB 9iDFvbnmICg0udo1wM8pILnos7a/qcfgKLGzxessILz3vcTBprD4KSAKIAq/rLz2sd2+1yAKCTQy MLi4v/ggKL3EuvEsILHivPe757rxLCC68cfgseLHpSAsILrxwNosIL3Fw7ywy7vnLCCw+MfXwMy/ 67fhLCBIU0vAwL3Dt+EsIMHfsbm5rsitIMW9uea/qcfgILDmuvEgwM/DvCDG98fULgoJurvAzsDM ILrxwNosIL3Fw7ywy7vnvK24piDB2Lrxx9IgsOa/7L+htMIgMTW4uL/4wLsgwabHz7+pILXluLO0 z7TZLikgIAoKwabD4rytt/kgCgm/qbHHKLrxwNq537HevcMgx8q/5CksIMHWuc617rfPte66uyAz xessIL+psce758H4IDXA5SAKCr+svPa9xcO7ILnXIL+svPa68SCzs7rOIAoJMjAwMrPiIDG/+SAz wM+6zsXNIDIwMDKz4iAyv/kgMjDAz7HuwfYgPLDowcK5+MijIDogx9G6+8C6x+AgMTY5LTE0ODQy OS0xMy0xMDEgv7mx3cHWOiDHwbfQxry+7r3DvbrF26LfPiAKCrHixbggCgktILnmsPrIxCC9yb7n tOvH0LGzIMfQu/2w+iAywM4xwbYgtOvIrbimIMXrx9EgvcfB+sD7ILGzwLCx4si4IMGmsPgovcm+ 57Trx9Agw/i/obytIMPfw7XH0SC538C9wMwgwaTIrsfPsO0gx6XB2L7uuKYgsbi758fPtMIgvcm+ 57TrIMfQu/2w+iDH1LKyILvsvsbA1rTCIMf2wfYgwd+xub7uILnXIMHfsbkgua7IrbimIL3AtebH 0iC89iDA1rTCIMHBwLogseLIuMDUtM+02S4pCgktIMD8v/ggseK897vnv6G8rSC8973EICgyMDAx s+IxMb/5v6Egwdiw+MfRIMPWvcW9xCC+xsbExq7H/MC4t84gMsDOMb3HKSAKCS0gNrCzv/kgv6y8 9iDIxCC9yb7ntOvH0LGzv6G8rSC89rfhwfUgud+x3goJLSDB37G5ua7IrSDAr8D7wfYgxb255iA0 udo1wM8gv6nH4CDBprD4CgktIEhTSyC9w8foKPHpz9D50+Xe4qn4wc3F48spIMHfsbnH9sH2v6G8 rSDAwL3DCgktIEphdmEgx8G3zrHXt6Ugv6y89iDIxCBTdW4gQ2VydGlmaWVkIEphdmEgUHJvZ3Jh bW1lciDA2rDdvcPH6MDAvcOwobTJIAoJLSC/rLi7v6y9wyC/rMjeILD8sOi3ziC68cDaILnfsd4g te6/oSC4uMD8wLsgseLHz7HiIMCnx9ggyPG4wcDatMIgucy4riC9xcO7x8+/qSDB1r3DseIgudm2 +LTPtNkuIAoJLSC68cDaILnfsd4sIL3Fw7ywy7vnIMD9wvcgtOvH4MfULiAKCS0gsbPAsCC89rfh yMQgtOux4r73LMHfvNKx4r73ILnXILqlw7Ox4r73IMHfsbkgtOO058Dat84gw+u+9yDD38O1IAoK wda/5LGzwLC067vzIAoJLSDB37G5wK/H0MC7IMHYuvHHz7TCILz2x+i7/SAowd+xub7uIMPKurjA 2iCwobTJKSAKCS0gwd+xub7uIL7ux9C/rLz2IMjxuMEgtOvH0Lv9IAoJLSDB37G5sPy3wyC75773 sOjIucHfwM4gseK+98O8IMDTwfe/+CAgCgrAz8GksOjIuSAKCTIwMDKz4iAyv/kgMjDAzyDBorz2 uLawqCAov6y89rHdLCDB1rnOte63z7XuursgM8XrLCC53bjtx9TGxyC758H4NbjFLCC1tcDlKQoJ MjAwMrPiIDK/+SAyNcDPILrxwNq537HeLCC9xcO8sMu75yC/z7fhCgkyMDAys+IgMr/5IDI2wM8g w+KxuSC/ubrxvNLB/SAotOe75yDIuMDHvce/obytIL+psccvuvHA2iC15biyKQoJMjAwMrPiIDK/ +SAyOMDPIDEyOjMwIMDOw7WxucGmsPjH17+hvK0gwd+xuSC9yb7nwLi3ziDD4rG5ICjB37G5us+5 5sfXsPgpCgkJCTE0OjMwIL3Jvue068fQsbMgseK897vnIMDUvNIgudcgv8C4rr+jxdfAzLzHCgky MDAys+IgN7/5IMHfsbm5rsitIMCvwPvB9iDFvbnmICg0udo1wM8pCgkyMDAys+IgOL/5IEhTSyC9 w8foKPHpz9D50+Xe4qn4wc3F48spIMDAvcMKCTIwMDKz4iA4v/kyOMDPIMG+sK0gudcgvPa34b3E CgkyMDAys+IgOL/5MjnAzyDB37G5IL3Jvue/obytIMDOw7WxucGmsPjH18C4t84gsc2xuQogCrmu wMfDsyAJCgktIMfBt9DGvL7uvcO9usXbKMHWKSC8rb/vvcMgvK3DyrG4ILytw8q1vyAxNTU0LTEg KLDmwd+69LX5M8P+KSAKCQkowPzIrSA6IDAyLTM0NzMtMzkxMCwgxtG9uiA6IDAyLTM0NzMtMzk5 MCwgyKjG5MDMwfY6IHd3dy5mcm9udGllci5jby5rcikKCS0gwd+xub3Jvue068fQsbMgOiC9yb7n vcMgtOu1v7G4IL+sx9W3ziA1NMijIL3Jvue068fQsbMgv9y758OzCgkJKMD8yK0gOiAwMjQtODg1 MC02NjA3LCDG0b26IDogMDI0LTg4NTItMzM2MykgCgktIMHWw9Y6x8G30Ma8vu69w726xdsowdYp ICDB1rD8OiDB37G5IL3Jvue068fQsbMgICAKCS0gyMS/+Dogwd+xuSDBpLrOseKw/Ci/5LfJvLop ICjB1inEt8bbvbqz3SB3d3cuY2FtcHVzLmNvLmtyICAKIAogCg== From noreply@sourceforge.net Thu Feb 14 14:19:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Feb 2002 06:19:36 -0800 Subject: [Patches] [ python-Patches-517521 ] Optimization for PyObject_Get/SetAttr Message-ID: Patches item #517521, was opened at 2002-02-14 06:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517521&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Optimization for PyObject_Get/SetAttr Initial Comment: The attached patch is based on the assumption that the vast majority of calls to PyObject_GetAttr and PyObject_SetAttr use a PyString (rather than a PyUnicode) as the name parameter. Because these routines perform a PyUnicode_Check first, every call (with a PyString as name) requires a call to PyType_IsSubType. By reorganizing so that PyString_Check is called first, the call to PyType_IsSubType is avoided in the common case. The same reorganization is done for PyObject_GenericGet/SetAttr. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517521&group_id=5470 From noreply@sourceforge.net Thu Feb 14 22:52:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 14 Feb 2002 14:52:33 -0800 Subject: [Patches] [ python-Patches-454790 ] Have getopt handle optional short args Message-ID: Patches item #454790, was opened at 2001-08-23 17:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454790&group_id=5470 Category: None Group: Python 2.3 >Status: Deleted >Resolution: Rejected Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: Have getopt handle optional short args Initial Comment: The GNU getopt implementation allows optional args to short arguments - two colons mean an option takes an optional arg; if there is text in the current argv-element, it is returned in optarg, otherwise optarg is set to zero. The attached patch implements this behaviour. ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2002-02-14 14:52 Message: Logged In: YES user_id=6405 I'm going to kill it - the getopt sig kinda makes it redundant :) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-01-12 03:35 Message: Logged In: YES user_id=21627 If there is no further action on this patch, I recommend to close it by May 1, 2002. We really do need documentation and test cases, and it seems that nobody is providing these, so the patch must be rejected. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2001-09-19 10:55 Message: Logged In: YES user_id=21627 Adding this feature sounds like a good thing. A shallow review of the patch reveals two major problems with it, though: no patches to the documentation, no patches to test_getopt. Would you consider providing these missing pieces? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=454790&group_id=5470 From MR MICHEAL ADAM" ATTN: THE PRESIDENT/CEO Dear Sir / Madam, I am Dr. Mrs. Marian Abacha, wife to the late Nigerian Head of state, General Sani Abacha who died on the 8th of June 1998 while still on active service for our Country. I am contacting you with the hope that you will be of great assistance to me, I currently have within my reach the sum of 76MILLION U.S dollars cash which l intend to use for investment purposes outside Nigeria. This money came as a result of a payback contract deal between my husband and a Russian firm in our country's multi-billion dollar Ajaokuta steel plant. The Russian partners returned my husband's share being the above sum after his death. Presently, the new civilian Government has intensified their probe into my husband's financial resources, which has led to the freezing of all our accounts, local and foreign, the revoking of all our business licenses and the arrest of my First son. In view of this I acted very fast to withdraw this money from one of our finance houses before it was closed down. I have deposited the money in a security vault for safe keeping with the help of very loyal officials of my late husband. No record is known about this fund by the government because there is no documentation showing that we received such funds. Due to the current situation in the country and government attitude to my financial affairs, I cannot make use of this money within. Bearing in mind that you may assist me, 20% of the total amount will be paid to you for your assistance, while 5% will be set aside for expenses incurred by the parties involved and this will be paid before sharing. Half of my75% will be paid in to my account on your instruction once the money hits your account, while the other half will be invested by your humble self in any viable business venture you deem fit, with you as manager of the invested funds. Remunerations, during the investment period will be on a 50/50 basis. Your URGENT response is needed. All correspondence must be through my lawyer,fax:234-1-4709814. Attentioned to my attorney (HAMZA IBU). Please do not forget to include your direct tel/fax line for easy reach. I hope I can trust you with my family's last financial hope.Regards Dr. Mrs. Marian Sani Abacha. C/o HAMZA IBU (counsel) From noreply@sourceforge.net Sat Feb 16 00:16:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Feb 2002 16:16:35 -0800 Subject: [Patches] [ python-Patches-516715 ] HTTPConnection.send() fails large reques Message-ID: Patches item #516715, was opened at 2002-02-12 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection.send() fails large reques Initial Comment: The present implementation of HTTPConnection.send() in httplib.py does not handle the case of less than the number of requested bytes being sent via socket.send(). Indeed, this condition occurs for fairly large requests. In my environment, socket.send() will max out at transferring 33011 bytes. The routine needs to check how many bytes where actually transferred and make subsequent socket.send() calls until all of the data makes it through. In the patch I've supplied, I send slices of a particular maximum size in each iteration, rather than attempting to send the entire remainder of data, for efficiency (it proved expensive to have big slices being created per call, which would happen otherwise). I noticed that in the description of recent patches it appears that an attempt has made to address this, but the version of httplib.py that supposedly provides a fix appears to make invalid references to socket.py. If what's there is actually suitable, please do disregard. The submitted diff is against version 1.34.2.1 ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-15 16:16 Message: Logged In: YES user_id=21627 I fail to see a problem in the current code. What does "max out" mean exactly? There shouldn't be a problem passing an arbitrarily large block of data to the send system call, atleast not over a TCP connection. What operating system are you using, and what is the precise error that you get with the current code? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 From noreply@sourceforge.net Sat Feb 16 01:47:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Feb 2002 17:47:26 -0800 Subject: [Patches] [ python-Patches-516715 ] HTTPConnection.send() fails large reques Message-ID: Patches item #516715, was opened at 2002-02-12 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection.send() fails large reques Initial Comment: The present implementation of HTTPConnection.send() in httplib.py does not handle the case of less than the number of requested bytes being sent via socket.send(). Indeed, this condition occurs for fairly large requests. In my environment, socket.send() will max out at transferring 33011 bytes. The routine needs to check how many bytes where actually transferred and make subsequent socket.send() calls until all of the data makes it through. In the patch I've supplied, I send slices of a particular maximum size in each iteration, rather than attempting to send the entire remainder of data, for efficiency (it proved expensive to have big slices being created per call, which would happen otherwise). I noticed that in the description of recent patches it appears that an attempt has made to address this, but the version of httplib.py that supposedly provides a fix appears to make invalid references to socket.py. If what's there is actually suitable, please do disregard. The submitted diff is against version 1.34.2.1 ---------------------------------------------------------------------- >Comment By: James Rucker (jamesrucker) Date: 2002-02-15 17:47 Message: Logged In: YES user_id=351540 When I say 'max out' I mean that only the first 33011 (in my environment) bytes get through on a call. You don't receive an error, per se, as the client things it's send is successful. The problem is that the server doesn't get all the bytes expected. To be clear, this isn't a problem with socket.send(); just httplib.py's use of socket.send () - in particular, the expectation that a lack of an error condition being presumed to mean that all bytes were sent. In general, there isn't a problem passing arbitrarily large blocks of data, however, clients of socket.send() are to check the result of the call, which is an integer specifying the number of bytes that were actually transmitted. Note that this number is not guaranteed to be the same as the number of bytes specified. I believe that the number of bytes that make it across in a single call depend on the underlying buffering and the rate at which the client is reading. I just found the following url which talks in more detail about the issue: http://py-howto.sourceforge.net/sockets/node6.html Btw, I'm using freebsd 4.4. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-15 16:16 Message: Logged In: YES user_id=21627 I fail to see a problem in the current code. What does "max out" mean exactly? There shouldn't be a problem passing an arbitrarily large block of data to the send system call, atleast not over a TCP connection. What operating system are you using, and what is the precise error that you get with the current code? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 From noreply@sourceforge.net Sat Feb 16 04:39:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Feb 2002 20:39:03 -0800 Subject: [Patches] [ python-Patches-516715 ] HTTPConnection.send() fails large reques Message-ID: Patches item #516715, was opened at 2002-02-12 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 Status: Open Resolution: None >Priority: 7 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection.send() fails large reques Initial Comment: The present implementation of HTTPConnection.send() in httplib.py does not handle the case of less than the number of requested bytes being sent via socket.send(). Indeed, this condition occurs for fairly large requests. In my environment, socket.send() will max out at transferring 33011 bytes. The routine needs to check how many bytes where actually transferred and make subsequent socket.send() calls until all of the data makes it through. In the patch I've supplied, I send slices of a particular maximum size in each iteration, rather than attempting to send the entire remainder of data, for efficiency (it proved expensive to have big slices being created per call, which would happen otherwise). I noticed that in the description of recent patches it appears that an attempt has made to address this, but the version of httplib.py that supposedly provides a fix appears to make invalid references to socket.py. If what's there is actually suitable, please do disregard. The submitted diff is against version 1.34.2.1 ---------------------------------------------------------------------- Comment By: James Rucker (jamesrucker) Date: 2002-02-15 17:47 Message: Logged In: YES user_id=351540 When I say 'max out' I mean that only the first 33011 (in my environment) bytes get through on a call. You don't receive an error, per se, as the client things it's send is successful. The problem is that the server doesn't get all the bytes expected. To be clear, this isn't a problem with socket.send(); just httplib.py's use of socket.send () - in particular, the expectation that a lack of an error condition being presumed to mean that all bytes were sent. In general, there isn't a problem passing arbitrarily large blocks of data, however, clients of socket.send() are to check the result of the call, which is an integer specifying the number of bytes that were actually transmitted. Note that this number is not guaranteed to be the same as the number of bytes specified. I believe that the number of bytes that make it across in a single call depend on the underlying buffering and the rate at which the client is reading. I just found the following url which talks in more detail about the issue: http://py-howto.sourceforge.net/sockets/node6.html Btw, I'm using freebsd 4.4. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-15 16:16 Message: Logged In: YES user_id=21627 I fail to see a problem in the current code. What does "max out" mean exactly? There shouldn't be a problem passing an arbitrarily large block of data to the send system call, atleast not over a TCP connection. What operating system are you using, and what is the precise error that you get with the current code? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 From noreply@sourceforge.net Sat Feb 16 05:14:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 15 Feb 2002 21:14:46 -0800 Subject: [Patches] [ python-Patches-516715 ] HTTPConnection.send() fails large reques Message-ID: Patches item #516715, was opened at 2002-02-12 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 Status: Open Resolution: None Priority: 7 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection.send() fails large reques Initial Comment: The present implementation of HTTPConnection.send() in httplib.py does not handle the case of less than the number of requested bytes being sent via socket.send(). Indeed, this condition occurs for fairly large requests. In my environment, socket.send() will max out at transferring 33011 bytes. The routine needs to check how many bytes where actually transferred and make subsequent socket.send() calls until all of the data makes it through. In the patch I've supplied, I send slices of a particular maximum size in each iteration, rather than attempting to send the entire remainder of data, for efficiency (it proved expensive to have big slices being created per call, which would happen otherwise). I noticed that in the description of recent patches it appears that an attempt has made to address this, but the version of httplib.py that supposedly provides a fix appears to make invalid references to socket.py. If what's there is actually suitable, please do disregard. The submitted diff is against version 1.34.2.1 ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2002-02-15 21:14 Message: Logged In: YES user_id=35752 See this patch for more details on the problem: http://sourceforge.net/tracker/index.php?func=detail&aid=474307&group_id=5470&atid=305470 Should httplib be using sendall() instead of send()? ---------------------------------------------------------------------- Comment By: James Rucker (jamesrucker) Date: 2002-02-15 17:47 Message: Logged In: YES user_id=351540 When I say 'max out' I mean that only the first 33011 (in my environment) bytes get through on a call. You don't receive an error, per se, as the client things it's send is successful. The problem is that the server doesn't get all the bytes expected. To be clear, this isn't a problem with socket.send(); just httplib.py's use of socket.send () - in particular, the expectation that a lack of an error condition being presumed to mean that all bytes were sent. In general, there isn't a problem passing arbitrarily large blocks of data, however, clients of socket.send() are to check the result of the call, which is an integer specifying the number of bytes that were actually transmitted. Note that this number is not guaranteed to be the same as the number of bytes specified. I believe that the number of bytes that make it across in a single call depend on the underlying buffering and the rate at which the client is reading. I just found the following url which talks in more detail about the issue: http://py-howto.sourceforge.net/sockets/node6.html Btw, I'm using freebsd 4.4. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-15 16:16 Message: Logged In: YES user_id=21627 I fail to see a problem in the current code. What does "max out" mean exactly? There shouldn't be a problem passing an arbitrarily large block of data to the send system call, atleast not over a TCP connection. What operating system are you using, and what is the precise error that you get with the current code? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 From noreply@sourceforge.net Sat Feb 16 09:41:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 01:41:16 -0800 Subject: [Patches] [ python-Patches-516715 ] HTTPConnection.send() fails large reques Message-ID: Patches item #516715, was opened at 2002-02-12 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 Status: Open Resolution: None Priority: 7 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection.send() fails large reques Initial Comment: The present implementation of HTTPConnection.send() in httplib.py does not handle the case of less than the number of requested bytes being sent via socket.send(). Indeed, this condition occurs for fairly large requests. In my environment, socket.send() will max out at transferring 33011 bytes. The routine needs to check how many bytes where actually transferred and make subsequent socket.send() calls until all of the data makes it through. In the patch I've supplied, I send slices of a particular maximum size in each iteration, rather than attempting to send the entire remainder of data, for efficiency (it proved expensive to have big slices being created per call, which would happen otherwise). I noticed that in the description of recent patches it appears that an attempt has made to address this, but the version of httplib.py that supposedly provides a fix appears to make invalid references to socket.py. If what's there is actually suitable, please do disregard. The submitted diff is against version 1.34.2.1 ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-16 01:41 Message: Logged In: YES user_id=21627 I believe it should use sendall throughout; in fact, 2.1.1/2 does that. I've ported Anthony's patch from http://aspn.activestate.com/ASPN/Mail/Message/Python-checkins/956422 to 2.2, please find this attached. I'll do a quick check as to why that wasn't applied to 2.2, and then commit it. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-02-15 21:14 Message: Logged In: YES user_id=35752 See this patch for more details on the problem: http://sourceforge.net/tracker/index.php?func=detail&aid=474307&group_id=5470&atid=305470 Should httplib be using sendall() instead of send()? ---------------------------------------------------------------------- Comment By: James Rucker (jamesrucker) Date: 2002-02-15 17:47 Message: Logged In: YES user_id=351540 When I say 'max out' I mean that only the first 33011 (in my environment) bytes get through on a call. You don't receive an error, per se, as the client things it's send is successful. The problem is that the server doesn't get all the bytes expected. To be clear, this isn't a problem with socket.send(); just httplib.py's use of socket.send () - in particular, the expectation that a lack of an error condition being presumed to mean that all bytes were sent. In general, there isn't a problem passing arbitrarily large blocks of data, however, clients of socket.send() are to check the result of the call, which is an integer specifying the number of bytes that were actually transmitted. Note that this number is not guaranteed to be the same as the number of bytes specified. I believe that the number of bytes that make it across in a single call depend on the underlying buffering and the rate at which the client is reading. I just found the following url which talks in more detail about the issue: http://py-howto.sourceforge.net/sockets/node6.html Btw, I'm using freebsd 4.4. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-15 16:16 Message: Logged In: YES user_id=21627 I fail to see a problem in the current code. What does "max out" mean exactly? There shouldn't be a problem passing an arbitrarily large block of data to the send system call, atleast not over a TCP connection. What operating system are you using, and what is the precise error that you get with the current code? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 From noreply@sourceforge.net Sat Feb 16 15:41:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 07:41:42 -0800 Subject: [Patches] [ python-Patches-516715 ] HTTPConnection.send() fails large reques Message-ID: Patches item #516715, was opened at 2002-02-12 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 Status: Open Resolution: None Priority: 7 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection.send() fails large reques Initial Comment: The present implementation of HTTPConnection.send() in httplib.py does not handle the case of less than the number of requested bytes being sent via socket.send(). Indeed, this condition occurs for fairly large requests. In my environment, socket.send() will max out at transferring 33011 bytes. The routine needs to check how many bytes where actually transferred and make subsequent socket.send() calls until all of the data makes it through. In the patch I've supplied, I send slices of a particular maximum size in each iteration, rather than attempting to send the entire remainder of data, for efficiency (it proved expensive to have big slices being created per call, which would happen otherwise). I noticed that in the description of recent patches it appears that an attempt has made to address this, but the version of httplib.py that supposedly provides a fix appears to make invalid references to socket.py. If what's there is actually suitable, please do disregard. The submitted diff is against version 1.34.2.1 ---------------------------------------------------------------------- >Comment By: James Rucker (jamesrucker) Date: 2002-02-16 07:41 Message: Logged In: YES user_id=351540 Using sendall() proposed in the diff of socketmodule.c provided by the patch nascheme referenced does make sense. Note that there is an extraneous variable 'total' in the PySocketSock_sendall() (not sure that you care to know that here, but I thought I should point it out). Also, while I see the revision of socketmodule.c specifying sendall() in certain versions, I didn't see versions of httplib.py that used it (you said that 2.1.1/2 does). Can you provide a CVS revision number of httplib.py that uses sendall() (forgive me, but I'm trying to make sure I'm understanding your naming conventions, and I'd also like to apply the patch here with code from the actual repository). ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-16 01:41 Message: Logged In: YES user_id=21627 I believe it should use sendall throughout; in fact, 2.1.1/2 does that. I've ported Anthony's patch from http://aspn.activestate.com/ASPN/Mail/Message/Python-checkins/956422 to 2.2, please find this attached. I'll do a quick check as to why that wasn't applied to 2.2, and then commit it. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-02-15 21:14 Message: Logged In: YES user_id=35752 See this patch for more details on the problem: http://sourceforge.net/tracker/index.php?func=detail&aid=474307&group_id=5470&atid=305470 Should httplib be using sendall() instead of send()? ---------------------------------------------------------------------- Comment By: James Rucker (jamesrucker) Date: 2002-02-15 17:47 Message: Logged In: YES user_id=351540 When I say 'max out' I mean that only the first 33011 (in my environment) bytes get through on a call. You don't receive an error, per se, as the client things it's send is successful. The problem is that the server doesn't get all the bytes expected. To be clear, this isn't a problem with socket.send(); just httplib.py's use of socket.send () - in particular, the expectation that a lack of an error condition being presumed to mean that all bytes were sent. In general, there isn't a problem passing arbitrarily large blocks of data, however, clients of socket.send() are to check the result of the call, which is an integer specifying the number of bytes that were actually transmitted. Note that this number is not guaranteed to be the same as the number of bytes specified. I believe that the number of bytes that make it across in a single call depend on the underlying buffering and the rate at which the client is reading. I just found the following url which talks in more detail about the issue: http://py-howto.sourceforge.net/sockets/node6.html Btw, I'm using freebsd 4.4. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-15 16:16 Message: Logged In: YES user_id=21627 I fail to see a problem in the current code. What does "max out" mean exactly? There shouldn't be a problem passing an arbitrarily large block of data to the send system call, atleast not over a TCP connection. What operating system are you using, and what is the precise error that you get with the current code? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 From noreply@sourceforge.net Sat Feb 16 23:15:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 15:15:28 -0800 Subject: [Patches] [ python-Patches-516715 ] HTTPConnection.send() fails large reques Message-ID: Patches item #516715, was opened at 2002-02-12 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 Category: Library (Lib) Group: Python 2.1.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: James Rucker (jamesrucker) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection.send() fails large reques Initial Comment: The present implementation of HTTPConnection.send() in httplib.py does not handle the case of less than the number of requested bytes being sent via socket.send(). Indeed, this condition occurs for fairly large requests. In my environment, socket.send() will max out at transferring 33011 bytes. The routine needs to check how many bytes where actually transferred and make subsequent socket.send() calls until all of the data makes it through. In the patch I've supplied, I send slices of a particular maximum size in each iteration, rather than attempting to send the entire remainder of data, for efficiency (it proved expensive to have big slices being created per call, which would happen otherwise). I noticed that in the description of recent patches it appears that an attempt has made to address this, but the version of httplib.py that supposedly provides a fix appears to make invalid references to socket.py. If what's there is actually suitable, please do disregard. The submitted diff is against version 1.34.2.1 ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-16 15:15 Message: Logged In: YES user_id=21627 I've applied the sendall patch, as httplib.py 1.44 and 1.42.10.1. Python 2.1.2 uses sendall in httplib.py 1.34.2.2 (2.1.1 didn't). I've also removed 'total' in socketmodule.c 1.207; thanks for the report. ---------------------------------------------------------------------- Comment By: James Rucker (jamesrucker) Date: 2002-02-16 07:41 Message: Logged In: YES user_id=351540 Using sendall() proposed in the diff of socketmodule.c provided by the patch nascheme referenced does make sense. Note that there is an extraneous variable 'total' in the PySocketSock_sendall() (not sure that you care to know that here, but I thought I should point it out). Also, while I see the revision of socketmodule.c specifying sendall() in certain versions, I didn't see versions of httplib.py that used it (you said that 2.1.1/2 does). Can you provide a CVS revision number of httplib.py that uses sendall() (forgive me, but I'm trying to make sure I'm understanding your naming conventions, and I'd also like to apply the patch here with code from the actual repository). ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-16 01:41 Message: Logged In: YES user_id=21627 I believe it should use sendall throughout; in fact, 2.1.1/2 does that. I've ported Anthony's patch from http://aspn.activestate.com/ASPN/Mail/Message/Python-checkins/956422 to 2.2, please find this attached. I'll do a quick check as to why that wasn't applied to 2.2, and then commit it. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-02-15 21:14 Message: Logged In: YES user_id=35752 See this patch for more details on the problem: http://sourceforge.net/tracker/index.php?func=detail&aid=474307&group_id=5470&atid=305470 Should httplib be using sendall() instead of send()? ---------------------------------------------------------------------- Comment By: James Rucker (jamesrucker) Date: 2002-02-15 17:47 Message: Logged In: YES user_id=351540 When I say 'max out' I mean that only the first 33011 (in my environment) bytes get through on a call. You don't receive an error, per se, as the client things it's send is successful. The problem is that the server doesn't get all the bytes expected. To be clear, this isn't a problem with socket.send(); just httplib.py's use of socket.send () - in particular, the expectation that a lack of an error condition being presumed to mean that all bytes were sent. In general, there isn't a problem passing arbitrarily large blocks of data, however, clients of socket.send() are to check the result of the call, which is an integer specifying the number of bytes that were actually transmitted. Note that this number is not guaranteed to be the same as the number of bytes specified. I believe that the number of bytes that make it across in a single call depend on the underlying buffering and the rate at which the client is reading. I just found the following url which talks in more detail about the issue: http://py-howto.sourceforge.net/sockets/node6.html Btw, I'm using freebsd 4.4. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-15 16:16 Message: Logged In: YES user_id=21627 I fail to see a problem in the current code. What does "max out" mean exactly? There shouldn't be a problem passing an arbitrarily large block of data to the send system call, atleast not over a TCP connection. What operating system are you using, and what is the precise error that you get with the current code? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=516715&group_id=5470 From noreply@sourceforge.net Sat Feb 16 23:17:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 15:17:23 -0800 Subject: [Patches] [ python-Patches-515598 ] removed unused import tkCommonDialog Message-ID: Patches item #515598, was opened at 2002-02-10 11:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515598&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: removed unused import tkCommonDialog Initial Comment: Python 2.2 (#1, Dec 28 2001, 11:17:23) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Unused import os removed from tkCommonDialog.py ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-16 15:17 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as 1.6. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515598&group_id=5470 From noreply@sourceforge.net Sat Feb 16 23:22:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 15:22:54 -0800 Subject: [Patches] [ python-Patches-515597 ] remove unused parameter tkFileDialog Message-ID: Patches item #515597, was opened at 2002-02-10 11:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515597&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) >Assigned to: Fredrik Lundh (effbot) Summary: remove unused parameter tkFileDialog Initial Comment: Python 2.2 (#1, Dec 28 2001, 11:17:23) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Removing an unused 'widget' 'parameter from tkFileDialog Dictionary._fixresult and tkCommonDialog. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-16 15:22 Message: Logged In: YES user_id=21627 I'm not sure that this change is a good idea; people may have subclassed the existing classes and implemented their own _fixresult methods; such code would break with your change. Assigning to /F; if he doesn't object, and you would still like to see this change, I'd accept it as a minor incompatibily. If no further comments are made until March 1, this patch should be rejected. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515597&group_id=5470 From noreply@sourceforge.net Sat Feb 16 23:35:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 15:35:58 -0800 Subject: [Patches] [ python-Patches-511193 ] Implement killpg in posixmodule Message-ID: Patches item #511193, was opened at 2002-01-31 05:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511193&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gustavo Niemeyer (niemeyer) Assigned to: Nobody/Anonymous (nobody) Summary: Implement killpg in posixmodule Initial Comment: killpg is currently not accessible from python standard library. Since process group handling functions are accessible (setsid, setpgrp, getpgrp, setpgid), this one should probably be there as well. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-16 15:35 Message: Logged In: YES user_id=21627 Thanks, applied as configure 1.282 configure.in 1.291 pyconfig.h.in 1.22 posixmodule.c 2.222 NEWS 1.357 ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2002-02-12 19:16 Message: Logged In: YES user_id=7887 Oops... my fault, sorry! Now the file is there (I hope.. :-). ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:31 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511193&group_id=5470 From noreply@sourceforge.net Sat Feb 16 23:42:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 15:42:03 -0800 Subject: [Patches] [ python-Patches-508038 ] can't say "char digit": digit is a type! Message-ID: Patches item #508038, was opened at 2002-01-24 09:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=508038&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Russ Cox (rsc) Assigned to: Nobody/Anonymous (nobody) >Summary: can't say "char digit": digit is a type! Initial Comment: digit is typedefed in longintrepr.h, but longobject.c contains a declaration "char digit", which, due to the typedef, is not legal. patch changes digit to cdigit. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-16 15:42 Message: Logged In: YES user_id=21627 Thanks for the patch, applied as longobject.c 1.113 and 1.112.8.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=508038&group_id=5470 From noreply@sourceforge.net Sat Feb 16 23:44:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 15:44:50 -0800 Subject: [Patches] [ python-Patches-499939 ] Fix for buggy https servers. Message-ID: Patches item #499939, was opened at 2002-01-05 12:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499939&group_id=5470 Category: Modules Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Michel Van den Bergh (vdbergh) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for buggy https servers. Initial Comment: Python 2.2. Tested on RH 7.1. This a workaround for, http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=494762 The problem is that some https servers close an ssl connection without properly resetting it first. In the above bug description it is suggested that this only occurs for IIS but apparently some (modified) Apache servers also suffer from it (see telemeter.telenet.be). One of the suggested workarounds is to modify httplib.py so as to ignore the combination of err[0]==SSL_ERROR_SYSCALL and err[1]=="EOF occurred in violation of protocol". However I think one should never compare error strings since in principle they may depend on language etc... So I decided to modify _socket.c slightly so that it becomes possible to return error codes which are not in in ssl.h. You will see that I did this in a portable way, which is independent of the explicit error numbers in ssl.h. When an ssl-connection is closed without reset I now return the error code SSL_ERROR_EOF. Then I ignore this (apparently benign) error in httplib.py. In addition I fixed what I think was an error in PySSL_SetError(SSL *ssl, int ret) in socketmodule.c. Originally there was: case SSL_ERROR_SSL: { unsigned long e = ERR_get_error(); if (e == 0) { /* an EOF was observed that violates the protocol */ errstr = "EOF occurred in violation of protocol"; etc... but if I understand the documentation for SSL_get_error then the test should be: e==0 && ret==0. A similar error occurs a few lines later. ---------------------------------------------------------------------- Comment By: Michel Van den Bergh (vdbergh) Date: 2002-01-09 02:29 Message: Logged In: YES user_id=10252 Due to some problems with sourceforge and incompetence on my part I seem to have submitted several times. See patch 500311. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=499939&group_id=5470 From noreply@sourceforge.net Sun Feb 17 00:36:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 16:36:20 -0800 Subject: [Patches] [ python-Patches-518625 ] Return objects in Tkinter Message-ID: Patches item #518625, was opened at 2002-02-16 16:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=518625&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L�wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Return objects in Tkinter Initial Comment: This patch uses the Tcl object API to convert return values to Python objects. For boolean, bytearray, double, int, list, and string objects, the equivalent Python objects are constructed (Unicode for Tcl string). For untyped objects, strings are returned. For all other objects, a Python wrapper object is returned which supports a tp_str conversion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=518625&group_id=5470 From noreply@sourceforge.net Sun Feb 17 05:16:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 21:16:11 -0800 Subject: [Patches] [ python-Patches-450267 ] OS/2+EMX port - changes to Python core Message-ID: Patches item #450267, was opened at 2001-08-12 04:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450267&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Martin v. L�wis (loewis) Summary: OS/2+EMX port - changes to Python core Initial Comment: The attached patch incorporates the changes to the source tree between Python 2.1.1 and the 010812 release of the OS/2+EMX port. It includes changes to files in Include/, Modules/, Objects/ and Python/. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-02-16 21:16 Message: Logged In: YES user_id=250749 Following discussion on python-dev, I have created patches for Objects/stringobject.c and Objects/unicodeobject.c that aim to rationalise the %#x/%#X format conversion mess. These two patches remove approaches specific to the various bugs and standard violations encountered with these format conversions, and take the approach of relying on the behaviour of the %x/%X format conversions and directly supplying Python's preferred prefix (0x/0X respectively). The patches presented are against CVS of 15Feb02 1430 AEST, and have been tested on both OS/2 and FreeBSD. If acceptable, I would prefer to apply my pre-existing patches for these files (the Objects patch below) before these new patches, as my earlier patches with their EMX specifics in OS/2 specific #ifdefs are "failsafe" as far as other platforms are concerned. Then if the new approach causes other platforms to fail, these patches can be backed out without breaking the OS/2 port. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-01-26 22:19 Message: Logged In: YES user_id=250749 I have split the original approach into patches for each of the Include, Modules, Objects and Python directories. Of particular note: - the patches to import.c are general to both VACPP and EMX ports, and have been trialled by Michael Muller with satisfactory results. - Modules/unicodedata.c has a name clash between its internally defined _getname() and an EMX routine of the same name defined in . Is the solution in the patch acceptable? - both Objects/stringobject.c and Objects/unicodeobject.c have changes to deal with EMX's runtime not producing a desired "0X" prefix in response to a "%X" format specifier (it produces "0x" instead). The patched source tree has been built and regression tested on both EMX and FreeBSD 4.4, with no unexpected results. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2001-10-01 15:59 Message: Logged In: YES user_id=21627 Please review this patch carefully again, asking in each case whether this chunk *really* belongs to this patch. Do so by asking "is it specific to the port of Python to os2emx?" There are some changes that are desirable, but are unrelated (like the whitespace changes in PyThread_down_sema). Please submit those in a separate patch. There are also changes that don't belong here at all, like the inclusion of a Modules/Setup. If you are revising this patch, you may also split it into a part that is absolutely necessary, and a part that is nice-to-have. E.g. the termios changes are probably system-specific, but I guess the port would work well without them. Without going in small steps, it seems that we won't move at all. You may consider making use of your checkin permissions for uncritical operations. If you need help in CVS operations, please let me know. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2001-08-13 06:21 Message: Logged In: YES user_id=250749 Thanks for the feedback. At this stage of the game, I'd prefer to work with a "supervisor" rather than take on CVS commit privs, though I realise that "supervisors" are a scarce resource. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-12 07:53 Message: Logged In: YES user_id=6380 Hi Andrew, Thanks for the patches. There's a lot of code (here and in the two previous patches). I'm going to see if we can give you CVS commit permission so you can apply the changes yourself. Note that commit permission (if you get it) doesn't mean that the patch is automatically approved -- I've seen some changes in your diffs that look questionable. You probably know which ones. :-) In general, the guidelines are that you can make changes freely (a) in code you own because it's in a file or directory that's specific to your port; (b) in code specific to your port that's inside #ifdefs for your port (this includes adding); (c) to fix an *obvious* small typo or buglet that bothers your compiler (example: if your compiler warns about an unused variable, feel free to delete it, as long as the unusedness isn't dependent on an #ifdef). For other changes we all appreciate it if you discuss them on python-dev or on the SF patch manager first. Oh, and if you ever check something in that breaks the build on another platform or causes the test suite to fail, people will demand very quick remedies or the checkin will be reversed. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450267&group_id=5470 From noreply@sourceforge.net Sun Feb 17 05:45:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 21:45:15 -0800 Subject: [Patches] [ python-Patches-518675 ] Adding galeon support Message-ID: Patches item #518675, was opened at 2002-02-16 21:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=518675&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Supreet Sethi (supreet) Assigned to: Nobody/Anonymous (nobody) Summary: Adding galeon support Initial Comment: It adds support galeon browser support in webbrowser lib. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=518675&group_id=5470 From noreply@sourceforge.net Sun Feb 17 06:23:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 22:23:54 -0800 Subject: [Patches] [ python-Patches-512256 ] ceval micro optimizations Message-ID: Patches item #512256, was opened at 2002-02-02 16:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512256&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Accepted Priority: 6 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: ceval micro optimizations Initial Comment: These are good for a 5% speed increase according to pystone and pybench. Changes: - move common instructions to top of switch stmt - simplify SET_LINENO block by calling call_trace instead of inlining it - skip "things_to_do" block for a few ops that don't actually do any work (like SET_LINENO and POP_TOP). - tweak if statements so that GCC generates better code ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-02-16 22:23 Message: Logged In: YES user_id=31435 These are nice little changes, and huge on the bang/buck scale -- go ahead! Note that I broke the patch by changing LOAD_FAST independently. I suppose I should mark it Out of Date, but to avoid pointless thrashing I jumped straight to Accepted. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-12 12:13 Message: Logged In: YES user_id=31435 Boosted priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512256&group_id=5470 From noreply@sourceforge.net Sun Feb 17 07:31:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 23:31:07 -0800 Subject: [Patches] [ python-Patches-450265 ] OS/2 + EMX port - PC directory files Message-ID: Patches item #450265, was opened at 2001-08-12 04:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: OS/2 + EMX port - PC directory files Initial Comment: The attached patch contains all the changes to the PC directory in the source tree between Python 2.1.1 and the 010812 release of the OS/2+EMX port. This comprises changes to PC/getpathp.c and a new subdirectory, PC/os2emx, which contains the Makefile, config.[ch], dlfcn.[ch], dllentry.c, python DLL .DEF file and a copy of the port's README.os2emx. At the moment, building dynamic modules is still handled by the supplied Makefile, rather than a DistUtils setup.py script. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-02-16 23:31 Message: Logged In: YES user_id=250749 Committed. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-01-26 21:42 Message: Logged In: YES user_id=250749 This updated patch against post-2.2 CVS adds a PC/os2emx directory, which contains all the build related files for the EMX port. No changes are made to any of the other files in the PC directory. The optional extensions that I support in the binary package are disabled by default in the makefile, as most of the dependencies need rebuilding to match the build environment of the Python port (typically enabling multithreading support). ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-01-03 02:45 Message: Logged In: YES user_id=21627 If you continue to organize the patches in the same way, just updating the existing report should be fine. If it is more convenient for you, creating a new report is fine, as well. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-01-02 15:20 Message: Logged In: YES user_id=250749 I am preparing updated patches against CVS for this and the other EMX related patches, and will upload in the next few days. Specifically for this patch, the updated version will just add a PC/os2emx subdirectory, and touch no other files in the PC directory (as the patch currently attached does). Would it be better to reject the 4 currently outstanding patches and submit new ones for this, or just update the current ones? ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-01-02 15:19 Message: Logged In: YES user_id=250749 I am preparing updated patches against CVS for this and the other EMX related patches, and will upload in the next few days. Specifically for this patch, the updated version will just add a PC/os2emx subdirectory, and touch no other files in the PC directory (as the patch currently attached does). Would it be better to reject the 4 currently outstanding patches and submit new ones for this, or just update the current ones? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2001-12-28 14:47 Message: Logged In: YES user_id=21627 Andrew, are you still interested in updating this patch? Otherwise, I recommend to reject it. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2001-10-01 15:41 Message: Logged In: YES user_id=21627 What kind of action would you like to see on this code? In the areas where it changes existing code, there are some questionable chunks, which I would not like to see in Python: - removal of comments - change of control logic without giving a rationale. E.g. there was an explicit comment /* If we have no values, we dont need a ';' */ Your patch changes this to give a ; in all cases. Why? Why is the addition of a terminating null in wprogpath removed? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-12 07:45 Message: Logged In: YES user_id=6380 Andrew, your patch attachment didn't work. Please try again, making sure you check the "file upload checkbox". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450265&group_id=5470 From noreply@sourceforge.net Sun Feb 17 07:53:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 16 Feb 2002 23:53:12 -0800 Subject: [Patches] [ python-Patches-515597 ] remove unused parameter tkFileDialog Message-ID: Patches item #515597, was opened at 2002-02-10 11:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515597&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Fredrik Lundh (effbot) Summary: remove unused parameter tkFileDialog Initial Comment: Python 2.2 (#1, Dec 28 2001, 11:17:23) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Removing an unused 'widget' 'parameter from tkFileDialog Dictionary._fixresult and tkCommonDialog. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2002-02-16 23:53 Message: Logged In: YES user_id=38376 This breaks the tkColorChooser module (and any other dialog subclass that needs a Tkinter widget context). ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-16 15:22 Message: Logged In: YES user_id=21627 I'm not sure that this change is a good idea; people may have subclassed the existing classes and implemented their own _fixresult methods; such code would break with your change. Assigning to /F; if he doesn't object, and you would still like to see this change, I'd accept it as a minor incompatibily. If no further comments are made until March 1, this patch should be rejected. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515597&group_id=5470 From noreply@sourceforge.net Sun Feb 17 14:53:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 17 Feb 2002 06:53:48 -0800 Subject: [Patches] [ python-Patches-518765 ] Bug in copy.py when used through rexec Message-ID: Patches item #518765, was opened at 2002-02-17 06:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=518765&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Derek Harland (dharland) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in copy.py when used through rexec Initial Comment: Version: In all versions since Python 1.5.2 up to the current Python 2.3a0 Platforms: All When using a restricted environment, imports of copy will fail with an AttributeError when trying to access types.CodeType. This occurs while trying to set up the deepcopy helper dictionary. The creation of the shallow copy helper dictionary works fine as the attempt to extract types.CodeType is explicitly wrapped in a try. This very minor patch adds the same try except wrapper for the deepcopy setup. example: >>> import rexec >>> rexec.RExec().r_import('copy') Traceback (most recent call last): File "", line 1, in ? File "/home/harland/dev/sourceforge/python/dist/src/Lib/rexec.py", line 265, in r_import return self.importer.import_module(mname, globals, locals, fromlist) File "/home/harland/dev/sourceforge/python/dist/src/Lib/ihooks.py", line 397, in import_module q, tail = self.find_head_package(parent, name) File "/home/harland/dev/sourceforge/python/dist/src/Lib/ihooks.py", line 433, in find_head_package q = self.import_it(head, qname, parent) File "/home/harland/dev/sourceforge/python/dist/src/Lib/ihooks.py", line 486, in import_it m = self.loader.load_module(fqname, stuff) File "/home/harland/dev/sourceforge/python/dist/src/Lib/ihooks.py", line 325, in load_module exec code in m.__dict__ File "/home/harland/dev/sourceforge/python/dist/src/Lib/copy.py", line 200, in ? d[types.CodeType] = _deepcopy_atomic AttributeError: 'module' object has no attribute 'CodeType' ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=518765&group_id=5470 From noreply@sourceforge.net Sun Feb 17 19:11:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 17 Feb 2002 11:11:51 -0800 Subject: [Patches] [ python-Patches-512256 ] ceval micro optimizations Message-ID: Patches item #512256, was opened at 2002-02-02 16:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512256&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 6 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: ceval micro optimizations Initial Comment: These are good for a 5% speed increase according to pystone and pybench. Changes: - move common instructions to top of switch stmt - simplify SET_LINENO block by calling call_trace instead of inlining it - skip "things_to_do" block for a few ops that don't actually do any work (like SET_LINENO and POP_TOP). - tweak if statements so that GCC generates better code ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2002-02-17 11:11 Message: Logged In: YES user_id=35752 Checked in with minor modifications as ceval.c 2.305. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-16 22:23 Message: Logged In: YES user_id=31435 These are nice little changes, and huge on the bang/buck scale -- go ahead! Note that I broke the patch by changing LOAD_FAST independently. I suppose I should mark it Out of Date, but to avoid pointless thrashing I jumped straight to Accepted. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-12 12:13 Message: Logged In: YES user_id=31435 Boosted priority. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=512256&group_id=5470 From josh.winters@webstream.net Mon Feb 18 23:37:55 2002 From: josh.winters@webstream.net (josh.winters@webstream.net) Date: Mon, 18 Feb 2002 18:37:55 -0500 Subject: [Patches] We would like to possibly get some info on your company Message-ID: Hello, We would like to possibly get some info on your company in an effort to explore the ways that we might be able to work together. We may be able to save you money and offer you the benefits of our reseller program. We have been developing and hosting web sites since 1997. We offer design, programming, hosting and webcasting and videoconferencing. We support Linux, NT and AS400. Please forward this to the proper party, or respond to the address below. You can also visit our web site at http://webstream.net for more information on our services. If by e-mail: josh.winters@webstream.net If by mail: WebStream Internet Solutions Outsourcing/Purchasing 2200 W.Commercial Blvd. Suite 204 Ft. Lauderdale, FL 33309 USA Thank you very much. Sincerely, Josh Winters josh.winters@webstream.net http://webstream.net Design * Programming * Hosting * WebCasting * Since 1997 From noreply@sourceforge.net Tue Feb 19 16:42:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Feb 2002 08:42:11 -0800 Subject: [Patches] [ python-Patches-515041 ] path in site doc refers to 1.5 Message-ID: Patches item #515041, was opened at 2002-02-08 14:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515041&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: path in site doc refers to 1.5 Initial Comment: doc for the site module refers to 1.5 in paths, this patch updates the paths to include 2.2 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-19 08:42 Message: Logged In: YES user_id=33168 Checked in as 1.22.6.1 and 1.23. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:21 Message: Logged In: YES user_id=21627 Please apply this to the 2.2 maintainance branch; for the trunk, please apply an equivalent 2.3 patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515041&group_id=5470 From noreply@sourceforge.net Tue Feb 19 16:43:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Feb 2002 08:43:05 -0800 Subject: [Patches] [ python-Patches-515023 ] thr.join() signatures are different Message-ID: Patches item #515023, was opened at 2002-02-08 14:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515023&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: thr.join() signatures are different Initial Comment: the _DummyThread.join() signature doesn't match it's base class. this patch adds a timeout parameter with default value to match Thread. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-02-19 08:43 Message: Logged In: YES user_id=33168 Checked in as 1.21 and 1.19.12.2. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:20 Message: Logged In: YES user_id=21627 This patch looks fine, please apply. It should also go into 2.2.1 (being a bug fix); either commit it their yourself, or indicate in your checkin message that it is a bugfix candidate. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=515023&group_id=5470 From noreply@sourceforge.net Tue Feb 19 17:53:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Feb 2002 09:53:04 -0800 Subject: [Patches] [ python-Patches-518675 ] Adding galeon support Message-ID: Patches item #518675, was opened at 2002-02-16 21:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=518675&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Supreet Sethi (supreet) Assigned to: Nobody/Anonymous (nobody) Summary: Adding galeon support Initial Comment: It adds support galeon browser support in webbrowser lib. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-19 09:53 Message: Logged In: YES user_id=21627 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=518675&group_id=5470 From noreply@sourceforge.net Tue Feb 19 17:57:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 19 Feb 2002 09:57:32 -0800 Subject: [Patches] [ python-Patches-520062 ] Support IPv6 with VC.NET Message-ID: Patches item #520062, was opened at 2002-02-19 09:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520062&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L�wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Support IPv6 with VC.NET Initial Comment: This patch enables IPv6 support based on Winsock2 on Microsoft C 13 and later. Due to the implementation strategy used in the SDK headers, the resulting _socket.pyd will not require additional shared libraries, but it will instead locale the symbols dynamically, and fall back to a default implementation if none are found. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520062&group_id=5470 From noreply@sourceforge.net Wed Feb 20 08:57:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 00:57:40 -0800 Subject: [Patches] [ python-Patches-403685 ] Printing unicode Message-ID: Patches item #403685, was opened at 2001-02-08 06:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403685&group_id=5470 Category: Core (C code) Group: None Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: M.-A. Lemburg (lemburg) Summary: Printing unicode Initial Comment: The print statement *always* passes the to-be-printed objects through str() before passing them onto the file.write(). This is a problem for unicode. It is not possible to print unicode strings to a unicode-aware file. This patch allows a stream to inhibit this automatic call to str() by defining a false __str__before_write__ attribute. Such an attribute has been added to the streams in the codecs.py I hope the documentation patch is correct; Im not able to test it. (added by Toby Dickenson, sourceforge id 'htrd', who seems to have a broken https) ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 00:57 Message: Logged In: YES user_id=21627 Superceded by patch #462849. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-02-10 06:23 Message: Postponed for discussion in Python 2.2 cycle as per request by Guido. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-02-09 05:45 Message: I'd rather break some code here and then get this done right once and for all. I wouldn't want to carry along a special attribute which needs to be checked before every .write() operation. This costs performance and adds unnecessary convolution to the file API. Since Unicode is still very new, I doubt that the impact of this will cause people too much trouble. IMHO, the correct way to deal with this is to let the file object write methods deal with the problem in an application specific way. cStringIO.c (and all other file-like objects) should be fixed to use the s# parser markers instead of requiring a real string object. This will also enhance interoperability with other data storage types. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-02-09 04:54 Message: waaah - without https I cant upload a new version of the patch. The original patch fails to clear the exception if getattr('__str__before_write__') fails... that inner part of PyFile_WriteObject needs to be: stringize = PyObject_GetAttrString(f, "__str_before_write__"); if(!stringize) PyErr_Clear(); if(!stringize || PyObject_IsTrue(stringize)) value = PyObject_Str(v); else { Py_INCREF(v); value = v; } my appologies for the extra trouble. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-02-09 04:02 Message: I hadnt seen that original discussion, and cant find it in the archives now :-( However, your summary matches exactly what this patch achieves for files have __str_before_write__=0 I think we have to require this extra flag to enable the new behaviour. For example, this prevents breakage of old code that prints to a StringIO instance. (Toby Dickenson, tdickenson@geminidataloggers.com) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-02-08 08:02 Message: I don't remember the details, but there was a discussion about this problem on python-dev. The outcome was to let Unicode objects pass through as-is to the file object and then have it apply whatever conversion it takes. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403685&group_id=5470 From noreply@sourceforge.net Wed Feb 20 14:51:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 06:51:38 -0800 Subject: [Patches] [ python-Patches-490374 ] make inspect.stack() work with PyShell Message-ID: Patches item #490374, was opened at 2001-12-07 11:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490374&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: make inspect.stack() work with PyShell Initial Comment: I'm on Python 2.2b2 on Windows. Changed the 'inspect' module to use 'linecache' for loading source code. This is more efficient. Also, 'inspect' now can see the source code of stuff entered in the IDLE PyShell. E.g. In IDLE, type: >>> import inspect >>> inspect.stack()[0] Without the patch, the output would be like this: (, None, 1, '?', None, None) With this patch: (, '', 1, '?', ['inspect.stack()[0]'], 0) ---------------------------------------------------------------------- >Comment By: Jason Orendorff (jorend) Date: 2002-02-20 06:51 Message: Logged In: YES user_id=18139 >poke< ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2001-12-07 12:07 Message: Logged In: YES user_id=18139 I'm afraid it's definitely a feature. (sigh) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-07 12:04 Message: Logged In: YES user_id=6380 Assigned to Tim for review, since he knows inspect.py inside-out. :-) It's probably too late for 2.2, unless you can prove this is a bugfix and not a feature. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=490374&group_id=5470 From noreply@sourceforge.net Wed Feb 20 14:58:51 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 06:58:51 -0800 Subject: [Patches] [ python-Patches-520483 ] Make IDLE OutputWindow handle Unicode Message-ID: Patches item #520483, was opened at 2002-02-20 06:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: Make IDLE OutputWindow handle Unicode Initial Comment: This one-line patch makes OutputWindow handle Unicode correctly. For example, >>> print u'\xbfQu\xe9 pas\xf3?' In 2.2 this throws a UnicodeError, not because of any problem with Unicode handling in either Python or Tk, but because IDLE does str(s) on the Unicode string. I just took out the call to str(). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 From noreply@sourceforge.net Wed Feb 20 22:38:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 14:38:37 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Wed Feb 20 22:41:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 14:41:38 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Wed Feb 20 22:56:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 14:56:21 -0800 Subject: [Patches] [ python-Patches-520483 ] Make IDLE OutputWindow handle Unicode Message-ID: Patches item #520483, was opened at 2002-02-20 06:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: Make IDLE OutputWindow handle Unicode Initial Comment: This one-line patch makes OutputWindow handle Unicode correctly. For example, >>> print u'\xbfQu\xe9 pas\xf3?' In 2.2 this throws a UnicodeError, not because of any problem with Unicode handling in either Python or Tk, but because IDLE does str(s) on the Unicode string. I just took out the call to str(). ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 14:56 Message: Logged In: YES user_id=21627 Isn't this too simplistic? I guess there was a reason for the str call: could it ever happen that somebody passes something else (beyond byte and Unicode strings)? Also, I wonder whether IDLE patches need to go to idlefork (sf.net/projects/idlefork) first. Apart from this comments, I think your patch is quite right. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 From noreply@sourceforge.net Wed Feb 20 23:02:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 15:02:03 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 15:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Wed Feb 20 23:27:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 15:27:39 -0800 Subject: [Patches] [ python-Patches-520483 ] Make IDLE OutputWindow handle Unicode Message-ID: Patches item #520483, was opened at 2002-02-20 06:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: Make IDLE OutputWindow handle Unicode Initial Comment: This one-line patch makes OutputWindow handle Unicode correctly. For example, >>> print u'\xbfQu\xe9 pas\xf3?' In 2.2 this throws a UnicodeError, not because of any problem with Unicode handling in either Python or Tk, but because IDLE does str(s) on the Unicode string. I just took out the call to str(). ---------------------------------------------------------------------- >Comment By: Jason Orendorff (jorend) Date: 2002-02-20 15:27 Message: Logged In: YES user_id=18139 > Isn't this too simplistic? I guess there was a reason for > the str call: could it ever happen that somebody passes > something else (beyond byte and Unicode strings)? I searched for write() in the idle directory and got 48 hits in 7 files. Then I checked them all. In every case, either write() is called with a string, or the argument is passed unchanged from another function that contains the word "write()". As for code outside IDLE, I'd be extra surprised if anyone calls obj.write(x) with x being something other than a string. Ordinary file objects don't accept it. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 14:56 Message: Logged In: YES user_id=21627 Isn't this too simplistic? I guess there was a reason for the str call: could it ever happen that somebody passes something else (beyond byte and Unicode strings)? Also, I wonder whether IDLE patches need to go to idlefork (sf.net/projects/idlefork) first. Apart from this comments, I think your patch is quite right. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 From noreply@sourceforge.net Thu Feb 21 01:15:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 17:15:10 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: Jason Orendorff (jorend) Date: 2002-02-20 17:15 Message: Logged In: YES user_id=18139 > I don't like the Unicode part of it at all. Well, I'm not attatched to it. It's very easy to subtract it from the patch. > What can you do with this feature? The same sort of thing you might do with an array of type 'c'. For example, change individual characters of a (Unicode) string and then run a (Unicode) re.match on it. > It seems to unfairly prefer a specific Unicode encoding, > without explaining what that encoding is, and without a > clear use case why this encoding is desirable. Well, why should array('h', '\x00\xff\xaa\xbb') be allowed? Why is that encoding preferable to any other particular encoding of short ints? Easy: it's the encoding of the C compiler where Python was built. For 'u' arrays, the encoding used is just the encoding that Python uses internally. However, it's not intended to be used in any situation where encode()/decode() would be appropriate. I never even thought about that possibility when I wrote it. The behavior of a 'u' array is intended to be more like this: Suppose A = array('u', ustr). Then: len(A) == len(ustr) A[0] == ustr[0] A[1] == ustr[1] ... That is, a 'u' array is an array of Unicode characters. Encoding is not an issue, any more than with the built-in unicode type. (If ustr is a non-Unicode string, then the behavior is different -- more in line with what 'b', 'h', 'i', and the others do.) If your concern is that Python currently "hides" its internal encoding, and the 'u' array exposes this unnecessarily, then consider these two examples that don't involve arrays: >>> x = u'\U00012345' # One Unicode codepoint... >>> len(x) 2 # hmm. >>> x[0] u'\ud808' # aha. UTF-16. >>> x[1] u'\udf45' >>> str(buffer(u'abc')) # Example two. 'a\x00b\x00c\x00' > It also seems to overlap with the Unicode object's > .encode method, which is much more general. Wow. Well, that wasn't my intent. It is intended, rather, to offer parity with 'c'. Java has byte[], short[], int[], long[], float[], double[], and char[]... Python doesn't currently have char[]. Shouldn't it? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 15:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Thu Feb 21 02:00:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 18:00:37 -0800 Subject: [Patches] [ python-Patches-520768 ] cellobject isn't VAR Message-ID: Patches item #520768, was opened at 2002-02-20 18:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520768&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: cellobject isn't VAR Initial Comment: cellobject.h has: typedef struct { PyObject_VAR_HEAD PyObject *ob_ref; } PyCellObject; But it's wrong; it should just be plain PyObject_HEAD, not VAR_HEAD. (I tested this on Win32; it compiles and passes the tests. The ob_size field implied by VAR_HEAD just isn't used anywhere.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520768&group_id=5470 From noreply@sourceforge.net Thu Feb 21 02:03:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 18:03:57 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: Jason Orendorff (jorend) Date: 2002-02-20 18:03 Message: Logged In: YES user_id=18139 > What is the rationale for expanding PyObject_VAR_HEAD? > It doesn't seem to achieve anything. It didn't make sense for array to be a VAR_HEAD type. VAR_HEAD types are variable-size: the last member defined in the struct for such a type is an array of length 1, and type->item_size is nonzero. See e.g. PyType_GenericAlloc(), and how it decides whether to call PyObject_INIT or PyObject_VAR_INIT: It checks type->item_size. The new arraymodule.c calls PyType_GenericAlloc; the old one didn't. So a change seemed warranted. Since Arraytype has item_size == 0, it seemed most consistent to make it a non-VAR type and initialize the ob_size field myself. I'm pretty sure I got the right interpretation of this; but if not, someone wiser in the ways of Python will speak up. :) (While I was looking at this, I noticed this: http://sourceforge.net/tracker/index.php? func=detail&aid=520768&group_id=5470&atid=305470) ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 17:15 Message: Logged In: YES user_id=18139 > I don't like the Unicode part of it at all. Well, I'm not attatched to it. It's very easy to subtract it from the patch. > What can you do with this feature? The same sort of thing you might do with an array of type 'c'. For example, change individual characters of a (Unicode) string and then run a (Unicode) re.match on it. > It seems to unfairly prefer a specific Unicode encoding, > without explaining what that encoding is, and without a > clear use case why this encoding is desirable. Well, why should array('h', '\x00\xff\xaa\xbb') be allowed? Why is that encoding preferable to any other particular encoding of short ints? Easy: it's the encoding of the C compiler where Python was built. For 'u' arrays, the encoding used is just the encoding that Python uses internally. However, it's not intended to be used in any situation where encode()/decode() would be appropriate. I never even thought about that possibility when I wrote it. The behavior of a 'u' array is intended to be more like this: Suppose A = array('u', ustr). Then: len(A) == len(ustr) A[0] == ustr[0] A[1] == ustr[1] ... That is, a 'u' array is an array of Unicode characters. Encoding is not an issue, any more than with the built-in unicode type. (If ustr is a non-Unicode string, then the behavior is different -- more in line with what 'b', 'h', 'i', and the others do.) If your concern is that Python currently "hides" its internal encoding, and the 'u' array exposes this unnecessarily, then consider these two examples that don't involve arrays: >>> x = u'\U00012345' # One Unicode codepoint... >>> len(x) 2 # hmm. >>> x[0] u'\ud808' # aha. UTF-16. >>> x[1] u'\udf45' >>> str(buffer(u'abc')) # Example two. 'a\x00b\x00c\x00' > It also seems to overlap with the Unicode object's > .encode method, which is much more general. Wow. Well, that wasn't my intent. It is intended, rather, to offer parity with 'c'. Java has byte[], short[], int[], long[], float[], double[], and char[]... Python doesn't currently have char[]. Shouldn't it? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 15:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Thu Feb 21 02:04:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 20 Feb 2002 18:04:15 -0800 Subject: [Patches] [ python-Patches-520768 ] cellobject isn't VAR Message-ID: Patches item #520768, was opened at 2002-02-20 18:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520768&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: cellobject isn't VAR Initial Comment: cellobject.h has: typedef struct { PyObject_VAR_HEAD PyObject *ob_ref; } PyCellObject; But it's wrong; it should just be plain PyObject_HEAD, not VAR_HEAD. (I tested this on Win32; it compiles and passes the tests. The ob_size field implied by VAR_HEAD just isn't used anywhere.) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520768&group_id=5470 From noreply@sourceforge.net Thu Feb 21 08:40:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Feb 2002 00:40:55 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-21 00:40 Message: Logged In: YES user_id=38388 About the Unicode bit: if "u" maps to Py_UNICODE I for one don't have any objections. The internal encoding is available in lots of places, so that argument doesn't count and I'm sure it can be put to some good use for fast manipulation of large Unicode strings. I very much like the new exposure of the type at C level; however I don't understand how you would use it without adding the complete module to the libpythonx.x.a (unless you add some sort of inter-module C API import mechanism like the one I added to _socket and _ssl) ?! ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 18:03 Message: Logged In: YES user_id=18139 > What is the rationale for expanding PyObject_VAR_HEAD? > It doesn't seem to achieve anything. It didn't make sense for array to be a VAR_HEAD type. VAR_HEAD types are variable-size: the last member defined in the struct for such a type is an array of length 1, and type->item_size is nonzero. See e.g. PyType_GenericAlloc(), and how it decides whether to call PyObject_INIT or PyObject_VAR_INIT: It checks type->item_size. The new arraymodule.c calls PyType_GenericAlloc; the old one didn't. So a change seemed warranted. Since Arraytype has item_size == 0, it seemed most consistent to make it a non-VAR type and initialize the ob_size field myself. I'm pretty sure I got the right interpretation of this; but if not, someone wiser in the ways of Python will speak up. :) (While I was looking at this, I noticed this: http://sourceforge.net/tracker/index.php? func=detail&aid=520768&group_id=5470&atid=305470) ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 17:15 Message: Logged In: YES user_id=18139 > I don't like the Unicode part of it at all. Well, I'm not attatched to it. It's very easy to subtract it from the patch. > What can you do with this feature? The same sort of thing you might do with an array of type 'c'. For example, change individual characters of a (Unicode) string and then run a (Unicode) re.match on it. > It seems to unfairly prefer a specific Unicode encoding, > without explaining what that encoding is, and without a > clear use case why this encoding is desirable. Well, why should array('h', '\x00\xff\xaa\xbb') be allowed? Why is that encoding preferable to any other particular encoding of short ints? Easy: it's the encoding of the C compiler where Python was built. For 'u' arrays, the encoding used is just the encoding that Python uses internally. However, it's not intended to be used in any situation where encode()/decode() would be appropriate. I never even thought about that possibility when I wrote it. The behavior of a 'u' array is intended to be more like this: Suppose A = array('u', ustr). Then: len(A) == len(ustr) A[0] == ustr[0] A[1] == ustr[1] ... That is, a 'u' array is an array of Unicode characters. Encoding is not an issue, any more than with the built-in unicode type. (If ustr is a non-Unicode string, then the behavior is different -- more in line with what 'b', 'h', 'i', and the others do.) If your concern is that Python currently "hides" its internal encoding, and the 'u' array exposes this unnecessarily, then consider these two examples that don't involve arrays: >>> x = u'\U00012345' # One Unicode codepoint... >>> len(x) 2 # hmm. >>> x[0] u'\ud808' # aha. UTF-16. >>> x[1] u'\udf45' >>> str(buffer(u'abc')) # Example two. 'a\x00b\x00c\x00' > It also seems to overlap with the Unicode object's > .encode method, which is much more general. Wow. Well, that wasn't my intent. It is intended, rather, to offer parity with 'c'. Java has byte[], short[], int[], long[], float[], double[], and char[]... Python doesn't currently have char[]. Shouldn't it? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 15:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Thu Feb 21 23:41:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 21 Feb 2002 15:41:23 -0800 Subject: [Patches] [ python-Patches-520768 ] cellobject isn't VAR Message-ID: Patches item #520768, was opened at 2002-02-20 18:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520768&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 1 Submitted By: Jason Orendorff (jorend) >Assigned to: Jeremy Hylton (jhylton) Summary: cellobject isn't VAR Initial Comment: cellobject.h has: typedef struct { PyObject_VAR_HEAD PyObject *ob_ref; } PyCellObject; But it's wrong; it should just be plain PyObject_HEAD, not VAR_HEAD. (I tested this on Win32; it compiles and passes the tests. The ob_size field implied by VAR_HEAD just isn't used anywhere.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-21 15:41 Message: Logged In: YES user_id=6380 I agree. Assigned to Jeremy. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520768&group_id=5470 From Concept Marketing Group" Hello - I found your e-mail in a Canadian Directory and wanted to introduce our company. Concept Marketing Group Inc., located at www.marketingsource.com, is located in Scottsdale, Arizona (USA) and has been in business for 25 years. Our web site contains both free and paid marketing services. With over 650 pages we offer the following: Articles Library - contains links to hundreds of articles on both traditional and Internet marketing strategies and techniques. It is a comprehensive collection of tips and winning strategies written by successful business professionals. Directory of Associations - online subscription containing 5,000 associations with key contact information - a great networking tool! On-line business lists - immediate on line access to direct mailing lists, telemarketing lists and sales leads. Targeted Email Announcements - opt-in online direct marketing. We offer proven results. Opt-in means customers have given their consent and request to receive information about products and services from companies like yours. I'd like to invite you to visit us at www.marketingsource.com. Register and receive a free e-mail account, special discounts and offers from vendors on software and hardware products and more. Regards, Barbara Mullis Concept Marketing Group Inc. 800-575-5369 www.marketingsource.com -- To unsubscribe from: Concept Marketing Group, just follow this link: http://marketingsource.com/cgi-bin/mojo/mojo.cgi?f=u&l=Concept_Marketing_Group&e=patches@python.org&p=6442 Click the link, or copy and paste the address into your browser. From noreply@sourceforge.net Fri Feb 22 13:25:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Feb 2002 05:25:48 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open >Resolution: Accepted Priority: 3 Submitted By: Jason Orendorff (jorend) >Assigned to: Martin v. L�wis (loewis) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-22 05:25 Message: Logged In: YES user_id=21627 With the rationale given, I'm now in favour of all parts of the patch. As for exposing the API, you need to address MAL's concerns: PyArray_* won't be available to other extension modules, instead, you need to do expose them through a C object. However, I recommend *not* to follow the approach taken in socket/ssl; I agree with Tim's concerns here. Instead, the approach taken by cStringIO (via cStringIO.cStringIO_API) is much better (i.e. put the burden of using the API onto any importer, and out of Python proper). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-21 00:40 Message: Logged In: YES user_id=38388 About the Unicode bit: if "u" maps to Py_UNICODE I for one don't have any objections. The internal encoding is available in lots of places, so that argument doesn't count and I'm sure it can be put to some good use for fast manipulation of large Unicode strings. I very much like the new exposure of the type at C level; however I don't understand how you would use it without adding the complete module to the libpythonx.x.a (unless you add some sort of inter-module C API import mechanism like the one I added to _socket and _ssl) ?! ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 18:03 Message: Logged In: YES user_id=18139 > What is the rationale for expanding PyObject_VAR_HEAD? > It doesn't seem to achieve anything. It didn't make sense for array to be a VAR_HEAD type. VAR_HEAD types are variable-size: the last member defined in the struct for such a type is an array of length 1, and type->item_size is nonzero. See e.g. PyType_GenericAlloc(), and how it decides whether to call PyObject_INIT or PyObject_VAR_INIT: It checks type->item_size. The new arraymodule.c calls PyType_GenericAlloc; the old one didn't. So a change seemed warranted. Since Arraytype has item_size == 0, it seemed most consistent to make it a non-VAR type and initialize the ob_size field myself. I'm pretty sure I got the right interpretation of this; but if not, someone wiser in the ways of Python will speak up. :) (While I was looking at this, I noticed this: http://sourceforge.net/tracker/index.php? func=detail&aid=520768&group_id=5470&atid=305470) ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 17:15 Message: Logged In: YES user_id=18139 > I don't like the Unicode part of it at all. Well, I'm not attatched to it. It's very easy to subtract it from the patch. > What can you do with this feature? The same sort of thing you might do with an array of type 'c'. For example, change individual characters of a (Unicode) string and then run a (Unicode) re.match on it. > It seems to unfairly prefer a specific Unicode encoding, > without explaining what that encoding is, and without a > clear use case why this encoding is desirable. Well, why should array('h', '\x00\xff\xaa\xbb') be allowed? Why is that encoding preferable to any other particular encoding of short ints? Easy: it's the encoding of the C compiler where Python was built. For 'u' arrays, the encoding used is just the encoding that Python uses internally. However, it's not intended to be used in any situation where encode()/decode() would be appropriate. I never even thought about that possibility when I wrote it. The behavior of a 'u' array is intended to be more like this: Suppose A = array('u', ustr). Then: len(A) == len(ustr) A[0] == ustr[0] A[1] == ustr[1] ... That is, a 'u' array is an array of Unicode characters. Encoding is not an issue, any more than with the built-in unicode type. (If ustr is a non-Unicode string, then the behavior is different -- more in line with what 'b', 'h', 'i', and the others do.) If your concern is that Python currently "hides" its internal encoding, and the 'u' array exposes this unnecessarily, then consider these two examples that don't involve arrays: >>> x = u'\U00012345' # One Unicode codepoint... >>> len(x) 2 # hmm. >>> x[0] u'\ud808' # aha. UTF-16. >>> x[1] u'\udf45' >>> str(buffer(u'abc')) # Example two. 'a\x00b\x00c\x00' > It also seems to overlap with the Unicode object's > .encode method, which is much more general. Wow. Well, that wasn't my intent. It is intended, rather, to offer parity with 'c'. Java has byte[], short[], int[], long[], float[], double[], and char[]... Python doesn't currently have char[]. Shouldn't it? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 15:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Fri Feb 22 13:39:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Feb 2002 05:39:49 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Martin v. L�wis (loewis) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-22 05:39 Message: Logged In: YES user_id=38388 How about simplifying the whole setup altogether and add arrays as standard Python types (ie. put the code in Objects/ and add the new include file to Includes/). About the inter-module C API export: I'll write up a PEP about this which will hopefully result in a new standard support mechanism for this in Python. (BTW, the approach I used in _ssl/_socket does use PyCObjects) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-22 05:25 Message: Logged In: YES user_id=21627 With the rationale given, I'm now in favour of all parts of the patch. As for exposing the API, you need to address MAL's concerns: PyArray_* won't be available to other extension modules, instead, you need to do expose them through a C object. However, I recommend *not* to follow the approach taken in socket/ssl; I agree with Tim's concerns here. Instead, the approach taken by cStringIO (via cStringIO.cStringIO_API) is much better (i.e. put the burden of using the API onto any importer, and out of Python proper). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-21 00:40 Message: Logged In: YES user_id=38388 About the Unicode bit: if "u" maps to Py_UNICODE I for one don't have any objections. The internal encoding is available in lots of places, so that argument doesn't count and I'm sure it can be put to some good use for fast manipulation of large Unicode strings. I very much like the new exposure of the type at C level; however I don't understand how you would use it without adding the complete module to the libpythonx.x.a (unless you add some sort of inter-module C API import mechanism like the one I added to _socket and _ssl) ?! ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 18:03 Message: Logged In: YES user_id=18139 > What is the rationale for expanding PyObject_VAR_HEAD? > It doesn't seem to achieve anything. It didn't make sense for array to be a VAR_HEAD type. VAR_HEAD types are variable-size: the last member defined in the struct for such a type is an array of length 1, and type->item_size is nonzero. See e.g. PyType_GenericAlloc(), and how it decides whether to call PyObject_INIT or PyObject_VAR_INIT: It checks type->item_size. The new arraymodule.c calls PyType_GenericAlloc; the old one didn't. So a change seemed warranted. Since Arraytype has item_size == 0, it seemed most consistent to make it a non-VAR type and initialize the ob_size field myself. I'm pretty sure I got the right interpretation of this; but if not, someone wiser in the ways of Python will speak up. :) (While I was looking at this, I noticed this: http://sourceforge.net/tracker/index.php? func=detail&aid=520768&group_id=5470&atid=305470) ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 17:15 Message: Logged In: YES user_id=18139 > I don't like the Unicode part of it at all. Well, I'm not attatched to it. It's very easy to subtract it from the patch. > What can you do with this feature? The same sort of thing you might do with an array of type 'c'. For example, change individual characters of a (Unicode) string and then run a (Unicode) re.match on it. > It seems to unfairly prefer a specific Unicode encoding, > without explaining what that encoding is, and without a > clear use case why this encoding is desirable. Well, why should array('h', '\x00\xff\xaa\xbb') be allowed? Why is that encoding preferable to any other particular encoding of short ints? Easy: it's the encoding of the C compiler where Python was built. For 'u' arrays, the encoding used is just the encoding that Python uses internally. However, it's not intended to be used in any situation where encode()/decode() would be appropriate. I never even thought about that possibility when I wrote it. The behavior of a 'u' array is intended to be more like this: Suppose A = array('u', ustr). Then: len(A) == len(ustr) A[0] == ustr[0] A[1] == ustr[1] ... That is, a 'u' array is an array of Unicode characters. Encoding is not an issue, any more than with the built-in unicode type. (If ustr is a non-Unicode string, then the behavior is different -- more in line with what 'b', 'h', 'i', and the others do.) If your concern is that Python currently "hides" its internal encoding, and the 'u' array exposes this unnecessarily, then consider these two examples that don't involve arrays: >>> x = u'\U00012345' # One Unicode codepoint... >>> len(x) 2 # hmm. >>> x[0] u'\ud808' # aha. UTF-16. >>> x[1] u'\udf45' >>> str(buffer(u'abc')) # Example two. 'a\x00b\x00c\x00' > It also seems to overlap with the Unicode object's > .encode method, which is much more general. Wow. Well, that wasn't my intent. It is intended, rather, to offer parity with 'c'. Java has byte[], short[], int[], long[], float[], double[], and char[]... Python doesn't currently have char[]. Shouldn't it? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 15:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Fri Feb 22 14:54:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Feb 2002 06:54:55 -0800 Subject: [Patches] [ python-Patches-521478 ] mailbox / fromline matching Message-ID: Patches item #521478, was opened at 2002-02-22 06:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521478&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Camiel Dobbelaar (camield) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox / fromline matching Initial Comment: mailbox.py does not parse this 'From' line correctly: >From camield@sentia.nl Mon Apr 23 18:22:28 2001 +0200 ^^^^^ This is because of the trailing timezone information, that the regex does not account for. Also, 'From' should match at the beginning of the line. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521478&group_id=5470 From noreply@sourceforge.net Fri Feb 22 23:29:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Feb 2002 15:29:06 -0800 Subject: [Patches] [ python-Patches-521670 ] Remove unused sys import Message-ID: Patches item #521670, was opened at 2002-02-22 15:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521670&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: Remove unused sys import Initial Comment: curses/textpad.py imports sys, but doesn't use it. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521670&group_id=5470 From noreply@sourceforge.net Sat Feb 23 04:25:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 22 Feb 2002 20:25:54 -0800 Subject: [Patches] [ python-Patches-521714 ] fix pychecker warnings in ast.py Message-ID: Patches item #521714, was opened at 2002-02-22 20:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521714&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: fix pychecker warnings in ast.py Initial Comment: pychecker was complaining of "Local variable (nodes) shadows global defined on line 35". I've changed the names of those uses which were obviously local in scope to something more appropriate (nodearg where it is used as an argument, nodelist where it is a list). This does not clear up all of the instances of that pychecker warning in ast.py, but removes the vast majority of them. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521714&group_id=5470 From noreply@sourceforge.net Sat Feb 23 22:32:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 23 Feb 2002 14:32:21 -0800 Subject: [Patches] [ python-Patches-521670 ] Remove unused sys import Message-ID: Patches item #521670, was opened at 2002-02-22 15:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521670&group_id=5470 Category: Modules Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: Remove unused sys import Initial Comment: curses/textpad.py imports sys, but doesn't use it. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-23 14:32 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as textpad.py 1.7. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521670&group_id=5470 From noreply@sourceforge.net Sat Feb 23 22:36:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 23 Feb 2002 14:36:23 -0800 Subject: [Patches] [ python-Patches-521714 ] fix pychecker warnings in ast.py Message-ID: Patches item #521714, was opened at 2002-02-22 20:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521714&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: fix pychecker warnings in ast.py Initial Comment: pychecker was complaining of "Local variable (nodes) shadows global defined on line 35". I've changed the names of those uses which were obviously local in scope to something more appropriate (nodearg where it is used as an argument, nodelist where it is a list). This does not clear up all of the instances of that pychecker warning in ast.py, but removes the vast majority of them. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-23 14:36 Message: Logged In: YES user_id=21627 Tbanks, committed as ast.py 1.21. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521714&group_id=5470 From noreply@sourceforge.net Sat Feb 23 22:42:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 23 Feb 2002 14:42:31 -0800 Subject: [Patches] [ python-Patches-520483 ] Make IDLE OutputWindow handle Unicode Message-ID: Patches item #520483, was opened at 2002-02-20 06:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: Make IDLE OutputWindow handle Unicode Initial Comment: This one-line patch makes OutputWindow handle Unicode correctly. For example, >>> print u'\xbfQu\xe9 pas\xf3?' In 2.2 this throws a UnicodeError, not because of any problem with Unicode handling in either Python or Tk, but because IDLE does str(s) on the Unicode string. I just took out the call to str(). ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-23 14:42 Message: Logged In: YES user_id=21627 Ok, committed as OutputWindow 1.6. I strongly recommend to submit this to idlefork as well. If want this patch to appear in Python 2.2.1, you should get a comment from one of the major IDLE authors or contributors. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 15:27 Message: Logged In: YES user_id=18139 > Isn't this too simplistic? I guess there was a reason for > the str call: could it ever happen that somebody passes > something else (beyond byte and Unicode strings)? I searched for write() in the idle directory and got 48 hits in 7 files. Then I checked them all. In every case, either write() is called with a string, or the argument is passed unchanged from another function that contains the word "write()". As for code outside IDLE, I'd be extra surprised if anyone calls obj.write(x) with x being something other than a string. Ordinary file objects don't accept it. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 14:56 Message: Logged In: YES user_id=21627 Isn't this too simplistic? I guess there was a reason for the str call: could it ever happen that somebody passes something else (beyond byte and Unicode strings)? Also, I wonder whether IDLE patches need to go to idlefork (sf.net/projects/idlefork) first. Apart from this comments, I think your patch is quite right. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 From noreply@sourceforge.net Sun Feb 24 00:19:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 23 Feb 2002 16:19:11 -0800 Subject: [Patches] [ python-Patches-520483 ] Make IDLE OutputWindow handle Unicode Message-ID: Patches item #520483, was opened at 2002-02-20 06:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: Make IDLE OutputWindow handle Unicode Initial Comment: This one-line patch makes OutputWindow handle Unicode correctly. For example, >>> print u'\xbfQu\xe9 pas\xf3?' In 2.2 this throws a UnicodeError, not because of any problem with Unicode handling in either Python or Tk, but because IDLE does str(s) on the Unicode string. I just took out the call to str(). ---------------------------------------------------------------------- >Comment By: Jason Orendorff (jorend) Date: 2002-02-23 16:19 Message: Logged In: YES user_id=18139 Submitted to idlefork. I'm too shy to bother "one of the major IDLE authors." It would be nice to have in 2.2.1, but I know the folks at PythonLabs are busy... ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-23 14:42 Message: Logged In: YES user_id=21627 Ok, committed as OutputWindow 1.6. I strongly recommend to submit this to idlefork as well. If want this patch to appear in Python 2.2.1, you should get a comment from one of the major IDLE authors or contributors. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 15:27 Message: Logged In: YES user_id=18139 > Isn't this too simplistic? I guess there was a reason for > the str call: could it ever happen that somebody passes > something else (beyond byte and Unicode strings)? I searched for write() in the idle directory and got 48 hits in 7 files. Then I checked them all. In every case, either write() is called with a string, or the argument is passed unchanged from another function that contains the word "write()". As for code outside IDLE, I'd be extra surprised if anyone calls obj.write(x) with x being something other than a string. Ordinary file objects don't accept it. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 14:56 Message: Logged In: YES user_id=21627 Isn't this too simplistic? I guess there was a reason for the str call: could it ever happen that somebody passes something else (beyond byte and Unicode strings)? Also, I wonder whether IDLE patches need to go to idlefork (sf.net/projects/idlefork) first. Apart from this comments, I think your patch is quite right. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 From noreply@sourceforge.net Sun Feb 24 00:43:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 23 Feb 2002 16:43:44 -0800 Subject: [Patches] [ python-Patches-520483 ] Make IDLE OutputWindow handle Unicode Message-ID: Patches item #520483, was opened at 2002-02-20 06:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 >Category: IDLE >Group: Python 2.2.x >Status: Open Resolution: Accepted >Priority: 7 Submitted By: Jason Orendorff (jorend) >Assigned to: Guido van Rossum (gvanrossum) Summary: Make IDLE OutputWindow handle Unicode Initial Comment: This one-line patch makes OutputWindow handle Unicode correctly. For example, >>> print u'\xbfQu\xe9 pas\xf3?' In 2.2 this throws a UnicodeError, not because of any problem with Unicode handling in either Python or Tk, but because IDLE does str(s) on the Unicode string. I just took out the call to str(). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-02-23 16:43 Message: Logged In: YES user_id=31435 We're never too busy for people we love, Jason . Reopened, changed category to IDLE, changed group to Python 2.2.x, boosted priority, and assigned to Guido. The str() call has been there since Guido first checked this in, and its purpose isn't apparent to me either. Maybe Guido remembers. Guido? I'm not worried at all that someone might be calling it with a non-stringish argument -- it's supplying a "file- like object" interface, and .write() requires a stringish argument. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-23 16:19 Message: Logged In: YES user_id=18139 Submitted to idlefork. I'm too shy to bother "one of the major IDLE authors." It would be nice to have in 2.2.1, but I know the folks at PythonLabs are busy... ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-23 14:42 Message: Logged In: YES user_id=21627 Ok, committed as OutputWindow 1.6. I strongly recommend to submit this to idlefork as well. If want this patch to appear in Python 2.2.1, you should get a comment from one of the major IDLE authors or contributors. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 15:27 Message: Logged In: YES user_id=18139 > Isn't this too simplistic? I guess there was a reason for > the str call: could it ever happen that somebody passes > something else (beyond byte and Unicode strings)? I searched for write() in the idle directory and got 48 hits in 7 files. Then I checked them all. In every case, either write() is called with a string, or the argument is passed unchanged from another function that contains the word "write()". As for code outside IDLE, I'd be extra surprised if anyone calls obj.write(x) with x being something other than a string. Ordinary file objects don't accept it. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 14:56 Message: Logged In: YES user_id=21627 Isn't this too simplistic? I guess there was a reason for the str call: could it ever happen that somebody passes something else (beyond byte and Unicode strings)? Also, I wonder whether IDLE patches need to go to idlefork (sf.net/projects/idlefork) first. Apart from this comments, I think your patch is quite right. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 From noreply@sourceforge.net Sun Feb 24 05:46:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 23 Feb 2002 21:46:49 -0800 Subject: [Patches] [ python-Patches-450266 ] OS/2 + EMX port - library changes Message-ID: Patches item #450266, was opened at 2001-08-12 04:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450266&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: OS/2 + EMX port - library changes Initial Comment: The attached patch contains the changes to the Lib directory in the sourc tree between Python 2.1.1 and the 010812 release of the OS/2+EMX port. It also includes an additional directory - Etc - which is home to a couple of example passwd/group files. This directory can be dropped or relocated as appropriate. An additional subdirectory of Lib is added - plat-os2emx. The included os2path.py should probably be refactored into ntpath.py - suggestions/advice on this appreciated. A couple of small changes to Lib/test - test_fcntl.py and test_longexp.py - to handle OS/2+EMX specific issues. ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-02-23 21:46 Message: Logged In: YES user_id=250749 Committed. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2002-01-26 21:56 Message: Logged In: YES user_id=250749 The 3 patches submitted (Lib/, Lib/plat-os2emx/, Lib/test/) are against CVS of 27Jan02. The Lib patch implements the approach with os2emxpath.py discussed on python-dev. It also touches popen2.py to properly support the Win32 like popen[234]() support added to posixmodule.c. I'm not sure whether several of the files in plat-os2emx (IN.py, SOCKET.py) are still needed, but they don't appear to don any harm. The changes in the test suite are to cope with EMX platform issues: - unless you have lots of real memory, test_longexp is likely to take the system down (malloc() behaviour issue) - EMX's fcntl is only a partial implementation ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=450266&group_id=5470 From noreply@sourceforge.net Sun Feb 24 11:25:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Feb 2002 03:25:22 -0800 Subject: [Patches] [ python-Patches-522027 ] pwdmodule and grpmodule use structs Message-ID: Patches item #522027, was opened at 2002-02-24 03:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522027&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Quinn Dunkan (quinn_dunkan) Assigned to: Nobody/Anonymous (nobody) Summary: pwdmodule and grpmodule use structs Initial Comment: Here are a few patches to make pwd and grp use structs, like time.struct_time ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522027&group_id=5470 From noreply@sourceforge.net Sun Feb 24 15:56:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Feb 2002 07:56:28 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Martin v. L�wis (loewis) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-24 07:56 Message: Logged In: YES user_id=21627 There is a flaw in the extension of arrays to Unicode: There is no easy way to get back the Unicode string. You have to use u"".join(arr.tolist()) This is slightly annoying, since there is it is the only case where it is not possible to get back the original constructor arguments. Also, what is the rationale for removing __members__? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-22 05:39 Message: Logged In: YES user_id=38388 How about simplifying the whole setup altogether and add arrays as standard Python types (ie. put the code in Objects/ and add the new include file to Includes/). About the inter-module C API export: I'll write up a PEP about this which will hopefully result in a new standard support mechanism for this in Python. (BTW, the approach I used in _ssl/_socket does use PyCObjects) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-22 05:25 Message: Logged In: YES user_id=21627 With the rationale given, I'm now in favour of all parts of the patch. As for exposing the API, you need to address MAL's concerns: PyArray_* won't be available to other extension modules, instead, you need to do expose them through a C object. However, I recommend *not* to follow the approach taken in socket/ssl; I agree with Tim's concerns here. Instead, the approach taken by cStringIO (via cStringIO.cStringIO_API) is much better (i.e. put the burden of using the API onto any importer, and out of Python proper). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-21 00:40 Message: Logged In: YES user_id=38388 About the Unicode bit: if "u" maps to Py_UNICODE I for one don't have any objections. The internal encoding is available in lots of places, so that argument doesn't count and I'm sure it can be put to some good use for fast manipulation of large Unicode strings. I very much like the new exposure of the type at C level; however I don't understand how you would use it without adding the complete module to the libpythonx.x.a (unless you add some sort of inter-module C API import mechanism like the one I added to _socket and _ssl) ?! ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 18:03 Message: Logged In: YES user_id=18139 > What is the rationale for expanding PyObject_VAR_HEAD? > It doesn't seem to achieve anything. It didn't make sense for array to be a VAR_HEAD type. VAR_HEAD types are variable-size: the last member defined in the struct for such a type is an array of length 1, and type->item_size is nonzero. See e.g. PyType_GenericAlloc(), and how it decides whether to call PyObject_INIT or PyObject_VAR_INIT: It checks type->item_size. The new arraymodule.c calls PyType_GenericAlloc; the old one didn't. So a change seemed warranted. Since Arraytype has item_size == 0, it seemed most consistent to make it a non-VAR type and initialize the ob_size field myself. I'm pretty sure I got the right interpretation of this; but if not, someone wiser in the ways of Python will speak up. :) (While I was looking at this, I noticed this: http://sourceforge.net/tracker/index.php? func=detail&aid=520768&group_id=5470&atid=305470) ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 17:15 Message: Logged In: YES user_id=18139 > I don't like the Unicode part of it at all. Well, I'm not attatched to it. It's very easy to subtract it from the patch. > What can you do with this feature? The same sort of thing you might do with an array of type 'c'. For example, change individual characters of a (Unicode) string and then run a (Unicode) re.match on it. > It seems to unfairly prefer a specific Unicode encoding, > without explaining what that encoding is, and without a > clear use case why this encoding is desirable. Well, why should array('h', '\x00\xff\xaa\xbb') be allowed? Why is that encoding preferable to any other particular encoding of short ints? Easy: it's the encoding of the C compiler where Python was built. For 'u' arrays, the encoding used is just the encoding that Python uses internally. However, it's not intended to be used in any situation where encode()/decode() would be appropriate. I never even thought about that possibility when I wrote it. The behavior of a 'u' array is intended to be more like this: Suppose A = array('u', ustr). Then: len(A) == len(ustr) A[0] == ustr[0] A[1] == ustr[1] ... That is, a 'u' array is an array of Unicode characters. Encoding is not an issue, any more than with the built-in unicode type. (If ustr is a non-Unicode string, then the behavior is different -- more in line with what 'b', 'h', 'i', and the others do.) If your concern is that Python currently "hides" its internal encoding, and the 'u' array exposes this unnecessarily, then consider these two examples that don't involve arrays: >>> x = u'\U00012345' # One Unicode codepoint... >>> len(x) 2 # hmm. >>> x[0] u'\ud808' # aha. UTF-16. >>> x[1] u'\udf45' >>> str(buffer(u'abc')) # Example two. 'a\x00b\x00c\x00' > It also seems to overlap with the Unicode object's > .encode method, which is much more general. Wow. Well, that wasn't my intent. It is intended, rather, to offer parity with 'c'. Java has byte[], short[], int[], long[], float[], double[], and char[]... Python doesn't currently have char[]. Shouldn't it? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 15:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Sun Feb 24 16:05:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Feb 2002 08:05:48 -0800 Subject: [Patches] [ python-Patches-510825 ] PTHREAD_SCOPE_SYSTEM support for HP-UX Message-ID: Patches item #510825, was opened at 2002-01-30 10:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=510825&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: PTHREAD_SCOPE_SYSTEM support for HP-UX Initial Comment: PTHREAD_SCOPE_SYSTEM is supported as an argument to pthread_attr_setscope() on HP-UX 11.00. However, it is not detected successfully because HP-UX returns EINVAL if the first argument to pthread_create is NULL. Patch attached against Python 2.2. Will work for 2.1.2 as well. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-24 08:05 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as configure.in 1.292, configure 1.283. ---------------------------------------------------------------------- Comment By: The Written Word (Albert Chin) (tww-china) Date: 2002-01-30 10:16 Message: Logged In: YES user_id=119770 Oops, forgot to attach patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=510825&group_id=5470 From noreply@sourceforge.net Sun Feb 24 16:07:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Feb 2002 08:07:03 -0800 Subject: [Patches] [ python-Patches-513329 ] build, install in HP-UX10.20 Message-ID: Patches item #513329, was opened at 2002-02-05 07:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513329&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Claudio Scafuri (scafuri) Assigned to: Nobody/Anonymous (nobody) Summary: build, install in HP-UX10.20 Initial Comment: a) python must be linked with c++ because at least one file is compiled with c++. b) in hpux "install -d" does not create a directory. Use "mkdir instead. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-24 08:07 Message: Logged In: YES user_id=21627 If there isn't any further feedback by March 1, this report will be closed. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-12 17:25 Message: Logged In: YES user_id=21627 There is already code in configure[.in] that tests whether using c++ to link is needed (it isn't needed on all systems). Please report why this test fails on HP-UX, and try providing a patch that corrects the test. The relevant code is after the comment # If CXX is set, and if it is needed to link a main function that was # compiled with CXX, LINKCC is CXX instead. Also, please contribute changes as unified or context diffs; see the Python SourceForge usage guidelines for details. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=513329&group_id=5470 From noreply@sourceforge.net Sun Feb 24 18:25:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Feb 2002 10:25:11 -0800 Subject: [Patches] [ python-Patches-415227 ] Solaris pkgtool bdist command Message-ID: Patches item #415227, was opened at 2001-04-10 12:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415227&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Alexander (mwa) Assigned to: M.-A. Lemburg (lemburg) Summary: Solaris pkgtool bdist command Initial Comment: The bdist_pktool command is based on bdist_packager and provides support for the Solaris pkgadd and pkgrm commands. In most cases, no additional options beyond the PEP 241 options are required. An exception is if the package name is >9 characters, a --pkg-abrev option is required because that's all pkgtool will handle. It makes listing the packages on the system a pain, but the actual package files produced do match name-version-revision-pyvers.pkg format. By default, bdist_pkgtool provides request, postinstall, preremove, and postremove scripts that will properly relocate modules to the site-packages directory and recompile all .py modules on the target machine. An author can provide a custom request script and either have it auto-relocate by merging the scripts, or inhibit auto-relocation with --no-autorelocate. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-24 10:25 Message: Logged In: YES user_id=38388 The code looks OK, but I can't test it... I'm sure the user base will, though, once it's in CVS. Please also write up some documentation which we can add to the distutils TeX docs and add them to the patch. I will then add it to CVS. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-20 06:00 Message: Logged In: YES user_id=38388 Hijacking this patch to take load off of Andrew. This patch should be reviewed after the Python 2.2 feature freeze. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2001-06-06 22:39 Message: Logged In: YES user_id=21627 Should there also be some Makefile machinery to create a Solaris package for python itself? There is a 1.6a2 package on sunfreeware; it would surely help if building Solaris packages was supported by the Python core itself. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415227&group_id=5470 From noreply@sourceforge.net Sun Feb 24 18:27:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Feb 2002 10:27:14 -0800 Subject: [Patches] [ python-Patches-415228 ] HP-UX packaging command Message-ID: Patches item #415228, was opened at 2001-04-10 12:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415228&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Alexander (mwa) Assigned to: M.-A. Lemburg (lemburg) Summary: HP-UX packaging command Initial Comment: The bdist_sdux (SD-UX is HP's packager) command is based on bdist_packager and provides the same functionality as the bdist_pkgtool command, except the resulting packages cannot auto-relocate. Instead, a checkinstall script is included by default that determines of the target machines python installation matches that of the creating machine. If not, it bails out and provides the installer with the correct version of the swinstall command to place it in the proper directory. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-24 10:27 Message: Logged In: YES user_id=38388 The code looks OK, but I can't test it... I'm sure the user base will, though, once it's in CVS. Please also write up some documentation which we can add to the distutils TeX docs and add them to the patch. I will then add it to CVS. Thanks. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-11-20 06:01 Message: Logged In: YES user_id=38388 Hijacking this patch to take load off of Andrew. This patch should be reviewed after the Python 2.2 feature freeze. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:18 Message: Logged In: YES user_id=6380 Please select the proper category when submitting patches! This is clearly a distutils thing. Assigned to Andrew. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415228&group_id=5470 From noreply@sourceforge.net Sun Feb 24 21:38:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Feb 2002 13:38:52 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Martin v. L�wis (loewis) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-02-24 13:38 Message: Logged In: YES user_id=31435 Without looking at any details, __members__ and __methods__ are deprecated starting with 2.2; the type/class unification PEPs aim at moving the universe toward supporting and using the class-like introspection API instead. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-24 07:56 Message: Logged In: YES user_id=21627 There is a flaw in the extension of arrays to Unicode: There is no easy way to get back the Unicode string. You have to use u"".join(arr.tolist()) This is slightly annoying, since there is it is the only case where it is not possible to get back the original constructor arguments. Also, what is the rationale for removing __members__? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-22 05:39 Message: Logged In: YES user_id=38388 How about simplifying the whole setup altogether and add arrays as standard Python types (ie. put the code in Objects/ and add the new include file to Includes/). About the inter-module C API export: I'll write up a PEP about this which will hopefully result in a new standard support mechanism for this in Python. (BTW, the approach I used in _ssl/_socket does use PyCObjects) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-22 05:25 Message: Logged In: YES user_id=21627 With the rationale given, I'm now in favour of all parts of the patch. As for exposing the API, you need to address MAL's concerns: PyArray_* won't be available to other extension modules, instead, you need to do expose them through a C object. However, I recommend *not* to follow the approach taken in socket/ssl; I agree with Tim's concerns here. Instead, the approach taken by cStringIO (via cStringIO.cStringIO_API) is much better (i.e. put the burden of using the API onto any importer, and out of Python proper). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-21 00:40 Message: Logged In: YES user_id=38388 About the Unicode bit: if "u" maps to Py_UNICODE I for one don't have any objections. The internal encoding is available in lots of places, so that argument doesn't count and I'm sure it can be put to some good use for fast manipulation of large Unicode strings. I very much like the new exposure of the type at C level; however I don't understand how you would use it without adding the complete module to the libpythonx.x.a (unless you add some sort of inter-module C API import mechanism like the one I added to _socket and _ssl) ?! ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 18:03 Message: Logged In: YES user_id=18139 > What is the rationale for expanding PyObject_VAR_HEAD? > It doesn't seem to achieve anything. It didn't make sense for array to be a VAR_HEAD type. VAR_HEAD types are variable-size: the last member defined in the struct for such a type is an array of length 1, and type->item_size is nonzero. See e.g. PyType_GenericAlloc(), and how it decides whether to call PyObject_INIT or PyObject_VAR_INIT: It checks type->item_size. The new arraymodule.c calls PyType_GenericAlloc; the old one didn't. So a change seemed warranted. Since Arraytype has item_size == 0, it seemed most consistent to make it a non-VAR type and initialize the ob_size field myself. I'm pretty sure I got the right interpretation of this; but if not, someone wiser in the ways of Python will speak up. :) (While I was looking at this, I noticed this: http://sourceforge.net/tracker/index.php? func=detail&aid=520768&group_id=5470&atid=305470) ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 17:15 Message: Logged In: YES user_id=18139 > I don't like the Unicode part of it at all. Well, I'm not attatched to it. It's very easy to subtract it from the patch. > What can you do with this feature? The same sort of thing you might do with an array of type 'c'. For example, change individual characters of a (Unicode) string and then run a (Unicode) re.match on it. > It seems to unfairly prefer a specific Unicode encoding, > without explaining what that encoding is, and without a > clear use case why this encoding is desirable. Well, why should array('h', '\x00\xff\xaa\xbb') be allowed? Why is that encoding preferable to any other particular encoding of short ints? Easy: it's the encoding of the C compiler where Python was built. For 'u' arrays, the encoding used is just the encoding that Python uses internally. However, it's not intended to be used in any situation where encode()/decode() would be appropriate. I never even thought about that possibility when I wrote it. The behavior of a 'u' array is intended to be more like this: Suppose A = array('u', ustr). Then: len(A) == len(ustr) A[0] == ustr[0] A[1] == ustr[1] ... That is, a 'u' array is an array of Unicode characters. Encoding is not an issue, any more than with the built-in unicode type. (If ustr is a non-Unicode string, then the behavior is different -- more in line with what 'b', 'h', 'i', and the others do.) If your concern is that Python currently "hides" its internal encoding, and the 'u' array exposes this unnecessarily, then consider these two examples that don't involve arrays: >>> x = u'\U00012345' # One Unicode codepoint... >>> len(x) 2 # hmm. >>> x[0] u'\ud808' # aha. UTF-16. >>> x[1] u'\udf45' >>> str(buffer(u'abc')) # Example two. 'a\x00b\x00c\x00' > It also seems to overlap with the Unicode object's > .encode method, which is much more general. Wow. Well, that wasn't my intent. It is intended, rather, to offer parity with 'c'. Java has byte[], short[], int[], long[], float[], double[], and char[]... Python doesn't currently have char[]. Shouldn't it? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 15:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Mon Feb 25 00:29:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Feb 2002 16:29:46 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Martin v. L�wis (loewis) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: Jason Orendorff (jorend) Date: 2002-02-24 16:29 Message: Logged In: YES user_id=18139 Martin writes: "There is a flaw in the extension of arrays to Unicode: There is no easy way to get back the Unicode string." Boy, are you right. There should be array.tounicode() and array.fromunicode() methods that only work on type 'u' arrays. ...I also want to fix repr for type 'u' arrays. Instead of "array.array('u', [u'x', u'y', u'z'])" it should say "array.array('u', u'xyz')". ...I would also implement __iadd__ and __imul__ (as list implements them), but this would be a semantic change! Thoughts? Count on a new patch tomorrow. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-24 13:38 Message: Logged In: YES user_id=31435 Without looking at any details, __members__ and __methods__ are deprecated starting with 2.2; the type/class unification PEPs aim at moving the universe toward supporting and using the class-like introspection API instead. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-24 07:56 Message: Logged In: YES user_id=21627 There is a flaw in the extension of arrays to Unicode: There is no easy way to get back the Unicode string. You have to use u"".join(arr.tolist()) This is slightly annoying, since there is it is the only case where it is not possible to get back the original constructor arguments. Also, what is the rationale for removing __members__? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-22 05:39 Message: Logged In: YES user_id=38388 How about simplifying the whole setup altogether and add arrays as standard Python types (ie. put the code in Objects/ and add the new include file to Includes/). About the inter-module C API export: I'll write up a PEP about this which will hopefully result in a new standard support mechanism for this in Python. (BTW, the approach I used in _ssl/_socket does use PyCObjects) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-22 05:25 Message: Logged In: YES user_id=21627 With the rationale given, I'm now in favour of all parts of the patch. As for exposing the API, you need to address MAL's concerns: PyArray_* won't be available to other extension modules, instead, you need to do expose them through a C object. However, I recommend *not* to follow the approach taken in socket/ssl; I agree with Tim's concerns here. Instead, the approach taken by cStringIO (via cStringIO.cStringIO_API) is much better (i.e. put the burden of using the API onto any importer, and out of Python proper). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-21 00:40 Message: Logged In: YES user_id=38388 About the Unicode bit: if "u" maps to Py_UNICODE I for one don't have any objections. The internal encoding is available in lots of places, so that argument doesn't count and I'm sure it can be put to some good use for fast manipulation of large Unicode strings. I very much like the new exposure of the type at C level; however I don't understand how you would use it without adding the complete module to the libpythonx.x.a (unless you add some sort of inter-module C API import mechanism like the one I added to _socket and _ssl) ?! ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 18:03 Message: Logged In: YES user_id=18139 > What is the rationale for expanding PyObject_VAR_HEAD? > It doesn't seem to achieve anything. It didn't make sense for array to be a VAR_HEAD type. VAR_HEAD types are variable-size: the last member defined in the struct for such a type is an array of length 1, and type->item_size is nonzero. See e.g. PyType_GenericAlloc(), and how it decides whether to call PyObject_INIT or PyObject_VAR_INIT: It checks type->item_size. The new arraymodule.c calls PyType_GenericAlloc; the old one didn't. So a change seemed warranted. Since Arraytype has item_size == 0, it seemed most consistent to make it a non-VAR type and initialize the ob_size field myself. I'm pretty sure I got the right interpretation of this; but if not, someone wiser in the ways of Python will speak up. :) (While I was looking at this, I noticed this: http://sourceforge.net/tracker/index.php? func=detail&aid=520768&group_id=5470&atid=305470) ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 17:15 Message: Logged In: YES user_id=18139 > I don't like the Unicode part of it at all. Well, I'm not attatched to it. It's very easy to subtract it from the patch. > What can you do with this feature? The same sort of thing you might do with an array of type 'c'. For example, change individual characters of a (Unicode) string and then run a (Unicode) re.match on it. > It seems to unfairly prefer a specific Unicode encoding, > without explaining what that encoding is, and without a > clear use case why this encoding is desirable. Well, why should array('h', '\x00\xff\xaa\xbb') be allowed? Why is that encoding preferable to any other particular encoding of short ints? Easy: it's the encoding of the C compiler where Python was built. For 'u' arrays, the encoding used is just the encoding that Python uses internally. However, it's not intended to be used in any situation where encode()/decode() would be appropriate. I never even thought about that possibility when I wrote it. The behavior of a 'u' array is intended to be more like this: Suppose A = array('u', ustr). Then: len(A) == len(ustr) A[0] == ustr[0] A[1] == ustr[1] ... That is, a 'u' array is an array of Unicode characters. Encoding is not an issue, any more than with the built-in unicode type. (If ustr is a non-Unicode string, then the behavior is different -- more in line with what 'b', 'h', 'i', and the others do.) If your concern is that Python currently "hides" its internal encoding, and the 'u' array exposes this unnecessarily, then consider these two examples that don't involve arrays: >>> x = u'\U00012345' # One Unicode codepoint... >>> len(x) 2 # hmm. >>> x[0] u'\ud808' # aha. UTF-16. >>> x[1] u'\udf45' >>> str(buffer(u'abc')) # Example two. 'a\x00b\x00c\x00' > It also seems to overlap with the Unicode object's > .encode method, which is much more general. Wow. Well, that wasn't my intent. It is intended, rather, to offer parity with 'c'. Java has byte[], short[], int[], long[], float[], double[], and char[]... Python doesn't currently have char[]. Shouldn't it? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 15:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Mon Feb 25 02:07:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 24 Feb 2002 18:07:53 -0800 Subject: [Patches] [ python-Patches-522279 ] transformer.py nodes shadows global Message-ID: Patches item #522279, was opened at 2002-02-24 18:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522279&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: transformer.py nodes shadows global Initial Comment: pychecker complains: transformer.py:295: Local variable (nodes) shadows global defined on line 0 transformer.py:297: Local variable (nodes) shadows global defined on line 0 transformer.py:298: Local variable (nodes) shadows global defined on line 0 I renamed nodes to nodesl (because nodelist was in scope). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522279&group_id=5470 From noreply@sourceforge.net Mon Feb 25 12:24:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Feb 2002 04:24:21 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Martin v. L�wis (loewis) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-25 04:24 Message: Logged In: YES user_id=21627 Removal of __members__ is fine, then - but you do need to fill out an appropriate tp_members instead, listing "typecode" and "itemsize". Adding __iadd__ and __imul__ is fine; the equivalent feature for lists has not caused complaints, either, and anybody using *= on an array probably would consider it a bug that it isn't in-place. Please add documentation changes as well; I currently have Doc/lib/libarray.tex \lineiii{'d'}{double}{8} +\lineiii{'u'}{Py_UNICODE}{2} \end{tableiii} Misc/NEWS - array.array is now a type object. A new format character 'u' indicates Py_UNICODE arrays. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-24 16:29 Message: Logged In: YES user_id=18139 Martin writes: "There is a flaw in the extension of arrays to Unicode: There is no easy way to get back the Unicode string." Boy, are you right. There should be array.tounicode() and array.fromunicode() methods that only work on type 'u' arrays. ...I also want to fix repr for type 'u' arrays. Instead of "array.array('u', [u'x', u'y', u'z'])" it should say "array.array('u', u'xyz')". ...I would also implement __iadd__ and __imul__ (as list implements them), but this would be a semantic change! Thoughts? Count on a new patch tomorrow. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-24 13:38 Message: Logged In: YES user_id=31435 Without looking at any details, __members__ and __methods__ are deprecated starting with 2.2; the type/class unification PEPs aim at moving the universe toward supporting and using the class-like introspection API instead. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-24 07:56 Message: Logged In: YES user_id=21627 There is a flaw in the extension of arrays to Unicode: There is no easy way to get back the Unicode string. You have to use u"".join(arr.tolist()) This is slightly annoying, since there is it is the only case where it is not possible to get back the original constructor arguments. Also, what is the rationale for removing __members__? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-22 05:39 Message: Logged In: YES user_id=38388 How about simplifying the whole setup altogether and add arrays as standard Python types (ie. put the code in Objects/ and add the new include file to Includes/). About the inter-module C API export: I'll write up a PEP about this which will hopefully result in a new standard support mechanism for this in Python. (BTW, the approach I used in _ssl/_socket does use PyCObjects) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-22 05:25 Message: Logged In: YES user_id=21627 With the rationale given, I'm now in favour of all parts of the patch. As for exposing the API, you need to address MAL's concerns: PyArray_* won't be available to other extension modules, instead, you need to do expose them through a C object. However, I recommend *not* to follow the approach taken in socket/ssl; I agree with Tim's concerns here. Instead, the approach taken by cStringIO (via cStringIO.cStringIO_API) is much better (i.e. put the burden of using the API onto any importer, and out of Python proper). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-21 00:40 Message: Logged In: YES user_id=38388 About the Unicode bit: if "u" maps to Py_UNICODE I for one don't have any objections. The internal encoding is available in lots of places, so that argument doesn't count and I'm sure it can be put to some good use for fast manipulation of large Unicode strings. I very much like the new exposure of the type at C level; however I don't understand how you would use it without adding the complete module to the libpythonx.x.a (unless you add some sort of inter-module C API import mechanism like the one I added to _socket and _ssl) ?! ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 18:03 Message: Logged In: YES user_id=18139 > What is the rationale for expanding PyObject_VAR_HEAD? > It doesn't seem to achieve anything. It didn't make sense for array to be a VAR_HEAD type. VAR_HEAD types are variable-size: the last member defined in the struct for such a type is an array of length 1, and type->item_size is nonzero. See e.g. PyType_GenericAlloc(), and how it decides whether to call PyObject_INIT or PyObject_VAR_INIT: It checks type->item_size. The new arraymodule.c calls PyType_GenericAlloc; the old one didn't. So a change seemed warranted. Since Arraytype has item_size == 0, it seemed most consistent to make it a non-VAR type and initialize the ob_size field myself. I'm pretty sure I got the right interpretation of this; but if not, someone wiser in the ways of Python will speak up. :) (While I was looking at this, I noticed this: http://sourceforge.net/tracker/index.php? func=detail&aid=520768&group_id=5470&atid=305470) ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 17:15 Message: Logged In: YES user_id=18139 > I don't like the Unicode part of it at all. Well, I'm not attatched to it. It's very easy to subtract it from the patch. > What can you do with this feature? The same sort of thing you might do with an array of type 'c'. For example, change individual characters of a (Unicode) string and then run a (Unicode) re.match on it. > It seems to unfairly prefer a specific Unicode encoding, > without explaining what that encoding is, and without a > clear use case why this encoding is desirable. Well, why should array('h', '\x00\xff\xaa\xbb') be allowed? Why is that encoding preferable to any other particular encoding of short ints? Easy: it's the encoding of the C compiler where Python was built. For 'u' arrays, the encoding used is just the encoding that Python uses internally. However, it's not intended to be used in any situation where encode()/decode() would be appropriate. I never even thought about that possibility when I wrote it. The behavior of a 'u' array is intended to be more like this: Suppose A = array('u', ustr). Then: len(A) == len(ustr) A[0] == ustr[0] A[1] == ustr[1] ... That is, a 'u' array is an array of Unicode characters. Encoding is not an issue, any more than with the built-in unicode type. (If ustr is a non-Unicode string, then the behavior is different -- more in line with what 'b', 'h', 'i', and the others do.) If your concern is that Python currently "hides" its internal encoding, and the 'u' array exposes this unnecessarily, then consider these two examples that don't involve arrays: >>> x = u'\U00012345' # One Unicode codepoint... >>> len(x) 2 # hmm. >>> x[0] u'\ud808' # aha. UTF-16. >>> x[1] u'\udf45' >>> str(buffer(u'abc')) # Example two. 'a\x00b\x00c\x00' > It also seems to overlap with the Unicode object's > .encode method, which is much more general. Wow. Well, that wasn't my intent. It is intended, rather, to offer parity with 'c'. Java has byte[], short[], int[], long[], float[], double[], and char[]... Python doesn't currently have char[]. Shouldn't it? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 15:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Mon Feb 25 18:50:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Feb 2002 10:50:12 -0800 Subject: [Patches] [ python-Patches-522587 ] Fixes pydoc http/ftp URL matching Message-ID: Patches item #522587, was opened at 2002-02-25 10:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522587&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes pydoc http/ftp URL matching Initial Comment: The current URL matching pattern used by pydoc only excludes whitespace. My patch also excludes the following characters: ' & " - excludes the quotes in: < & > - As stated in RFC-1738: """The characters "<" and ">" are unsafe because they are used as the delimiters around URLs in free text""" We don't want to include the delimeters as part of the URL. And including unescaped "<" in an attribute value is not legal markup. Also, remove the word boundary requirement for http/ftp URIs because otherwise the "/" would not be included in the following URL: "http://www.python.org/" Attached is the patch and some simple test code. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522587&group_id=5470 From esijang@hotmail.com Mon Feb 25 19:02:34 2002 From: esijang@hotmail.com (esijang) Date: Tue, 26 Feb 2002 04:02:34 +0900 Subject: [Patches] ●●하룻밤 자고 나면 피로가 쫘~악~!![광고] Message-ID: 하룻밤 자고나면 피로가 쫘~악!!

 잠든 동안이라는 일본 말이며 일본 (유한회사) 라이프21사의 나가다 사장이 남편의 암을 치료차 브라질에 가서 아가리쿠스 버섯을 이용하여 치료한 것을 계기로 일본의 민간요법인 목초액 사용법과 접목, 발전시켜 쓰기 간편하게 아가리쿠스 버섯, 유카리 수액, 전분을 특별한 제조법으로 분말화하여 한지로 가공한 화제의 수액시트로 습포제처럼 발바닥이나 아픈 곳에 붙이면 나무뿌리가 수분을 빨아올리는 것처럼 발바닥으로부터 몸 속의 노폐물을 뽑아내어 신기하게 몸이 가뿐하고 상쾌해집니다.
즉, 파스의 형태로 부황과 고약의 역할을 하는 것입니다.
좀더 간단히 말하면 모양은 파스의 형태지만 기능은 몸속의 노폐물을 강력하게 빨아내는 부황과 고약을 합친 것과 같다고 할 수 있습니다.

즉, 파스처럼 간편히 부착하고 발바닥에 붙여 몸 속의 노폐물을 빨아내는 것입니다.

부모님과 어르신들께 이보다 좋은 선물은 없을것입니다.   지금 바로 신청하세요.



    원치않는 메일로 불편을 드렸다면 고개숙여 사과 드립니다.
    저희는 귀하의 전자우편 주소 외 어떠한 개인정보도 가지고 있지 않으므로 안심하시기 바랍니다.
   이메일 수신을 원치 않으시면 "이메일주소를 적으신후 수신거부하기를 클릭"해주세요
   이메일 :
   불편을 드려 죄송합니다.

    네.떼.루.마.니(시장넷) 주문·상담 080-365-8589(080-365일-바로팔구)
From noreply@sourceforge.net Mon Feb 25 20:16:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 25 Feb 2002 12:16:21 -0800 Subject: [Patches] [ python-Patches-522621 ] Leak in thread_nt.h Message-ID: Patches item #522621, was opened at 2002-02-25 12:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522621&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Leak in thread_nt.h Initial Comment: Leaks are created in thread_nt.h when you create and destroy threads. Specifically, entries are made into a local (static) "threads" dictionary when a thread is created, but are never removed (in fact, the reference counts are apparently being incremented twice when the entries are added). In fact, the dictionary is never actually used at all otherwise and appears to be an artifact of an earlier version of this file. The provided patch comments out references to the dictionary and associated helper objects and appears to work just fine. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522621&group_id=5470 From noreply@sourceforge.net Tue Feb 26 13:59:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Feb 2002 05:59:58 -0800 Subject: [Patches] [ python-Patches-522961 ] Leak in Python/thread_nt.h Message-ID: Patches item #522961, was opened at 2002-02-26 05:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522961&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Leak in Python/thread_nt.h Initial Comment: I submitted this into the bug tracker as [ #522621 ] Leak in thread_nt.h, although was advised to convert it into a proper patch request... The NT threading module creates a dictionary to keep track of thread handles but never uses it. It doesn't maintain it properly, creating leaks. This patch removes the dictionary entirely. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522961&group_id=5470 From noreply@sourceforge.net Tue Feb 26 22:28:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Feb 2002 14:28:50 -0800 Subject: [Patches] [ python-Patches-523169 ] tests for simple list() and tuple(TUPLE) Message-ID: Patches item #523169, was opened at 2002-02-26 14:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523169&group_id=5470 Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Nobody/Anonymous (nobody) Summary: tests for simple list() and tuple(TUPLE) Initial Comment: Strange as it may seem, the test suite has never explicitely checked for the basic behavior of list(seq), here is a patch with tests for that (to go in Lib/test/test_b1.py) in particular it tests that list(LIST) is not LIST PLUS a changed test for tuple, checking that tuple(TUPLE) is TUPLE (to go in Lib/test/test_b2.py) Enjoy, Samuele Pedroni. ---------------------------------------------------------------------- >Comment By: Samuele Pedroni (pedronis) Date: 2002-02-26 14:28 Message: Logged In: YES user_id=61408 test_b2.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523169&group_id=5470 From noreply@sourceforge.net Tue Feb 26 22:27:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Feb 2002 14:27:06 -0800 Subject: [Patches] [ python-Patches-523169 ] tests for simple list() and tuple(TUPLE) Message-ID: Patches item #523169, was opened at 2002-02-26 14:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523169&group_id=5470 Category: Tests Group: None Status: Open Resolution: None Priority: 5 Submitted By: Samuele Pedroni (pedronis) Assigned to: Nobody/Anonymous (nobody) Summary: tests for simple list() and tuple(TUPLE) Initial Comment: Strange as it may seem, the test suite has never explicitely checked for the basic behavior of list(seq), here is a patch with tests for that (to go in Lib/test/test_b1.py) in particular it tests that list(LIST) is not LIST PLUS a changed test for tuple, checking that tuple(TUPLE) is TUPLE (to go in Lib/test/test_b2.py) Enjoy, Samuele Pedroni. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523169&group_id=5470 From noreply@sourceforge.net Tue Feb 26 22:39:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Feb 2002 14:39:49 -0800 Subject: [Patches] [ python-Patches-523169 ] tests for simple list() and tuple(TUPLE) Message-ID: Patches item #523169, was opened at 2002-02-26 14:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523169&group_id=5470 Category: Tests Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Samuele Pedroni (pedronis) >Assigned to: Guido van Rossum (gvanrossum) Summary: tests for simple list() and tuple(TUPLE) Initial Comment: Strange as it may seem, the test suite has never explicitely checked for the basic behavior of list(seq), here is a patch with tests for that (to go in Lib/test/test_b1.py) in particular it tests that list(LIST) is not LIST PLUS a changed test for tuple, checking that tuple(TUPLE) is TUPLE (to go in Lib/test/test_b2.py) Enjoy, Samuele Pedroni. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-26 14:39 Message: Logged In: YES user_id=6380 Thanks! Applied. ---------------------------------------------------------------------- Comment By: Samuele Pedroni (pedronis) Date: 2002-02-26 14:28 Message: Logged In: YES user_id=61408 test_b2.patch ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523169&group_id=5470 From noreply@sourceforge.net Wed Feb 27 02:33:45 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Feb 2002 18:33:45 -0800 Subject: [Patches] [ python-Patches-523241 ] MimeWriter must use CRLF instead of LF Message-ID: Patches item #523241, was opened at 2002-02-26 18:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523241&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Clarence Gardner (cgardner) Assigned to: Nobody/Anonymous (nobody) Summary: MimeWriter must use CRLF instead of LF Initial Comment: In all of the output that MimeWriter does (headers and boundaries), a CRLF must be written rather than just LF. (CRLF at the end of the header, and at the beginning and end of the boundaries.) Here's hoping I'm doing this right :) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523241&group_id=5470 From noreply@sourceforge.net Wed Feb 27 03:15:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Feb 2002 19:15:49 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 14:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Martin v. L�wis (loewis) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: Jason Orendorff (jorend) Date: 2002-02-26 19:15 Message: Logged In: YES user_id=18139 Getting there. This version has tounicode() and fromunicode(), and a better repr() for type 'u' arrays. Also, array.typecode and array.itemsize are now listed under tp_getset; they're attribute descriptors and they show up in help(array). (Neat!) Next, documentation; then __iadd__ and __imul__. But not tonight. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-25 04:24 Message: Logged In: YES user_id=21627 Removal of __members__ is fine, then - but you do need to fill out an appropriate tp_members instead, listing "typecode" and "itemsize". Adding __iadd__ and __imul__ is fine; the equivalent feature for lists has not caused complaints, either, and anybody using *= on an array probably would consider it a bug that it isn't in-place. Please add documentation changes as well; I currently have Doc/lib/libarray.tex \lineiii{'d'}{double}{8} +\lineiii{'u'}{Py_UNICODE}{2} \end{tableiii} Misc/NEWS - array.array is now a type object. A new format character 'u' indicates Py_UNICODE arrays. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-24 16:29 Message: Logged In: YES user_id=18139 Martin writes: "There is a flaw in the extension of arrays to Unicode: There is no easy way to get back the Unicode string." Boy, are you right. There should be array.tounicode() and array.fromunicode() methods that only work on type 'u' arrays. ...I also want to fix repr for type 'u' arrays. Instead of "array.array('u', [u'x', u'y', u'z'])" it should say "array.array('u', u'xyz')". ...I would also implement __iadd__ and __imul__ (as list implements them), but this would be a semantic change! Thoughts? Count on a new patch tomorrow. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-24 13:38 Message: Logged In: YES user_id=31435 Without looking at any details, __members__ and __methods__ are deprecated starting with 2.2; the type/class unification PEPs aim at moving the universe toward supporting and using the class-like introspection API instead. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-24 07:56 Message: Logged In: YES user_id=21627 There is a flaw in the extension of arrays to Unicode: There is no easy way to get back the Unicode string. You have to use u"".join(arr.tolist()) This is slightly annoying, since there is it is the only case where it is not possible to get back the original constructor arguments. Also, what is the rationale for removing __members__? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-22 05:39 Message: Logged In: YES user_id=38388 How about simplifying the whole setup altogether and add arrays as standard Python types (ie. put the code in Objects/ and add the new include file to Includes/). About the inter-module C API export: I'll write up a PEP about this which will hopefully result in a new standard support mechanism for this in Python. (BTW, the approach I used in _ssl/_socket does use PyCObjects) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-22 05:25 Message: Logged In: YES user_id=21627 With the rationale given, I'm now in favour of all parts of the patch. As for exposing the API, you need to address MAL's concerns: PyArray_* won't be available to other extension modules, instead, you need to do expose them through a C object. However, I recommend *not* to follow the approach taken in socket/ssl; I agree with Tim's concerns here. Instead, the approach taken by cStringIO (via cStringIO.cStringIO_API) is much better (i.e. put the burden of using the API onto any importer, and out of Python proper). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-21 00:40 Message: Logged In: YES user_id=38388 About the Unicode bit: if "u" maps to Py_UNICODE I for one don't have any objections. The internal encoding is available in lots of places, so that argument doesn't count and I'm sure it can be put to some good use for fast manipulation of large Unicode strings. I very much like the new exposure of the type at C level; however I don't understand how you would use it without adding the complete module to the libpythonx.x.a (unless you add some sort of inter-module C API import mechanism like the one I added to _socket and _ssl) ?! ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 18:03 Message: Logged In: YES user_id=18139 > What is the rationale for expanding PyObject_VAR_HEAD? > It doesn't seem to achieve anything. It didn't make sense for array to be a VAR_HEAD type. VAR_HEAD types are variable-size: the last member defined in the struct for such a type is an array of length 1, and type->item_size is nonzero. See e.g. PyType_GenericAlloc(), and how it decides whether to call PyObject_INIT or PyObject_VAR_INIT: It checks type->item_size. The new arraymodule.c calls PyType_GenericAlloc; the old one didn't. So a change seemed warranted. Since Arraytype has item_size == 0, it seemed most consistent to make it a non-VAR type and initialize the ob_size field myself. I'm pretty sure I got the right interpretation of this; but if not, someone wiser in the ways of Python will speak up. :) (While I was looking at this, I noticed this: http://sourceforge.net/tracker/index.php? func=detail&aid=520768&group_id=5470&atid=305470) ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 17:15 Message: Logged In: YES user_id=18139 > I don't like the Unicode part of it at all. Well, I'm not attatched to it. It's very easy to subtract it from the patch. > What can you do with this feature? The same sort of thing you might do with an array of type 'c'. For example, change individual characters of a (Unicode) string and then run a (Unicode) re.match on it. > It seems to unfairly prefer a specific Unicode encoding, > without explaining what that encoding is, and without a > clear use case why this encoding is desirable. Well, why should array('h', '\x00\xff\xaa\xbb') be allowed? Why is that encoding preferable to any other particular encoding of short ints? Easy: it's the encoding of the C compiler where Python was built. For 'u' arrays, the encoding used is just the encoding that Python uses internally. However, it's not intended to be used in any situation where encode()/decode() would be appropriate. I never even thought about that possibility when I wrote it. The behavior of a 'u' array is intended to be more like this: Suppose A = array('u', ustr). Then: len(A) == len(ustr) A[0] == ustr[0] A[1] == ustr[1] ... That is, a 'u' array is an array of Unicode characters. Encoding is not an issue, any more than with the built-in unicode type. (If ustr is a non-Unicode string, then the behavior is different -- more in line with what 'b', 'h', 'i', and the others do.) If your concern is that Python currently "hides" its internal encoding, and the 'u' array exposes this unnecessarily, then consider these two examples that don't involve arrays: >>> x = u'\U00012345' # One Unicode codepoint... >>> len(x) 2 # hmm. >>> x[0] u'\ud808' # aha. UTF-16. >>> x[1] u'\udf45' >>> str(buffer(u'abc')) # Example two. 'a\x00b\x00c\x00' > It also seems to overlap with the Unicode object's > .encode method, which is much more general. Wow. Well, that wasn't my intent. It is intended, rather, to offer parity with 'c'. Java has byte[], short[], int[], long[], float[], double[], and char[]... Python doesn't currently have char[]. Shouldn't it? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 15:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Wed Feb 27 05:10:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Feb 2002 21:10:41 -0800 Subject: [Patches] [ python-Patches-523268 ] pwd.getpw* returns enhanced tuple. Message-ID: Patches item #523268, was opened at 2002-02-26 21:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523268&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: pwd.getpw* returns enhanced tuple. Initial Comment: This patch against the current CVS implements the enhanced tuple return types for pwd.getpw*(). This makes the return similar to time.localtime() and os.stat(). Includes changes to the documents as well. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523268&group_id=5470 From noreply@sourceforge.net Wed Feb 27 05:32:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 26 Feb 2002 21:32:34 -0800 Subject: [Patches] [ python-Patches-523271 ] Docstrings for os.stat and time.localtim Message-ID: Patches item #523271, was opened at 2002-02-26 21:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523271&group_id=5470 Category: Documentation Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Docstrings for os.stat and time.localtim Initial Comment: This patch updates the first line of the docstrings for os.stat(), os.lstat(), and time.*time() so that it reflects the attribute names on the tuple-like struct object returned. It changes: localtime(...) localtime([seconds]) -> (year,month,day,hour,minute,second,weekday,dayofyear ,dst) into: gmtime([seconds]) -> (tm_year,tm_mon,tm_day,tm_hour,tm_min,tm_sec,tm_wday,tm_yday,tm_isdst) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523271&group_id=5470 From noreply@sourceforge.net Wed Feb 27 14:53:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Feb 2002 06:53:43 -0800 Subject: [Patches] [ python-Patches-523415 ] Explict proxies for urllib.urlopen() Message-ID: Patches item #523415, was opened at 2002-02-27 06:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523415&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Andy Gimblett (gimbo) Assigned to: Nobody/Anonymous (nobody) Summary: Explict proxies for urllib.urlopen() Initial Comment: This patch extends urllib.urlopen() so that proxies may be specified explicitly. This is achieved by adding an optional "proxies" parameter. If this parameter is omitted, urlopen() acts exactly as before, ie gets proxy settings from the environment. This is useful if you want to tell urlopen() not to use the proxy: just pass an empty dictionary. Also included is a patch to the urllib documentation explaining the new parameter. Apologies if patch format is not exactly as required: this is my first submission. All feedback appreciated. :-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523415&group_id=5470 From noreply@sourceforge.net Wed Feb 27 15:03:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Feb 2002 07:03:17 -0800 Subject: [Patches] [ python-Patches-523424 ] Finding "home" in "user.py" for Windows Message-ID: Patches item #523424, was opened at 2002-02-27 07:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523424&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gilles Lenfant (glenfant) Assigned to: Nobody/Anonymous (nobody) Summary: Finding "home" in "user.py" for Windows Initial Comment: On my win2k French box + python 2.1.2: >>> import user >>> user.home 'C:\' This isn't a great issue but this means that all users of this win2k box will share the same ".pythonrc.py". The code provided by Jeff Bauer can be changed easily because the standard Python distro now has a "_winreg" module. This patch gives the real user $HOME like folder for any user on whatever's Windows localization: >>> import user >>> user.home u'C:\Documents and Settings\MyWindowsUsername\Mes documents' This has been successfully tested with Win98 and Win2000. This should be tested on XP, NT4, and 95 but I can't. Sorry for the "context or unified diffs" (dunno what it means) but the module is short and my patch is clearly emphasized. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523424&group_id=5470 From noreply@sourceforge.net Wed Feb 27 22:13:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Feb 2002 14:13:49 -0800 Subject: [Patches] [ python-Patches-523424 ] Finding "home" in "user.py" for Windows Message-ID: Patches item #523424, was opened at 2002-02-27 07:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523424&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gilles Lenfant (glenfant) Assigned to: Nobody/Anonymous (nobody) >Summary: Finding "home" in "user.py" for Windows Initial Comment: On my win2k French box + python 2.1.2: >>> import user >>> user.home 'C:\' This isn't a great issue but this means that all users of this win2k box will share the same ".pythonrc.py". The code provided by Jeff Bauer can be changed easily because the standard Python distro now has a "_winreg" module. This patch gives the real user $HOME like folder for any user on whatever's Windows localization: >>> import user >>> user.home u'C:\Documents and Settings\MyWindowsUsername\Mes documents' This has been successfully tested with Win98 and Win2000. This should be tested on XP, NT4, and 95 but I can't. Sorry for the "context or unified diffs" (dunno what it means) but the module is short and my patch is clearly emphasized. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-27 14:13 Message: Logged In: YES user_id=21627 If it returns "My Documents", it is definitely *not* the home directory of the user; \Documents and Settings\username would be the home directory. Furthermore, on many installations, HOME *is* set, and it is the Administrator's choice where that points to; the typical installation (in a domain) indeed is to assign HOMEDRIVE. So I'm not in favour of that change. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523424&group_id=5470 From noreply@sourceforge.net Wed Feb 27 22:20:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Feb 2002 14:20:56 -0800 Subject: [Patches] [ python-Patches-522027 ] pwdmodule and grpmodule use structs Message-ID: Patches item #522027, was opened at 2002-02-24 03:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522027&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Quinn Dunkan (quinn_dunkan) Assigned to: Nobody/Anonymous (nobody) Summary: pwdmodule and grpmodule use structs Initial Comment: Here are a few patches to make pwd and grp use structs, like time.struct_time ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-27 14:20 Message: Logged In: YES user_id=21627 For the pwd part, please coordinate with Sean Reifschneider and patch #523268. I like the documentation changes in that patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522027&group_id=5470 From noreply@sourceforge.net Wed Feb 27 22:21:04 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Feb 2002 14:21:04 -0800 Subject: [Patches] [ python-Patches-523268 ] pwd.getpw* returns enhanced tuple. Message-ID: Patches item #523268, was opened at 2002-02-26 21:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523268&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: pwd.getpw* returns enhanced tuple. Initial Comment: This patch against the current CVS implements the enhanced tuple return types for pwd.getpw*(). This makes the return similar to time.localtime() and os.stat(). Includes changes to the documents as well. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-27 14:21 Message: Logged In: YES user_id=21627 Please coordinate with Quinn Dunkan (patch #522027). It seems his patch fills out some character strings where you use NULL. Ideally, you'd both come up with a revised version of the patch, and withdraw the other one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523268&group_id=5470 From noreply@sourceforge.net Wed Feb 27 22:22:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 27 Feb 2002 14:22:36 -0800 Subject: [Patches] [ python-Patches-522621 ] Leak in thread_nt.h Message-ID: Patches item #522621, was opened at 2002-02-25 12:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522621&group_id=5470 Category: Core (C code) Group: Python 2.2.x >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Leak in thread_nt.h Initial Comment: Leaks are created in thread_nt.h when you create and destroy threads. Specifically, entries are made into a local (static) "threads" dictionary when a thread is created, but are never removed (in fact, the reference counts are apparently being incremented twice when the entries are added). In fact, the dictionary is never actually used at all otherwise and appears to be an artifact of an earlier version of this file. The provided patch comments out references to the dictionary and associated helper objects and appears to work just fine. ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-27 14:22 Message: Logged In: YES user_id=21627 Duplicate of #522961 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522621&group_id=5470 From customer_service@childcareprograms.com Wed Feb 27 23:56:40 2002 From: customer_service@childcareprograms.com (customer_service@childcareprograms.com) Date: Wed, 27 Feb 2002 23:56:40 Subject: [Patches] (no subject) Message-ID: PM200011:56:40 PM This is an HTML email message. If you see this, your mail client does not support HTML messages. ------=_NextPart_OKPMSYHARL Content-Type: text/html;charset="iso-8859-1" Content-Transfer-Encoding: 7bit ChildcarePrograms Home Page

           

| Full/Part Time Program | Weekends Program | Go Out Club | Vacation Club | Summer Program | Gold Membership |

Log In.jpg (1493 bytes)

http://www.childcareprograms.com/BABY16.GIF (6379 bytes)

http://www.childcareprograms.com/Button_Registration_1.jpg (1813 bytes)

http://www.childcareprograms.com/Button_Programs_4.jpg (1722 bytes)

http://www.childcareprograms.com/Button_Pratners_3.jpg (1785 bytes)

http://www.childcareprograms.com/Button_Contact_2.jpg (1751 bytes)

http://www.childcareprograms.com/Button_Payment_1.jpg (1810 bytes)

 

  

WHAT IS THIS SITE ABOUT?

HOW TO FIND CHILDCARE PROGRAM APPROPRIATE TO YOU USING THIS SITE

Are you tired looking for mature reliable babysitter? You can’t find someone to leave your children with when you go out? You don’t know what to do with your schoolchild, when summer camp is over but school doesn’t start yet? You are not alone. There are plenty of people having the same problems and living close to you!

Our purpose is to help these people.

The first in the line of our service products is a Whole/Part Day Program. The basic version of the program is for 5 working mothers to provide day care to 5 kids 1 day per week, in their own house. There are variations of this program for a particular case. First, there may be different numbers of participants: from 2 to 5. There may be variations in the place of the childcare: change house for each mother every day or use only one (2, 3 or 4) house(s) as agreed with other participants ...... (see whole text)

� 1996-2000, People2People Technology, Inc.

 

Full/Part Time Program

Weekends Program

Go Out Club

Vacation Club

Summer Program

Gold Membership

To be removed from this mailing list, please click on this link: http://www.childcareprograms.com/unsubscribe.htm
You must use your exact address in the box to ensure
you will be unsubscribed.

------=_NextPart_OKPMSYHARL-- From noreply@sourceforge.net Thu Feb 28 09:20:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 01:20:53 -0800 Subject: [Patches] [ python-Patches-523268 ] pwd.getpw* returns enhanced tuple. Message-ID: Patches item #523268, was opened at 2002-02-27 05:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523268&group_id=5470 Category: Modules Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: pwd.getpw* returns enhanced tuple. Initial Comment: This patch against the current CVS implements the enhanced tuple return types for pwd.getpw*(). This makes the return similar to time.localtime() and os.stat(). Includes changes to the documents as well. ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2002-02-28 09:20 Message: Logged In: YES user_id=81797 I've taken a look at Quinn's patch, and have created a new version which I believe is the combination of the two. It also includes doc strings for the structs themselves, documentation of the grp module, and removes a case where a failure can cause a memory leak. I'll ask Quinn to review this patch. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-27 22:21 Message: Logged In: YES user_id=21627 Please coordinate with Quinn Dunkan (patch #522027). It seems his patch fills out some character strings where you use NULL. Ideally, you'd both come up with a revised version of the patch, and withdraw the other one. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523268&group_id=5470 From noreply@sourceforge.net Thu Feb 28 09:22:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 01:22:47 -0800 Subject: [Patches] [ python-Patches-522027 ] pwdmodule and grpmodule use structs Message-ID: Patches item #522027, was opened at 2002-02-24 11:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522027&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Quinn Dunkan (quinn_dunkan) Assigned to: Nobody/Anonymous (nobody) Summary: pwdmodule and grpmodule use structs Initial Comment: Here are a few patches to make pwd and grp use structs, like time.struct_time ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-02-28 09:22 Message: Logged In: YES user_id=81797 I have created a new patch which is the union of our two patches, plus a bit. Please review it and if you have any comments let me know. Thanks, Sean ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-27 22:20 Message: Logged In: YES user_id=21627 For the pwd part, please coordinate with Sean Reifschneider and patch #523268. I like the documentation changes in that patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522027&group_id=5470 From noreply@sourceforge.net Thu Feb 28 15:19:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 07:19:39 -0800 Subject: [Patches] [ python-Patches-522961 ] Leak in Python/thread_nt.h Message-ID: Patches item #522961, was opened at 2002-02-26 13:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522961&group_id=5470 Category: Core (C code) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Nobody/Anonymous (nobody) Summary: Leak in Python/thread_nt.h Initial Comment: I submitted this into the bug tracker as [ #522621 ] Leak in thread_nt.h, although was advised to convert it into a proper patch request... The NT threading module creates a dictionary to keep track of thread handles but never uses it. It doesn't maintain it properly, creating leaks. This patch removes the dictionary entirely. ---------------------------------------------------------------------- >Comment By: Gerald S. Williams (gsw_agere) Date: 2002-02-28 15:19 Message: Logged In: YES user_id=329402 Note that this change removes dependencies from the PyThread code, which is a stated goal of that module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522961&group_id=5470 From noreply@sourceforge.net Thu Feb 28 15:35:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 07:35:47 -0800 Subject: [Patches] [ python-Patches-522279 ] transformer.py nodes shadows global Message-ID: Patches item #522279, was opened at 2002-02-25 03:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522279&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: transformer.py nodes shadows global Initial Comment: pychecker complains: transformer.py:295: Local variable (nodes) shadows global defined on line 0 transformer.py:297: Local variable (nodes) shadows global defined on line 0 transformer.py:298: Local variable (nodes) shadows global defined on line 0 I renamed nodes to nodesl (because nodelist was in scope). ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-28 16:35 Message: Logged In: YES user_id=21627 I fail to see the global that is being shadowed. Any clues? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522279&group_id=5470 From noreply@sourceforge.net Thu Feb 28 16:11:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 08:11:22 -0800 Subject: [Patches] [ python-Patches-522279 ] transformer.py nodes shadows global Message-ID: Patches item #522279, was opened at 2002-02-24 19:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522279&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: transformer.py nodes shadows global Initial Comment: pychecker complains: transformer.py:295: Local variable (nodes) shadows global defined on line 0 transformer.py:297: Local variable (nodes) shadows global defined on line 0 transformer.py:298: Local variable (nodes) shadows global defined on line 0 I renamed nodes to nodesl (because nodelist was in scope). ---------------------------------------------------------------------- >Comment By: Evelyn Mitchell (efm) Date: 2002-02-28 09:11 Message: Logged In: YES user_id=13263 I'm guessing it's picking up the one from ast.py from ast import * (at line 25 of transformer) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-28 08:35 Message: Logged In: YES user_id=21627 I fail to see the global that is being shadowed. Any clues? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522279&group_id=5470 From noreply@sourceforge.net Thu Feb 28 17:17:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 09:17:58 -0800 Subject: [Patches] [ python-Patches-523944 ] imputil.py can't import "\r\n" .py files Message-ID: Patches item #523944, was opened at 2002-02-28 10:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523944&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nobody/Anonymous (nobody) Summary: imputil.py can't import "\r\n" .py files Initial Comment: __builtin__.compile() requires that codestring line endings consist of "\n". imputil._compile() does not enforce this. One result is that imputil may be unable to import modules created on Win32. The attached patch to the latest (CVS revision 1.23) imputil.py replaces both "\r\n" and "\r" with "\n" before passing a code string to __builtin__.compile(). This is consistent with the behavior of e.g. Lib/py_compile.py. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523944&group_id=5470 From noreply@sourceforge.net Thu Feb 28 17:49:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 09:49:20 -0800 Subject: [Patches] [ python-Patches-522279 ] transformer.py nodes shadows global Message-ID: Patches item #522279, was opened at 2002-02-25 03:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522279&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: transformer.py nodes shadows global Initial Comment: pychecker complains: transformer.py:295: Local variable (nodes) shadows global defined on line 0 transformer.py:297: Local variable (nodes) shadows global defined on line 0 transformer.py:298: Local variable (nodes) shadows global defined on line 0 I renamed nodes to nodesl (because nodelist was in scope). ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-28 18:49 Message: Logged In: YES user_id=21627 Thanks, applied as transformer.py 1.32. ---------------------------------------------------------------------- Comment By: Evelyn Mitchell (efm) Date: 2002-02-28 17:11 Message: Logged In: YES user_id=13263 I'm guessing it's picking up the one from ast.py from ast import * (at line 25 of transformer) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-28 16:35 Message: Logged In: YES user_id=21627 I fail to see the global that is being shadowed. Any clues? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522279&group_id=5470 From noreply@sourceforge.net Thu Feb 28 18:08:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 10:08:50 -0800 Subject: [Patches] [ python-Patches-522279 ] transformer.py nodes shadows global Message-ID: Patches item #522279, was opened at 2002-02-25 03:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522279&group_id=5470 Category: Parser/Compiler Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Evelyn Mitchell (efm) Assigned to: Nobody/Anonymous (nobody) Summary: transformer.py nodes shadows global Initial Comment: pychecker complains: transformer.py:295: Local variable (nodes) shadows global defined on line 0 transformer.py:297: Local variable (nodes) shadows global defined on line 0 transformer.py:298: Local variable (nodes) shadows global defined on line 0 I renamed nodes to nodesl (because nodelist was in scope). ---------------------------------------------------------------------- >Comment By: Martin v. L�wis (loewis) Date: 2002-02-28 19:08 Message: Logged In: YES user_id=21627 Thanks, applied as transformer.py 1.32. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-28 18:49 Message: Logged In: YES user_id=21627 Thanks, applied as transformer.py 1.32. ---------------------------------------------------------------------- Comment By: Evelyn Mitchell (efm) Date: 2002-02-28 17:11 Message: Logged In: YES user_id=13263 I'm guessing it's picking up the one from ast.py from ast import * (at line 25 of transformer) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-28 16:35 Message: Logged In: YES user_id=21627 I fail to see the global that is being shadowed. Any clues? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522279&group_id=5470 From noreply@sourceforge.net Thu Feb 28 19:22:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 11:22:11 -0800 Subject: [Patches] [ python-Patches-524005 ] "make tags" fails on new POSIX hosts Message-ID: Patches item #524005, was opened at 2002-02-28 19:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=524005&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Paul Eggert (eggert) Assigned to: Nobody/Anonymous (nobody) Summary: "make tags" fails on new POSIX hosts Initial Comment: The new POSIX standard is now official (IEEE Std 1003.1-2001), and it has removed support for the obsolescent syntax "sort foo -o foo". You are now supposed to use "sort -o foo foo" instead. As a result of this change, I can't run "make tags" on my Solaris 8 host if I am using GNU textutils 2.0.21 and have defined _POSIX2_VERSION=200112 and POSIXLY_CORRECT=true in my environment. Here is a patch, relative to Python 2.2. 2002-02-28 Paul Eggert * Makefile.pre.in (tags): Use "sort -o tags tags", since POSIX 1003.1-2001 no longer allows "sort tags -o tags". =================================================================== RCS file: RCS/Makefile.pre.in,v retrieving revision 2.2 retrieving revision 2.2.0.1 diff -pu -r2.2 -r2.2.0.1 --- Makefile.pre.in 2001/12/19 09:24:40 2.2 +++ Makefile.pre.in 2002/02/28 19:02:54 2.2.0.1 @@ -827,7 +827,7 @@ tags:: ctags -w -t Include/*.h; \ for i in $(SRCDIRS); do ctags -w -t -a $$i/*.[ch]; \ done; \ - sort tags -o tags + sort -o tags tags # Create a tags file for GNU Emacs TAGS:: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=524005&group_id=5470 From noreply@sourceforge.net Thu Feb 28 19:26:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 11:26:37 -0800 Subject: [Patches] [ python-Patches-524005 ] "make tags" fails on new POSIX hosts Message-ID: Patches item #524005, was opened at 2002-02-28 14:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=524005&group_id=5470 Category: Build Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Paul Eggert (eggert) >Assigned to: Guido van Rossum (gvanrossum) >Summary: "make tags" fails on new POSIX hosts Initial Comment: The new POSIX standard is now official (IEEE Std 1003.1-2001), and it has removed support for the obsolescent syntax "sort foo -o foo". You are now supposed to use "sort -o foo foo" instead. As a result of this change, I can't run "make tags" on my Solaris 8 host if I am using GNU textutils 2.0.21 and have defined _POSIX2_VERSION=200112 and POSIXLY_CORRECT=true in my environment. Here is a patch, relative to Python 2.2. 2002-02-28 Paul Eggert * Makefile.pre.in (tags): Use "sort -o tags tags", since POSIX 1003.1-2001 no longer allows "sort tags -o tags". =================================================================== RCS file: RCS/Makefile.pre.in,v retrieving revision 2.2 retrieving revision 2.2.0.1 diff -pu -r2.2 -r2.2.0.1 --- Makefile.pre.in 2001/12/19 09:24:40 2.2 +++ Makefile.pre.in 2002/02/28 19:02:54 2.2.0.1 @@ -827,7 +827,7 @@ tags:: ctags -w -t Include/*.h; \ for i in $(SRCDIRS); do ctags -w -t -a $$i/*.[ch]; \ done; \ - sort tags -o tags + sort -o tags tags # Create a tags file for GNU Emacs TAGS:: ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 14:26 Message: Logged In: YES user_id=6380 Thanks! Fixed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=524005&group_id=5470 From noreply@sourceforge.net Thu Feb 28 19:28:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 11:28:35 -0800 Subject: [Patches] [ python-Patches-524008 ] pysvr portability bug on new POSIX hosts Message-ID: Patches item #524008, was opened at 2002-02-28 19:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=524008&group_id=5470 Category: Demos and tools Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Paul Eggert (eggert) Assigned to: Nobody/Anonymous (nobody) Summary: pysvr portability bug on new POSIX hosts Initial Comment: The new POSIX standard is now official (IEEE Std 1003.1-2001), and it has removed support for the obsolescent syntax "tail +2l". You are now supposed to use "tail -n +2" instead. As a result of this change, the pysvr demo fails on my Solaris 8 host if I am using GNU textutils 2.0.21 and have defined _POSIX2_VERSION=200112 and POSIXLY_CORRECT=true in my environment. Here is a patch, relative to Python 2.2. 2002-02-28 Paul Eggert * Demo/pysvr/pysvr.c (ps): Don't use "tail +2l", as POSIX 1003.1-2001 no longer allows this. Use "sed 1d" instead, as it's more portable. =================================================================== RCS file: Demo/pysvr/pysvr.c,v retrieving revision 2.2 retrieving revision 2.2.0.1 diff -pu -r2.2 -r2.2.0.1 --- Demo/pysvr/pysvr.c 2001/11/28 20:27:42 2.2 +++ Demo/pysvr/pysvr.c 2002/02/28 19:02:54 2.2.0.1 @@ -365,6 +365,6 @@ ps(void) { char buffer[100]; PyOS_snprintf(buffer, sizeof(buffer), - "ps -l -p %d Patches item #522961, was opened at 2002-02-26 08:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522961&group_id=5470 >Category: Windows Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) >Assigned to: Tim Peters (tim_one) Summary: Leak in Python/thread_nt.h Initial Comment: I submitted this into the bug tracker as [ #522621 ] Leak in thread_nt.h, although was advised to convert it into a proper patch request... The NT threading module creates a dictionary to keep track of thread handles but never uses it. It doesn't maintain it properly, creating leaks. This patch removes the dictionary entirely. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-02-28 16:13 Message: Logged In: YES user_id=31435 Changed Category to Windows, assigned to me. Gerald, there are two patches attached, uploaded within two minutes of each other. Which one do you like better? ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-02-28 10:19 Message: Logged In: YES user_id=329402 Note that this change removes dependencies from the PyThread code, which is a stated goal of that module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522961&group_id=5470 From noreply@sourceforge.net Thu Feb 28 21:30:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 13:30:32 -0800 Subject: [Patches] [ python-Patches-522961 ] Leak in Python/thread_nt.h Message-ID: Patches item #522961, was opened at 2002-02-26 08:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522961&group_id=5470 Category: Windows Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Tim Peters (tim_one) Summary: Leak in Python/thread_nt.h Initial Comment: I submitted this into the bug tracker as [ #522621 ] Leak in thread_nt.h, although was advised to convert it into a proper patch request... The NT threading module creates a dictionary to keep track of thread handles but never uses it. It doesn't maintain it properly, creating leaks. This patch removes the dictionary entirely. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-02-28 16:30 Message: Logged In: YES user_id=31435 Deleted the older patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-28 16:13 Message: Logged In: YES user_id=31435 Changed Category to Windows, assigned to me. Gerald, there are two patches attached, uploaded within two minutes of each other. Which one do you like better? ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-02-28 10:19 Message: Logged In: YES user_id=329402 Note that this change removes dependencies from the PyThread code, which is a stated goal of that module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522961&group_id=5470 From noreply@sourceforge.net Thu Feb 28 21:35:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 13:35:54 -0800 Subject: [Patches] [ python-Patches-522961 ] Leak in Python/thread_nt.h Message-ID: Patches item #522961, was opened at 2002-02-26 08:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522961&group_id=5470 Category: Windows Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Tim Peters (tim_one) Summary: Leak in Python/thread_nt.h Initial Comment: I submitted this into the bug tracker as [ #522621 ] Leak in thread_nt.h, although was advised to convert it into a proper patch request... The NT threading module creates a dictionary to keep track of thread handles but never uses it. It doesn't maintain it properly, creating leaks. This patch removes the dictionary entirely. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-02-28 16:35 Message: Logged In: YES user_id=31435 Thanks! This has been checked in, Misc/ACKS; new revision: 1.160 Python/thread_nt.h; new revision: 2.22 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-28 16:30 Message: Logged In: YES user_id=31435 Deleted the older patch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-28 16:13 Message: Logged In: YES user_id=31435 Changed Category to Windows, assigned to me. Gerald, there are two patches attached, uploaded within two minutes of each other. Which one do you like better? ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-02-28 10:19 Message: Logged In: YES user_id=329402 Note that this change removes dependencies from the PyThread code, which is a stated goal of that module. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=522961&group_id=5470 From noreply@sourceforge.net Thu Feb 28 22:32:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 14:32:14 -0800 Subject: [Patches] [ python-Patches-523241 ] MimeWriter must use CRLF instead of LF Message-ID: Patches item #523241, was opened at 2002-02-26 21:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523241&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Clarence Gardner (cgardner) Assigned to: Nobody/Anonymous (nobody) Summary: MimeWriter must use CRLF instead of LF Initial Comment: In all of the output that MimeWriter does (headers and boundaries), a CRLF must be written rather than just LF. (CRLF at the end of the header, and at the beginning and end of the boundaries.) Here's hoping I'm doing this right :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 17:32 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523241&group_id=5470 From noreply@sourceforge.net Thu Feb 28 22:35:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 14:35:30 -0800 Subject: [Patches] [ python-Patches-511449 ] PyBuffer_New double alignment bugfix Message-ID: Patches item #511449, was opened at 2002-01-31 17:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511449&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Deleted Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: PyBuffer_New double alignment bugfix Initial Comment: PyBuffer_New performs a single malloc to allocate a buffer object and its associated storage. In Python-2.2 the object is double aligned, but the storage is not guaranteed to be double aligned. See bug #472568 by Frederic Giacometti. This patch adds a padding double to the buffer object and code which truncates the storage pointer to a double aligned boundary within the padding. Frederic's original suggestion was cleaner, but appeared to require an extra compiler switch to get double alignment for gcc i386. Since the info page for gcc -malign-double warns: *Warning:* if you use the `-malign-double' switch, structures containing the above types will be aligned differently than the published application binary interface specifications for the 386. I figured the switch was a bad idea, so I used truncating division instead of Frederic's clean pointer trick. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511449&group_id=5470 From noreply@sourceforge.net Thu Feb 28 22:37:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 14:37:49 -0800 Subject: [Patches] [ python-Patches-521478 ] mailbox / fromline matching Message-ID: Patches item #521478, was opened at 2002-02-22 09:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521478&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Camiel Dobbelaar (camield) >Assigned to: Guido van Rossum (gvanrossum) Summary: mailbox / fromline matching Initial Comment: mailbox.py does not parse this 'From' line correctly: >From camield@sentia.nl Mon Apr 23 18:22:28 2001 +0200 ^^^^^ This is because of the trailing timezone information, that the regex does not account for. Also, 'From' should match at the beginning of the line. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 17:37 Message: Logged In: YES user_id=6380 That From line is simply illegal, or at least nonstandard. If your system uses this nonstandard format, you can extend the mailbox parser by overriding the ._isrealfromline method. The pattern doesn't need ^ because match() is used, which only matches at the start of the line. Rejected. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=521478&group_id=5470 From noreply@sourceforge.net Thu Feb 28 22:41:01 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 14:41:01 -0800 Subject: [Patches] [ python-Patches-523241 ] MimeWriter must use CRLF instead of LF Message-ID: Patches item #523241, was opened at 2002-02-26 18:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523241&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Clarence Gardner (cgardner) Assigned to: Nobody/Anonymous (nobody) Summary: MimeWriter must use CRLF instead of LF Initial Comment: In all of the output that MimeWriter does (headers and boundaries), a CRLF must be written rather than just LF. (CRLF at the end of the header, and at the beginning and end of the boundaries.) Here's hoping I'm doing this right :) ---------------------------------------------------------------------- >Comment By: Clarence Gardner (cgardner) Date: 2002-02-28 14:41 Message: Logged In: YES user_id=409146 Actually, it's a SourceForge bug :( I did check the box and attach the file, but it gave me a "Bad Filename" error. I did it again, removing the quotes that my browser put around the filename, and it said "You already submitted this! Don't doubleclick!" So maybe not *everybody's* submissions that lack a file came from an idiot :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 14:32 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523241&group_id=5470 From noreply@sourceforge.net Thu Feb 28 22:46:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 14:46:10 -0800 Subject: [Patches] [ python-Patches-520694 ] arraymodule.c improvements Message-ID: Patches item #520694, was opened at 2002-02-20 17:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Jason Orendorff (jorend) Assigned to: Martin v. L�wis (loewis) Summary: arraymodule.c improvements Initial Comment: This patch makes brings the array module a little more up-to-date. There are two changes: 1. Modernize the array type, memory management, and so forth. As a result, the array() builtin is no longer a function but a type. array.array is array.ArrayType. Also, it can now be subclassed in Python. 2. Add a new typecode 'u', for Unicode characters. The patch includes changes to test/test_array.py to test the new features. I would like to make a further change: add an arrayobject.h include file, and provide some array operations there, giving them names like PyArray_Check(), PyArray_GetItem(), and PyArray_GET_DATA(). Is such a change likely to find favor? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 17:46 Message: Logged In: YES user_id=6380 Cool. I wonder if it wouldn't have been easier to first submit and commit the easy changes, and then the unicode addition separately? Anyway, I presume that Martin will commit this when it's ready. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-26 22:15 Message: Logged In: YES user_id=18139 Getting there. This version has tounicode() and fromunicode(), and a better repr() for type 'u' arrays. Also, array.typecode and array.itemsize are now listed under tp_getset; they're attribute descriptors and they show up in help(array). (Neat!) Next, documentation; then __iadd__ and __imul__. But not tonight. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-25 07:24 Message: Logged In: YES user_id=21627 Removal of __members__ is fine, then - but you do need to fill out an appropriate tp_members instead, listing "typecode" and "itemsize". Adding __iadd__ and __imul__ is fine; the equivalent feature for lists has not caused complaints, either, and anybody using *= on an array probably would consider it a bug that it isn't in-place. Please add documentation changes as well; I currently have Doc/lib/libarray.tex \lineiii{'d'}{double}{8} +\lineiii{'u'}{Py_UNICODE}{2} \end{tableiii} Misc/NEWS - array.array is now a type object. A new format character 'u' indicates Py_UNICODE arrays. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-24 19:29 Message: Logged In: YES user_id=18139 Martin writes: "There is a flaw in the extension of arrays to Unicode: There is no easy way to get back the Unicode string." Boy, are you right. There should be array.tounicode() and array.fromunicode() methods that only work on type 'u' arrays. ...I also want to fix repr for type 'u' arrays. Instead of "array.array('u', [u'x', u'y', u'z'])" it should say "array.array('u', u'xyz')". ...I would also implement __iadd__ and __imul__ (as list implements them), but this would be a semantic change! Thoughts? Count on a new patch tomorrow. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-24 16:38 Message: Logged In: YES user_id=31435 Without looking at any details, __members__ and __methods__ are deprecated starting with 2.2; the type/class unification PEPs aim at moving the universe toward supporting and using the class-like introspection API instead. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-24 10:56 Message: Logged In: YES user_id=21627 There is a flaw in the extension of arrays to Unicode: There is no easy way to get back the Unicode string. You have to use u"".join(arr.tolist()) This is slightly annoying, since there is it is the only case where it is not possible to get back the original constructor arguments. Also, what is the rationale for removing __members__? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-22 08:39 Message: Logged In: YES user_id=38388 How about simplifying the whole setup altogether and add arrays as standard Python types (ie. put the code in Objects/ and add the new include file to Includes/). About the inter-module C API export: I'll write up a PEP about this which will hopefully result in a new standard support mechanism for this in Python. (BTW, the approach I used in _ssl/_socket does use PyCObjects) ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-22 08:25 Message: Logged In: YES user_id=21627 With the rationale given, I'm now in favour of all parts of the patch. As for exposing the API, you need to address MAL's concerns: PyArray_* won't be available to other extension modules, instead, you need to do expose them through a C object. However, I recommend *not* to follow the approach taken in socket/ssl; I agree with Tim's concerns here. Instead, the approach taken by cStringIO (via cStringIO.cStringIO_API) is much better (i.e. put the burden of using the API onto any importer, and out of Python proper). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-02-21 03:40 Message: Logged In: YES user_id=38388 About the Unicode bit: if "u" maps to Py_UNICODE I for one don't have any objections. The internal encoding is available in lots of places, so that argument doesn't count and I'm sure it can be put to some good use for fast manipulation of large Unicode strings. I very much like the new exposure of the type at C level; however I don't understand how you would use it without adding the complete module to the libpythonx.x.a (unless you add some sort of inter-module C API import mechanism like the one I added to _socket and _ssl) ?! ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 21:03 Message: Logged In: YES user_id=18139 > What is the rationale for expanding PyObject_VAR_HEAD? > It doesn't seem to achieve anything. It didn't make sense for array to be a VAR_HEAD type. VAR_HEAD types are variable-size: the last member defined in the struct for such a type is an array of length 1, and type->item_size is nonzero. See e.g. PyType_GenericAlloc(), and how it decides whether to call PyObject_INIT or PyObject_VAR_INIT: It checks type->item_size. The new arraymodule.c calls PyType_GenericAlloc; the old one didn't. So a change seemed warranted. Since Arraytype has item_size == 0, it seemed most consistent to make it a non-VAR type and initialize the ob_size field myself. I'm pretty sure I got the right interpretation of this; but if not, someone wiser in the ways of Python will speak up. :) (While I was looking at this, I noticed this: http://sourceforge.net/tracker/index.php? func=detail&aid=520768&group_id=5470&atid=305470) ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 20:15 Message: Logged In: YES user_id=18139 > I don't like the Unicode part of it at all. Well, I'm not attatched to it. It's very easy to subtract it from the patch. > What can you do with this feature? The same sort of thing you might do with an array of type 'c'. For example, change individual characters of a (Unicode) string and then run a (Unicode) re.match on it. > It seems to unfairly prefer a specific Unicode encoding, > without explaining what that encoding is, and without a > clear use case why this encoding is desirable. Well, why should array('h', '\x00\xff\xaa\xbb') be allowed? Why is that encoding preferable to any other particular encoding of short ints? Easy: it's the encoding of the C compiler where Python was built. For 'u' arrays, the encoding used is just the encoding that Python uses internally. However, it's not intended to be used in any situation where encode()/decode() would be appropriate. I never even thought about that possibility when I wrote it. The behavior of a 'u' array is intended to be more like this: Suppose A = array('u', ustr). Then: len(A) == len(ustr) A[0] == ustr[0] A[1] == ustr[1] ... That is, a 'u' array is an array of Unicode characters. Encoding is not an issue, any more than with the built-in unicode type. (If ustr is a non-Unicode string, then the behavior is different -- more in line with what 'b', 'h', 'i', and the others do.) If your concern is that Python currently "hides" its internal encoding, and the 'u' array exposes this unnecessarily, then consider these two examples that don't involve arrays: >>> x = u'\U00012345' # One Unicode codepoint... >>> len(x) 2 # hmm. >>> x[0] u'\ud808' # aha. UTF-16. >>> x[1] u'\udf45' >>> str(buffer(u'abc')) # Example two. 'a\x00b\x00c\x00' > It also seems to overlap with the Unicode object's > .encode method, which is much more general. Wow. Well, that wasn't my intent. It is intended, rather, to offer parity with 'c'. Java has byte[], short[], int[], long[], float[], double[], and char[]... Python doesn't currently have char[]. Shouldn't it? ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 18:02 Message: Logged In: YES user_id=21627 What is the rationale for expanding PyObject_VAR_HEAD? It doesn't seem to achieve anything. I don't like the Unicode part of it at all. What can you do with this feature? It seems to unfairly prefer a specific Unicode encoding, without explaining what that encoding is, and without a clear use case why this encoding is desirable. It also seems to overlap with the Unicode object's .encode method, which is much more general. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520694&group_id=5470 From noreply@sourceforge.net Thu Feb 28 22:59:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 14:59:39 -0800 Subject: [Patches] [ python-Patches-520483 ] Make IDLE OutputWindow handle Unicode Message-ID: Patches item #520483, was opened at 2002-02-20 09:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 Category: IDLE Group: Python 2.2.x >Status: Closed Resolution: Accepted Priority: 7 Submitted By: Jason Orendorff (jorend) Assigned to: Guido van Rossum (gvanrossum) Summary: Make IDLE OutputWindow handle Unicode Initial Comment: This one-line patch makes OutputWindow handle Unicode correctly. For example, >>> print u'\xbfQu\xe9 pas\xf3?' In 2.2 this throws a UnicodeError, not because of any problem with Unicode handling in either Python or Tk, but because IDLE does str(s) on the Unicode string. I just took out the call to str(). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 17:59 Message: Logged In: YES user_id=6380 I think when I first wrote that code, Tkinter didn't yet support Unicode. I think I felt that write() shouldn't be called with anything besides a string, but I didn't want to put in an explicit type check, and yet I didn't want to pass non-strings to Tcl because it treats certain types special. For example, in the patched IDLE, try sys.stdout.write((1,2,(3,4))), or try sys.stdout.write(None). But I think it's no big deal, and I approve of the change. Consequently, I'm closing this bug report again. I've merged this into 2.2.1. Should I do anything else? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-23 19:43 Message: Logged In: YES user_id=31435 We're never too busy for people we love, Jason . Reopened, changed category to IDLE, changed group to Python 2.2.x, boosted priority, and assigned to Guido. The str() call has been there since Guido first checked this in, and its purpose isn't apparent to me either. Maybe Guido remembers. Guido? I'm not worried at all that someone might be calling it with a non-stringish argument -- it's supplying a "file- like object" interface, and .write() requires a stringish argument. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-23 19:19 Message: Logged In: YES user_id=18139 Submitted to idlefork. I'm too shy to bother "one of the major IDLE authors." It would be nice to have in 2.2.1, but I know the folks at PythonLabs are busy... ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-23 17:42 Message: Logged In: YES user_id=21627 Ok, committed as OutputWindow 1.6. I strongly recommend to submit this to idlefork as well. If want this patch to appear in Python 2.2.1, you should get a comment from one of the major IDLE authors or contributors. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2002-02-20 18:27 Message: Logged In: YES user_id=18139 > Isn't this too simplistic? I guess there was a reason for > the str call: could it ever happen that somebody passes > something else (beyond byte and Unicode strings)? I searched for write() in the idle directory and got 48 hits in 7 files. Then I checked them all. In every case, either write() is called with a string, or the argument is passed unchanged from another function that contains the word "write()". As for code outside IDLE, I'd be extra surprised if anyone calls obj.write(x) with x being something other than a string. Ordinary file objects don't accept it. ---------------------------------------------------------------------- Comment By: Martin v. L�wis (loewis) Date: 2002-02-20 17:56 Message: Logged In: YES user_id=21627 Isn't this too simplistic? I guess there was a reason for the str call: could it ever happen that somebody passes something else (beyond byte and Unicode strings)? Also, I wonder whether IDLE patches need to go to idlefork (sf.net/projects/idlefork) first. Apart from this comments, I think your patch is quite right. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520483&group_id=5470 From noreply@sourceforge.net Thu Feb 28 23:03:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 15:03:43 -0800 Subject: [Patches] [ python-Patches-523241 ] MimeWriter must use CRLF instead of LF Message-ID: Patches item #523241, was opened at 2002-02-26 21:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523241&group_id=5470 Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Clarence Gardner (cgardner) Assigned to: Nobody/Anonymous (nobody) Summary: MimeWriter must use CRLF instead of LF Initial Comment: In all of the output that MimeWriter does (headers and boundaries), a CRLF must be written rather than just LF. (CRLF at the end of the header, and at the beginning and end of the boundaries.) Here's hoping I'm doing this right :) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 18:03 Message: Logged In: YES user_id=6380 Thanks for bearing with us. SF may be the worst possible tool, but I don't know anything better. :-( Having seen the patch, I disagree with your intent. This issue has come up before. While the MIME standard stipulates that newlines are represented as CRLF on the wire, we're not writing files on the wire. We're using the local line ending convention consistently whenever we read or write email, and some other entity is responsible for translating these to the proper CRLF. Maybe you can come up with a fix to the documentation that explains this policy instead? ---------------------------------------------------------------------- Comment By: Clarence Gardner (cgardner) Date: 2002-02-28 17:41 Message: Logged In: YES user_id=409146 Actually, it's a SourceForge bug :( I did check the box and attach the file, but it gave me a "Bad Filename" error. I did it again, removing the quotes that my browser put around the filename, and it said "You already submitted this! Don't doubleclick!" So maybe not *everybody's* submissions that lack a file came from an idiot :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 17:32 Message: Logged In: YES user_id=6380 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=523241&group_id=5470 From noreply@sourceforge.net Thu Feb 28 23:08:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 15:08:23 -0800 Subject: [Patches] [ python-Patches-520062 ] Support IPv6 with VC.NET Message-ID: Patches item #520062, was opened at 2002-02-19 12:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520062&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L�wis (loewis) >Assigned to: Martin v. L�wis (loewis) Summary: Support IPv6 with VC.NET Initial Comment: This patch enables IPv6 support based on Winsock2 on Microsoft C 13 and later. Due to the implementation strategy used in the SDK headers, the resulting _socket.pyd will not require additional shared libraries, but it will instead locale the symbols dynamically, and fall back to a default implementation if none are found. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 18:08 Message: Logged In: YES user_id=6380 We'll have a hard time to test this, since I don't think anyone I know with a Windows build environment is set up for IPv6 yet. I'm assigning to Martin since he's the IPv6 master, to see if he agrees with the basic premises (and that it doesn't break anything on Unix -- it's a pretty small patch so that seems unlikely). Then Martin should probably assign it to Tim, so Tim can see if at least it doesn't break anything on various flavors of Windows we have lying around. Then it can be alpha and beta tested to see if it doesn't break anything else, and the original author can test if the installer we distribute actually does the right thing for him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520062&group_id=5470 From noreply@sourceforge.net Thu Feb 28 23:08:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 15:08:38 -0800 Subject: [Patches] [ python-Patches-511449 ] PyBuffer_New double alignment bugfix Message-ID: Patches item #511449, was opened at 2002-01-31 17:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511449&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Deleted Resolution: None Priority: 5 Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: PyBuffer_New double alignment bugfix Initial Comment: PyBuffer_New performs a single malloc to allocate a buffer object and its associated storage. In Python-2.2 the object is double aligned, but the storage is not guaranteed to be double aligned. See bug #472568 by Frederic Giacometti. This patch adds a padding double to the buffer object and code which truncates the storage pointer to a double aligned boundary within the padding. Frederic's original suggestion was cleaner, but appeared to require an extra compiler switch to get double alignment for gcc i386. Since the info page for gcc -malign-double warns: *Warning:* if you use the `-malign-double' switch, structures containing the above types will be aligned differently than the published application binary interface specifications for the 386. I figured the switch was a bad idea, so I used truncating division instead of Frederic's clean pointer trick. ---------------------------------------------------------------------- >Comment By: Jay T Miller (jaytmiller) Date: 2002-02-28 18:08 Message: Logged In: YES user_id=320512 I have withdrawn this patch after realizing that I somehow missed much of the discussion regarding the bug and how to fix it. My fix is not really correct, although it did work for me, and I suspect, would work on most compilers. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=511449&group_id=5470 From noreply@sourceforge.net Thu Feb 28 23:17:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 15:17:22 -0800 Subject: [Patches] [ python-Patches-520062 ] Support IPv6 with VC.NET Message-ID: Patches item #520062, was opened at 2002-02-19 12:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520062&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L�wis (loewis) >Assigned to: Tim Peters (tim_one) Summary: Support IPv6 with VC.NET Initial Comment: This patch enables IPv6 support based on Winsock2 on Microsoft C 13 and later. Due to the implementation strategy used in the SDK headers, the resulting _socket.pyd will not require additional shared libraries, but it will instead locale the symbols dynamically, and fall back to a default implementation if none are found. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-02-28 18:17 Message: Logged In: YES user_id=31435 Since Martin submitted the patch, I think we can assume he already agrees with the basic premise . Reassigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 18:08 Message: Logged In: YES user_id=6380 We'll have a hard time to test this, since I don't think anyone I know with a Windows build environment is set up for IPv6 yet. I'm assigning to Martin since he's the IPv6 master, to see if he agrees with the basic premises (and that it doesn't break anything on Unix -- it's a pretty small patch so that seems unlikely). Then Martin should probably assign it to Tim, so Tim can see if at least it doesn't break anything on various flavors of Windows we have lying around. Then it can be alpha and beta tested to see if it doesn't break anything else, and the original author can test if the installer we distribute actually does the right thing for him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520062&group_id=5470 From noreply@sourceforge.net Thu Feb 28 23:19:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 15:19:16 -0800 Subject: [Patches] [ python-Patches-518765 ] Bug in copy.py when used through rexec Message-ID: Patches item #518765, was opened at 2002-02-17 09:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=518765&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Derek Harland (dharland) >Assigned to: Guido van Rossum (gvanrossum) Summary: Bug in copy.py when used through rexec Initial Comment: Version: In all versions since Python 1.5.2 up to the current Python 2.3a0 Platforms: All When using a restricted environment, imports of copy will fail with an AttributeError when trying to access types.CodeType. This occurs while trying to set up the deepcopy helper dictionary. The creation of the shallow copy helper dictionary works fine as the attempt to extract types.CodeType is explicitly wrapped in a try. This very minor patch adds the same try except wrapper for the deepcopy setup. example: >>> import rexec >>> rexec.RExec().r_import('copy') Traceback (most recent call last): File "", line 1, in ? File "/home/harland/dev/sourceforge/python/dist/src/Lib/rexec.py", line 265, in r_import return self.importer.import_module(mname, globals, locals, fromlist) File "/home/harland/dev/sourceforge/python/dist/src/Lib/ihooks.py", line 397, in import_module q, tail = self.find_head_package(parent, name) File "/home/harland/dev/sourceforge/python/dist/src/Lib/ihooks.py", line 433, in find_head_package q = self.import_it(head, qname, parent) File "/home/harland/dev/sourceforge/python/dist/src/Lib/ihooks.py", line 486, in import_it m = self.loader.load_module(fqname, stuff) File "/home/harland/dev/sourceforge/python/dist/src/Lib/ihooks.py", line 325, in load_module exec code in m.__dict__ File "/home/harland/dev/sourceforge/python/dist/src/Lib/copy.py", line 200, in ? d[types.CodeType] = _deepcopy_atomic AttributeError: 'module' object has no attribute 'CodeType' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 18:19 Message: Logged In: YES user_id=6380 Thanks! Fixed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=518765&group_id=5470 From noreply@sourceforge.net Thu Feb 28 23:20:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 15:20:54 -0800 Subject: [Patches] [ python-Patches-520062 ] Support IPv6 with VC.NET Message-ID: Patches item #520062, was opened at 2002-02-19 12:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520062&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L�wis (loewis) Assigned to: Tim Peters (tim_one) Summary: Support IPv6 with VC.NET Initial Comment: This patch enables IPv6 support based on Winsock2 on Microsoft C 13 and later. Due to the implementation strategy used in the SDK headers, the resulting _socket.pyd will not require additional shared libraries, but it will instead locale the symbols dynamically, and fall back to a default implementation if none are found. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-02-28 18:20 Message: Logged In: YES user_id=31435 The "//" style comment in pyconfig.h should change to /**/ style (I don't care that MSVC accepts either -- not everyone looking at this file uses MSVC). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-28 18:17 Message: Logged In: YES user_id=31435 Since Martin submitted the patch, I think we can assume he already agrees with the basic premise . Reassigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 18:08 Message: Logged In: YES user_id=6380 We'll have a hard time to test this, since I don't think anyone I know with a Windows build environment is set up for IPv6 yet. I'm assigning to Martin since he's the IPv6 master, to see if he agrees with the basic premises (and that it doesn't break anything on Unix -- it's a pretty small patch so that seems unlikely). Then Martin should probably assign it to Tim, so Tim can see if at least it doesn't break anything on various flavors of Windows we have lying around. Then it can be alpha and beta tested to see if it doesn't break anything else, and the original author can test if the installer we distribute actually does the right thing for him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520062&group_id=5470 From noreply@sourceforge.net Thu Feb 28 23:23:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 15:23:09 -0800 Subject: [Patches] [ python-Patches-517256 ] poor performance in xmlrpc response Message-ID: Patches item #517256, was opened at 2002-02-13 18:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517256&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Rucker (jamesrucker) >Assigned to: Fredrik Lundh (effbot) Summary: poor performance in xmlrpc response Initial Comment: xmlrpclib.Transport.parse_response() (called from xmlrpclib.Transport.request()) is exhibiting poor performance - approx. 10x slower than expected. I investigated based on using a simple app that sent a msg to a server, where all the server did was return the message back to the caller. From profiling, it became clear that the return trip was taken 10x the time consumed by the client->server trip, and that the time was spent getting things across the wire. parse_response() reads from a file object created via socket.makefile(), and as a result exhibits performance that is about an order of magnitude worse than what it would be if socket.recv() were used on the socket. The patch provided uses socket.recv() when possible, to improve performance. The patch provided is against revision 1.15. Its use provides performance for the return trip that is more or less equivalent to that of the forward trip. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 18:23 Message: Logged In: YES user_id=6380 Fredrik, does this look OK to you? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=517256&group_id=5470 From noreply@sourceforge.net Thu Feb 28 23:33:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 15:33:03 -0800 Subject: [Patches] [ python-Patches-520768 ] cellobject isn't VAR Message-ID: Patches item #520768, was opened at 2002-02-21 02:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520768&group_id=5470 Category: Core (C code) Group: None Status: Open >Resolution: Accepted Priority: 1 Submitted By: Jason Orendorff (jorend) Assigned to: Jeremy Hylton (jhylton) Summary: cellobject isn't VAR Initial Comment: cellobject.h has: typedef struct { PyObject_VAR_HEAD PyObject *ob_ref; } PyCellObject; But it's wrong; it should just be plain PyObject_HEAD, not VAR_HEAD. (I tested this on Win32; it compiles and passes the tests. The ob_size field implied by VAR_HEAD just isn't used anywhere.) ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-02-28 23:33 Message: Logged In: YES user_id=31392 Yup. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-21 23:41 Message: Logged In: YES user_id=6380 I agree. Assigned to Jeremy. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520768&group_id=5470 From noreply@sourceforge.net Thu Feb 28 23:39:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 15:39:05 -0800 Subject: [Patches] [ python-Patches-520062 ] Support IPv6 with VC.NET Message-ID: Patches item #520062, was opened at 2002-02-19 12:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520062&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. L�wis (loewis) >Assigned to: Martin v. L�wis (loewis) Summary: Support IPv6 with VC.NET Initial Comment: This patch enables IPv6 support based on Winsock2 on Microsoft C 13 and later. Due to the implementation strategy used in the SDK headers, the resulting _socket.pyd will not require additional shared libraries, but it will instead locale the symbols dynamically, and fall back to a default implementation if none are found. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-02-28 18:39 Message: Logged In: YES user_id=31435 Back to Martin. No problems compiling or running on my Win98SE + VC6 box, incl. test_socketserver.py. The only thing I object to is the "//" comment. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-28 18:20 Message: Logged In: YES user_id=31435 The "//" style comment in pyconfig.h should change to /**/ style (I don't care that MSVC accepts either -- not everyone looking at this file uses MSVC). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-28 18:17 Message: Logged In: YES user_id=31435 Since Martin submitted the patch, I think we can assume he already agrees with the basic premise . Reassigned to me. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-28 18:08 Message: Logged In: YES user_id=6380 We'll have a hard time to test this, since I don't think anyone I know with a Windows build environment is set up for IPv6 yet. I'm assigning to Martin since he's the IPv6 master, to see if he agrees with the basic premises (and that it doesn't break anything on Unix -- it's a pretty small patch so that seems unlikely). Then Martin should probably assign it to Tim, so Tim can see if at least it doesn't break anything on various flavors of Windows we have lying around. Then it can be alpha and beta tested to see if it doesn't break anything else, and the original author can test if the installer we distribute actually does the right thing for him. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520062&group_id=5470 From noreply@sourceforge.net Thu Feb 28 23:46:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 28 Feb 2002 15:46:52 -0800 Subject: [Patches] [ python-Patches-520768 ] cellobject isn't VAR Message-ID: Patches item #520768, was opened at 2002-02-21 02:00 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520768&group_id=5470 Category: Core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 1 Submitted By: Jason Orendorff (jorend) Assigned to: Jeremy Hylton (jhylton) Summary: cellobject isn't VAR Initial Comment: cellobject.h has: typedef struct { PyObject_VAR_HEAD PyObject *ob_ref; } PyCellObject; But it's wrong; it should just be plain PyObject_HEAD, not VAR_HEAD. (I tested this on Win32; it compiles and passes the tests. The ob_size field implied by VAR_HEAD just isn't used anywhere.) ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2002-02-28 23:46 Message: Logged In: YES user_id=31392 Fixed in rev 2.2 of cellobject.h. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-02-28 23:33 Message: Logged In: YES user_id=31392 Yup. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-02-21 23:41 Message: Logged In: YES user_id=6380 I agree. Assigned to Jeremy. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=520768&group_id=5470