Mailman 3 May 2007 - Python-Dev

removing use of mimetools, multifile, and rfc822
by Brett Cannon 31 May '07

31 May '07

I just finished going through PEP 4 and adding DeprecationWarnings in 2.6for the various modules that were lacking the warning for some reason or another ... ... except for mimetools, multifile, and rfc822. All three modules are still used by some other module somewhere in the stdlib. The docs say to use the email package to replace these three, but there is no one-to-one mapping. And as I never use any of these three modules, email, or the modules still using the three in question I don't know how to go about ripping them out. In other words this email is to hopefully inspire someone to remove the uses of rfc822, mimetools, and multifile from the stdlib so the DeprecationWarnings can finally go in. -Brett

3 2

Re: [Python-Dev] [Distutils] Adventures with x64, VS7 and VS8 on Windows
by "Martin v. Löwis" 31 May '07

31 May '07

> The practical problem is: how should 'The PSF' get a Microsoft-signed > certificate? If you want to experiment with a signed installer, try http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.1.msi In order for Windows to verify the signature, you can install http://www.dcl.hpi.uni-potsdam.de/home/loewis/osm.cer first (and remove it from the list of trusted root certificates when you are done, if you are worried about that). While XP displays the certificate just fine (in Properties/Digital Signatures), my installation of Vista fails to recognize that the file has a signature. Not sure what's wrong here (FWIW, signtool would fail to sign the file as well if run on Vista, but signed it just fine when run on XP). Regards, Martin

1 0

Re: [Python-Dev] Quoting netiquette reminder [Re: proposed which.py replacement]
by Greg Ewing 31 May '07

31 May '07

Aahz wrote: > Guido has previously given himself explicit permission to violate > netiquette (including the rule about top-posting). Only in the Python mailing lists, I hope -- unless he's declared himself BDFL of the whole Internet as well. :-) I suppose he could be considered to have a right to do that, but it doesn't stop sloppy quoting practices from being annoying and inefficient. The quoting conventions that emerged in the early days did so for good reasons -- they avoid squandering bandwidth and aid clear communication. To me, it's not so much a matter of politeness, but of common sense. -- Greg

1 0

New Super PEP
by Calvin Spealman 30 May '07

30 May '07

