Mailman 3 January 2002 - Python-Dev

Re: [Python-Dev] Feature request: better support for "wrapper" objects
by Jack Jansen 12 Jan '02

12 Jan '02

Recently, "Thomas Heller" <thomas.heller(a)ion-tof.com> said: > Here's an outline which could work in 2.2: This sounds very good! There's only one thing you'll have to explain to me: how would this work from C? My types are all in C, not in Python, so I'd need to do the magic in C. Where do I find examples of using metatypes from C? I could then put all this wrapper stuff in a file WrapperObject.c and it would be reusable by any object that wanted this functionality. > Create a subtype of type, having a tp_convert slot: > > typedef int (*convert_func)(PyTypeObject *, void **); > > typedef struct { > PyTypeObject type; > convert_func tp_convert; > } WrapperTypeType; > > and use it as metaclass (metatype?) for your WindowObj: > > class WindowObj(...): > __metaclass__ = WrapperTypeType > > Write a function to return a conversion function: > > convert_func *get_converter(PyTypeObject *type) > { > if (WrapperTypeType_Check(type)) > return ((WrapperTypeType *)type)->tp_convert; > /* code to check additional types and return their converters */ > .... > } > > and then > > if (!PyArg_ParseTuple(args, "O&", get_converter(WinObj_Type), &Window)) > > How does this sound? > > Thomas > > -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

3 4

2.2c1 test on windows - ok
by Thomas Heller 11 Jan '02

11 Jan '02

installed from the windows installer - everything seems to be ok: 117 tests OK. 23 tests skipped: test_al test_cd test_cl test_crypt test_dbm test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp t est_imgfile test_largefile test_linuxaudiodev test_nis test_openpty test_poll test_pty test_pwd test_signal test_sockets erver test_sunaudiodev test_timing Thomas

3 3

PEP 100 references & wording
by Skip Montanaro 11 Jan '02

11 Jan '02

I just noticed that PEP 100 (Python/Unicode integration) references http://starship.python.net/~lemburg/unicode-proposal.txt as the latest version. Sure enough, I visited that and found that it's newer than the PEP (1.8 v. 1.7). Shouldn't the PEP be the most up-to-date public document? The comment right after that suggests this should be so: [ed. note: new revisions should be made to this PEP document, while the historical record previous to version 1.7 should be retrieved from MAL's url, or Misc/unicode.txt] Since this is now an informational PEP, I believe the wording should change to reflect functionality that has already been implemented. For instance, instead of Python should provide a built-in constructor for Unicode strings which is available through __builtins__: it should read Python provides a built-in constructor for Unicode strings which is available through __builtins__: Skip

3 3

eval() slowdown in 2.2 on MacOS X?
by Andrew Kuchling 11 Jan '02

11 Jan '02