Comments welcome, of course. Bare with my first attempt at crafting a PEP. PEP: XXX Title: Super As A Keyword Version: $Revision$ Last-Modified: $Date$ Author: Calvin Spealman <ironfroggy(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30-Apr-2007 Python-Version: 2.6 Post-History: Abstract ======== The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Rationale ========= The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. Specification ============= Replacing the old usage of super, calls to the next class in the MRO (method resolution order) will be made without an explicit super object creation, by simply accessing an attribute on the super type directly, which will automatically apply the class and instance to perform the proper lookup. The following example demonstrates the use of this. :: class A(object): def f(self): return 'A' class B(A): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Each super attribute lookup identifies these parameters and performs the super lookup on the instance, as the current super implementation does with the explicit invokation of a super object upon a class and instance. The enhancements to the super type will define a new __getattr__ classmethod of the super type, which must look backwards to the previous frame and locate the instance object. This can be naively determined by located the local named by the first argument to the function. Using super outside of a function where this is a valid lookup for the instance can be considered undocumented in its behavior. Every class will gain a new special attribute, __super__, which is a super object instansiated only with the class it is an attribute of. In this capacity, the new super also acts as its own descriptor, create an instance- specific super upon lookup. Much of this was discussed in the thread of the python-dev list, "Fixing super anyone?" [1]_. Open Issues ----------- __call__ methods '''''''''''''''' Backward compatability of the super type API raises some issues. Names, the lookup of the __call__ of the super type itself, which means a conflict with doing an actual super lookup of the __call__ attribute. Namely, the following is ambiguous in the current proposal: :: super.__call__(arg) Which means the backward compatible API, which involves instansiating the super type, will either not be possible, because it will actually do a super lookup on the __call__ attribute, or there will be no way to perform a super lookup on the __call__ attribute. Both seem unacceptable, so any suggestions are welcome. super type's new getattr '''''''''''''''''''''''' To give the behavior needed, the super type either needs a way to do dynamic lookup of attributes on the super type object itself or define a metaclass for the builtin type. This author is unsure which, if either, is possible with C- defined types. When should we create __super__ attributes? ''''''''''''''''''''''''''''''''''''''''''' They either need to be created on class creation or on __super__ attribute lookup. For the second, they could be cached, of course, which seems like it may be the best idea, if implicit creation of a super object for every class is considered too much overhead. References ========== .. [1] Fixing super anyone? (http://mail.python.org/pipermail/python-3000/2007-April/006667.html) Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/

16 40

Re: [Python-Dev] Build problems with sqlite on OSX
by Darrin Thompson 30 May '07

30 May '07

On 5/29/07, "Martin v. Löwis" <martin(a)v.loewis.de> wrote: > p &sqlite3InitCallback > (gdb) p $sqlite3InitCallback $1 = void grrrr. > Try "info shared" in gdb. Not sure whether that works on OSX, > though. > Worked beautifully! The smoking gun: something is hauling in the system provided sqlite3 in addition to my static one. (Weren't you just saying that?) I'm going to investigate that further unless you tell me I'm an idiot. I suspect it's the official Qt binaries from Trolltech doing it indirectly. Plus that's the only way I can rationalize some sqlite functions having source available and some acting like they've been stripped. -- Darrin

2 1

couple of bug fixes
by Raghuram Devarakonda 29 May '07

29 May '07

Hi, I uploaded couple of patches to fix bugs. 1) http://www.python.org/sf/1720897 to fix the bug 668596 (distutils chops the first character of filenames). 2) http://www.python.org/sf/1713041 to fix the bug 1712742 (pprint handles depth argument incorrectly). Both the patches are extremely small (2, 3 lines change) and include test cases. Can I interest some one to review them? Thanks, Raghu.

1 0

whitespace normalization pre-commit hook is giving me grief
by Brett Cannon 29 May '07

29 May '07

In my bcannon-objcap branch I am trying to check in a change that involves a soft symlink from Lib/controlled_importlib.py to ../importlib/controlled_importlib.py through ``ln -s ../controlled_importlib.py controlled_importlib.py`` while in the Lib directory. I have done this before in this branch so as to allow for easy importing of code from the svn import of importlib that the branch contains. But svn keeps rejecting the commit saying that Lib/controlled_importlib.py needs to be whitespace normalized. I have run reindent on both the external import in the branch and in the original sandbox copy and both are coming back clean. I even imported reindent manually and followed what Georg posted when the pre-commit hook was added and it still passes. Unfortunately the pre-commit hook does not specify what line a change was made on so I have no clue where it is failing (maybe this should be added?). Can somebody help me figure out what the hell is going on? I am waiting to find out it is something small and stupid, but at this point I am not seeing a solution to this. -Brett

5 12

Build problems with sqlite on OSX
by Darrin Thompson 29 May '07

29 May '07

First of all 1000 apologies if this is the wrong list. Please redirect me if necessary. I'm attempting to build python 2.5.1 fat binaries on OSX and statically link to a newer sqlite than what ships with OSX. (3.3.17). I'm getting "Bus Error" early when I run my app. If I turn on a lot of malloc debugging options and run under gdb I get this trace: (gdb) info threads * 1 process 18968 local thread 0x1003 0x900e41d1 in strtol_l () (gdb) bt #0 0x900e41d1 in strtol_l () #1 0x900160a5 in atoi () #2 0x9406fd80 in sqlite3InitCallback () #3 0x0381faf2 in sqlite3_exec (db=0x338d080, zSql=0x331f1e0 "SELECT name, rootpage, sql FROM 'main'.sqlite_master WHERE tbl_name='sqlite_sequence'", xCallback=0x9406fd00 <sqlite3InitCallback>, pArg=0xbfffde14, pzErrMsg=0x0) at ./src/legacy.c:93 #4 0x0384c769 in sqlite3VdbeExec (p=0x1945200) at ./src/vdbe.c:4090 #5 0x03816686 in sqlite3Step (p=0x1945200) at ./src/vdbeapi.c:236 #6 0x03816817 in sqlite3_step (pStmt=0x1945200) at ./src/vdbeapi.c:289 #7 0x0380b9aa in _sqlite_step_with_busyhandler (statement=0x1945200, connection=0x32a77a0) at /Users/pandora/build-toolchain/build/Python-2.5.1/Modules/_sqlite/util.c:33 #8 0x0380850d in cursor_executescript (self=0x32bd4d0, args=0x32a2d10) at /Users/pandora/build-toolchain/build/Python-2.5.1/Modules/_sqlite/cursor.c:788 #9 0x0020e6fc in PyObject_Call (func=0x329ecd8, arg=0x32a2d10, kw=0x0) at Objects/abstract.c:1860 #10 0x00292a36 in PyEval_CallObjectWithKeywords (func=0x329ecd8, arg=0x32a2d10, kw=0x0) at Python/ceval.c:3433 #11 0x0020e6cd in PyObject_CallObject (o=0x329ecd8, a=0x32a2d10) at Objects/abstract.c:1851 #12 0x03806e1c in connection_executescript (self=0x32a77a0, args=0x32a2d10, kwargs=0x0) at /Users/pandora/build-toolchain/build/Python-2.5.1/Modules/_sqlite/connection.c:1001 #13 0x002998ae in PyEval_EvalFrameEx (f=0x338c250, throwflag=0) at Python/ceval.c:3564 Can someone advise as to the correct configure arguments for sqlite or something else I might be missing? Thanks in advance. -- Darrin

5 6

Unable to commit
by Peter Åstrand 29 May '07

29 May '07

I'm unable to commit tonight: Sending Doc/lib/libsubprocess.tex Sending Lib/subprocess.py Sending Lib/test/test_subprocess.py Transmitting file data ...svn: Commit failed (details follow): svn: 'pre-commit' hook failed with error output: Traceback (most recent call last): File "/data/repos/projects/hooks/checkwhitespace.py", line 50, in ? run_app(main) File "/usr/lib/python2.3/site-packages/svn/core.py", line 33, in run_app return apply(func, (pool,) + args, kw) File "/data/repos/projects/hooks/checkwhitespace.py", line 32, in main if fs.node_prop(txn_root, path, 'svn:special') == '*': continue TypeError: svn_fs_node_prop() takes exactly 4 arguments (3 given) Any ideas? (CC me, I'm not on the list.) Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00

4 7

python/trunk/Lib/test/test_urllib.py (for ftpwrapper)
by ocean 28 May '07

28 May '07

# Sorry, I posted to inapropreate mailing list. (Python-3000) http://mail.python.org/pipermail/python-checkins/2007-May/060507.html Hello. I'm using Windows2000, I tried some investigation for test_ftpwrapper. After I did this change, most errors were gone. Index: Lib/urllib.py =================================================================== --- Lib/urllib.py (revision 55584) +++ Lib/urllib.py (working copy) @@ -833,7 +833,7 @@ self.busy = 0 self.ftp = ftplib.FTP() self.ftp.connect(self.host, self.port, self.timeout) - self.ftp.login(self.user, self.passwd) +# self.ftp.login(self.user, self.passwd) for dir in self.dirs: self.ftp.cwd(dir) I don't know, but probably 'login' on Win2000 is problamatic. Remaining error is: File "e:\python-dev\trunk\lib\threading.py", line 460, in __bootstrap self.run() File "e:\python-dev\trunk\lib\threading.py", line 440, in run self.__target(*self.__args, **self.__kwargs) File "test_urllib.py", line 565, in server conn.recv(13) error: (10035, 'The socket operation could not complete without blocking') And after commented out conn.recv block in test_urllib.py, test passed fine. def server(evt): serv = socket.socket(socket.AF_INET, socket.SOCK_STREAM) serv.settimeout(3) serv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) serv.bind(("", 9093)) serv.listen(5) try: conn, addr = serv.accept() conn.send("1 Hola mundo\n") """ cantdata = 0 while cantdata < 13: data = conn.recv(13-cantdata) cantdata += len(data) time.sleep(.3) """ conn.send("2 No more lines\n") conn.close() except socket.timeout: pass finally: serv.close() evt.set()

3 2