[CC'ed to python-dev, Barbara Mattson] Barbara's encountered an apparent problem with test_longexp in Python 2.2 on MacOS X. test_longexp creates a big list expression and eval()'s it. The problem is that it takes an exceedingly long time to run, at least more than half an hour (at which point she interrupted it). The two curious things are that 1) while test_longexp requires a lot of memory and often thrashes on a low-memory machine (I found there are 2 or 3 bugs in the SF bugtracker to this effect), the MacOS box in question has a gigabyte of RAM, and 2) Python 2.1.1 *doesn't* show the problem. Quoting from her report: I tried the test_longexp by hand: REPS = XXX l = eval("[" + "2," * REPS + "]") print len(l) changing REPS from 1000 to 50000. 1000 and 10000 ran fairly quickly - under a minute. However, 25000 took about 5 minutes and 50000 took 23 minutes. I'm not about to try 65580 (I need to get some real work done today, after all :-). BTW, out of curiosity, I tried the same thing under 2.1.1, and even for REPS = 70000 it took less than a minute. Any clues? --amk (www.amk.ca) "Peri, how would you like to meet a genius?" "I thought I already have." -- The Doctor and Peri, in "Mark of the Rani"

4 9

2.1.2 testing.
by Anthony Baxter 11 Jan '02

11 Jan '02

Has anyone had a chance to test that 2.1.2 builds and works correctly on anything? I'm testing on the following systems. sourceforge compile farm boxes are marked as such, compaq testdrive boxes to arrive as well[1]. For each, a fresh cvs export, followed by ./configure ; make ; make test. Are there additional useful tests that could be run? Linux/x86 Redhat 6.2 PASSED Linux/x86 Redhat 7.1 PASSED Linux/x86 Redhat 7.2 PASSED Solaris/sparc 2.7 (gcc-2.95.2) PASSED Linux/x86 Debian 2.2 (cf.sf.net) PASSED Linux/PPC [RS/6000] Debian 2.2 (cf.sf.net) PASSED Linux/alpha Debian 2.2 (cf.sf.net) PASSED FreeBSD 4.4 (cf.sf.net) PASSED Solaris/sparc 2.8 (cf.sf.net) (gcc-2.95.2) PASSED Tru64/Alpha 4.0 (compaq) ... still building ... Tru64/Alpha 5.1 (compaq) ... to be done ... Linux/sparc Debian 2.2 (cf.sf.net) FAILED This is scary. I don't know why this one alone fails - it fails the test_math test. Running the test by hand: anthonybaxter@usf-cf-sparc-linux-1:~/python212_linxsparc$ PYTHONPATH= ./python ./Lib/test/test_math.py math module, testing with eps 1e-05 constants acos Traceback (most recent call last): File "./Lib/test/test_math.py", line 21, in ? testit('acos(-1)', math.acos(-1), math.pi) OverflowError: math range error Running math.acos(-1) gives the correct answer. Anyone got any idea? I couldn't get py212 to build on our remaining solaris/x86 box, but then I can't get 2.1.1 to build on it either, without a whole lot of manual hackery - so I don't care about that. It's just a stuffed machine. :) I was hoping to test on MacOS X, but the cf.sf.net boxes aren't answering... anyone else want to give it a go? Anthony [1] sheesh. had to install telnet for the compaq boxes. first time I've not had ssh access somewhere for a while. . . (plus, they don't have cvs. sigh.)

7 7

unicode/string asymmetries
by Thomas Heller 11 Jan '02

11 Jan '02

I noticed several unicode/string asymmetries: 1. No support for unicode in the struct and array modules. Is this an oversight? 2. What would be the corresponding unicode format character for 'z' in the struct module (string or None)? 3. There does not seem to be an equivalent to the 's' format character for PyArg_Parse() or Py_BuildValue(). Thomas

5 19

Re: [Python-Dev] unicode/string asymmetries
by Jack Jansen 11 Jan '02

11 Jan '02

> jack wrote: > > > struct.pack("32s", wu(u"VS_VERSION_INFO")) > > > > Why would you have to specify the encoding if what you want is the normal, > > standard encoding? > > because there is no such thing as a "normal, standard > encoding" for a unicode character, just like there's no > "normal, standard encoding" for an integer (big endian, > little endian?), a floating point number (ieee, vax, etc), > a screen coordinate, etc. What I here call the "normal, standard encoding" is what the C library supports. Your analogy of integers and floats is exactly the right one: even though there are many ways to represent an integer what you get back from PyArg_Parse("l") is a standard C "long". Maybe the confusion is that whereever I have said "unicode" in the past I should have said "wchar_t". I know there are, in theory, many encodings of Unicode but in practice there is only one that I'm interested in most of the time and that's wchar_t, because that's what all my APIs want. So, I would like PyArg_Parse/Py_BuildValue formats that are symmetric to "s", "s#" and "z" but that return wchar_t strings and that work with both UnicodeObjects and StringObjects. -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

4 9

Re: [Python-Dev] Feature request: better support for "wrapper" objects
by Jack Jansen 11 Jan '02

11 Jan '02

Recently, "Martin v. Loewis" <martin(a)v.loewis.de> said: > > Or, to make things clearer, WinObj_Type->tp_convert would simply > > point to the current WinObj_Convert function. > > So what do you gain with that extension? It seem all that is done is > you can replace _Convert by _Type everywhere, with no additional > change to the semantics. Because you can refer to the _Type from Python, that is the whole point of this exercise. And because you can refer to it from Python you can pass it to calldll.newcall and such. > > > > ps_GetDrawableSurface = calldll.newcall(psapilib.ps_GetDrawableSurface, > > > > Carbon.Qd.GrafPortType) > [...] > > Not at the moment, but in calldll version 2 there would be. In stead > > of passing types as "l" or "h" you would pass type objects to > > newcall(). Newcall() would probably special-case the various ints but > > for all other types simply call PyArg_Parse(arg, "O@", typeobj, > > &voidptr). > > I still don't understand. In your example, GrafPortType is a return > type, not an argument type. So you *have* an anything, and you *want* > the GrafPortType. How exactly do you use PyArg_Parse in that scenario? Sorry, you're right. My example was for a return value, so we're talking Py_BuildValue here. But this situation is equivalent to a GrafPort argument, where PyArg_Parse would be used. > Also, why would you use this extension inside newcall()? I'd rather > expect it in ps_GetDrawableSurface.__call__ instead (i.e. when you > deal with a specific call, not when you create the callable instance). Absolutely right, sloppy typing on my part. -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

2 1

RELEASED - Python 2.1.2c1
by Guido van Rossum 11 Jan '02

11 Jan '02

We've issued a release candidate of Python 2.1.2: http://www.python.org/2.1.2/ Our thanks go out to Anthony Baxter, who almost singlehandedly produced this release. We're planning a final release of 2.1.2 early next week, probably Tuesday night (Wednesday morning for Anthony :-). Please report any bugs you find to the bug tracker: http://sourceforge.net/bugs/?group_id=5470 This being a bugfix release, there are no exciting new features -- we just fixed a lot of bugs; a few are outlined below. For a complete list, please see: http://sourceforge.net/project/shownotes.php?release_id=69287 - The socket object gained a new method, 'sendall()'. This method is guaranteed to send all data - this is not guaranteed by the 'send()' method. See also SF patch #474307. The standard library has been updated to use this method where appropriate. - Fix for incorrectly swapped arguments to PyFrame_BlockSetup in ceval.c. This bug could cause python to crash. It was related to using a 'continue' inside a 'try' block. - The Python compiler package was updated to correctly calculate stack depth in some cases. This was affecting Zope Python Scripts rather badly. - Largefile support was added (but not on by default, you'll need to follow the instructions in the documentation of the posix module). --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Python-Dev] release for 2.1.2, plus 2.2.1...
by Jack Jansen 11 Jan '02

11 Jan '02

Recently, Anthony Baxter <anthony(a)interlink.com.au> said: > >>> Barry A. Warsaw wrote > > AB> Ok, I'd like to make the 2.1.2 release some time in the first > > AB> half of the week starting 7th Jan, assuming that's ok for the > > AB> folks who'll need to do the work on the PC/Mac packaging. > > I'm doing this this evening; i.e. now. And I'm not going to do a MacPython 2.1.2. The effort needed is too much, and people seem to be happy enough with 2.1.1 (most have switched to 2.2 anyway). Oh yes, Anthony: I tried the current 2.1.2 CVS on Mac OS X (unix-Python), and all problems appear to be solved. -- - Jack Jansen <Jack.Jansen(a)oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

1 0