Mailman 3 March 2002 - Python-Dev

"result type only depends on operand types"...?
by Alex Martelli 01 Apr '02

01 Apr '02

Back on March 10 in the thread on PEP 285 Guido wrote: """ This is a very general rule that I like a lot: that the type of a result should only depend on the type of the arguments, not on their values. I expect that this rule will make reasoning about programs (as in PsyCo or PyChecker) easier to do. I recently caved in and allowed an exception: 2**2 returns an int, but 2**-2 returns a float. This was a case of "practicality beats purity". I don't see True-1 in the same league though. """ And yet...: >>> type(2**10) <type 'int'> >>> type(2**100) <type 'long'> ...doesn't this apply to many operators on ints in 2.2? Yet _another_ (set of) exception(s) with practicality beating purity? Perhaps, but if a "very general rule" has so many exceptions in frequent and fundamental cases, is it a rule at all...? Alex

8 18

A Hygienic Macro System in Python?
by James_Althoff＠i2.com 01 Apr '02

01 Apr '02

Or ... invoke callable(): statement1 statement2 . . . statementn is syntax for: def temp(): statement1 statement2 . . . statementn callable(temp) del temp More generally, invoke expr-that-results-in-a-callable(a,b,c) lambda x,y,z: statement1 statement2 . . . statementn is syntax for: def temp(x,y,z): statement1 statement2 . . . statementn expr-that-results-in-a-callable(temp,a,b,c) del temp examples: invoke aquireLockAndDo(): sensitiveStuff() invoke withConnectionDo(): generateReport() invoke gui.showBusyCursorDuring(): doQuery() invoke gui.showStatusDuring(msg="Searching..."): doQuery() invoke gui.showBusyCursorDuring(): invoke gui.showStatusDuring(msg="Generating Report..."): invoke withConnectionDo(): generateReport() invoke button.setEventHandler() lambda event: print event Freely substitute any preferred keyword: "call", "run", etc. instead of "invoke". call aquireLockAndDo(): sensitiveStuff() run aquireLockAndDo(): sensitiveStuff() etc. Doesn't handle return values, but ... Jim

3 2

Moving forward on the object memory API
by Neil Schemenauer 01 Apr '02

01 Apr '02

It looks like Tim managed to work some magic and make pymalloc's free handle memory allocated by either the system allocator or pymalloc itself. That means we can make PyMem_DEL use the pymalloc's 'free' and make PyObject_NEW use pymalloc's 'malloc'. Here's my plan for making this happen: #define PyMem_MALLOC(n) malloc(n) #define PyMem_REALLOC(p, n) realloc((void *)(p), (n)) #define PyMem_FREE(p) free((void *)(p)) I think making PyMem_FREE call free() is safe. I haven't seen any extension modules allocate with PyObject_NEW and free with PyMem_FREE. We deprecate the PyMem_* functions. There's no need for them, IMHO: #define PyMem_Malloc PyMem_MALLOC #define PyMem_New PyMem_NEW #define PyMem_Resize PyMem_RESIZE #define PyMem_Free PyMem_DEL #define PyMem_Del PyMem_DEL /* See comment near MALLOC_ZERO_RETURNS_NULL in pyport.h. */ #define PyMem_Realloc(p, n) \ do { \ size_t _n = n; \ PyMem_REALLOC(p, _n ? _n : 1); \ } while (0) Next, we base PyObject_{MALLOC,REALLOC,FREE} on pymalloc. Basically: #ifdef WITH_PYMALLOC #define PyObject_MALLOC(n) _PyMalloc_Malloc(n) #define PyObject_REALLOC(op, n) _PyMalloc_Realloc((void *)(op), (n)) #define PyObject_FREE(op) _PyMalloc_Free((void *)(op)) #else #define PyObject_MALLOC(n) PyMem_MALLOC(n) #define PyObject_REALLOC(op, n) PyMem_REALLOC((void *)(op), (n)) #define PyObject_FREE(op) PyMem_FREE((void *)(op)) #endif PyMem_DEL and PyMem_Free need to call pymalloc: #define PyMem_DEL(op) PyObject_FREE(op) We go through the source and replace all the PyMem_* function calls with the equivalent PyMem_* macro calls and replace PyMem_DEL with PyMem_FREE. The recommended API for extension modules writers would be PyMem_{MALLOC,REALLOC,NEW,RESIZE,FREE}, PyObject_{New,NewVar,Del}, and PyObject_GC_{New,NewVar,Del}. Neil

4 24

pymalloc killer
by Tim Peters 31 Mar '02

31 Mar '02

Recall that pymalloc delegates requests for "not small" blocks to the system malloc. This means that when pymalloc's free() is called, it has to figure out whether the address passed to it was one it allocated itself, or came from the system malloc. It uses 64 bits of magical info to determine this, based in part on address calculation. Vladimir claimed, and I agreed, that the chance of making a mistake here was insignificant. However, the question remained whether a hostile user could study the source code to mount a successful attack. Alas, it turns out that's easy. The attached was my first brute-force try at tricking pymalloc via pure Python code, and should break it quickly (within a few seconds) on any 32-bit little-endian box. It usually dies with a memory fault. I've also seen it trigger a bogus "unhashable type" error, and most worrisome a "SystemError: unknown opcode" error (showing it's possible to mutate bytecode via driving pymalloc insane). I ran this on Win98SE, and it seems it's also possible to provoke pymalloc into convincing the OS that the computer's modem is permanently busy (! of course a reboot fixed that). Given that there are other ways to provoke Python into crashing (and some much easier than this way), I don't know how seriously to take this. Historically, I'm usually hugging the end of the "who cares?" scale (I'm not sure I've ever seen a system I couldn't crash with a little effort -- and I have no idea how to stop me, let alone someone who's really keen to do damage). Please fight amongst yourselves <wink>.

6 36

Re: [Python-Dev] 2.2.1 release mechanics
by Michael Hudson 31 Mar '02

31 Mar '02

Sean Reifschneider <jafo(a)tummy.com> writes: > On Sun, Mar 31, 2002 at 11:39:07PM +0100, Michael Hudson wrote: > >Cool. Does the timetable I posted suit you? I.e. will you be able to > >produce RPMs at the same time as Tim, Fred and Jack do their magic? > > >From noon GMT April 9 through April 10? Couldn't be any more ideal -- our > local hackingsociety.org meeting is the evening of April 9th, so I'll build > the release bits at the meeting... Excellent. > >The list of wizards is growing... > > I don't have time to do *HALF* the python community contributions I'd like > to... Of course not! I feel as if I've been doing Python related stuff more-or-less fulltime (don't tell my supervisor) for the last two weeks, and there's still an infinite amount of things I want to do... Cheers, M. -- Just point your web browser at http://www.python.org/search/ and look for "program", "doesn't", "work", or "my". Whenever you find someone else whose program didn't work, don't do what they did. Repeat as needed. -- Tim Peters, on python-help, 16 Jun 1998

1 0

Re: [Python-Dev] 2.2.1 release mechanics
by Michael Hudson 31 Mar '02

31 Mar '02

Sean Reifschneider <jafo-python-dev(a)tummy.com> writes: > On Sun, Mar 31, 2002 at 09:41:10PM +0100, Michael Hudson wrote: > >Oh, one other thing: RPMs. Are they going to happen? > > Definitely... Something has changed in the 2.2.1 release which has broken > the RPMs, but I will have them resolved probably later tonight. I hope to > have a .spec file for inclusion in the tar file, and will have Red Hat 7.2 > and 6.2 binary RPMs ready. I will also have some pages about them > (probably just the current one updated a bit) ready to go. Cool. Does the timetable I posted suit you? I.e. will you be able to produce RPMs at the same time as Tim, Fred and Jack do their magic? The list of wizards is growing... Cheers, M. -- (ps: don't feed the lawyers: they just lose their fear of humans) -- Peter Wood, comp.lang.lisp

2 1

Re: [Python-Dev] Removing METH_OLDARGS
by Neal Norwitz 31 Mar '02

31 Mar '02

Guido van Rossum wrote: > I did a grep for 'PyArg_Parse(' and found some other files, > e.g. Modules/arraymodule.c, Objects/fileobject.c and > Objects/stringobject.c. I forgot there is one case of METH_OLDARGS: file.readinto(). I didn't want to change this because I don't know how to use it and there is no test for it. If someone can give me a use-case, I can add a test and fix it. Neal

2 1

Unused PyArg_* functions
by Neal Norwitz 31 Mar '02

31 Mar '02

All of these functions are undocumented and used in exactly one place: Modules/glmodule.c. The functions are defined in Modules/cgensupport.c. They are not exported in Include/modsupport.h. PyArg_GetObject PyArg_GetLong PyArg_GetShort PyArg_GetFloat PyArg_GetString PyArg_GetChar PyArg_GetLongArraySize PyArg_GetShortArraySize PyArg_GetLongArray PyArg_GetShortArray PyArg_GetDoubleArray PyArg_GetFloatArray Are these generally useful? Are they used by extensions (other than gl)? Should they be moved to glmodule? PyArg_VaParse() is exported in modsupport, but it is neither used nor documented. Should I do leave it alone or remove it? Are there other simple cleanups that need/ought to get done? Neal

2 1

Re: [Python-Dev] 2.2.1 release mechanics
by Michael Hudson 31 Mar '02

31 Mar '02

Michael Hudson <mwh(a)python.net> writes: > I'm aware that I've not been great about keeping people up to date > about my timing plans for the last couple of releases, so I'd like to > be a little more organized this time. Oh, one other thing: RPMs. Are they going to happen? -- surely, somewhere, somehow, in the history of computing, at least one manual has been written that you could at least remotely attempt to consider possibly glancing at. -- Adam Rixey

2 1

Weekly Python Bug/Patch Summary
by Skip Montanaro 31 Mar '02

31 Mar '02

Bug/Patch Summary ----------------- 236 open / 2357 total bugs 95 open / 1401 total patches Closed Bugs ----------- tkfileDialog on NT makes float fr specif (2001-06-10) http://python.org/sf/431899 Problem with urllib and proxies / Win32 (2001-06-12) http://python.org/sf/432501 python20 dll not found (2001-07-24) http://python.org/sf/444129 Linking/compiling with DEBUG (2001-11-05) http://python.org/sf/478339 softspace confused in nested print (2001-11-09) http://python.org/sf/480215 GetFileSecurity returns wrong SID (2001-11-13) http://python.org/sf/481284 xml.AttributesImpl: __setitem__ undef. (2001-12-20) http://python.org/sf/495672 test_email assumes Unix uses NTP scale (2001-12-27) http://python.org/sf/497162 Python/Tkinter crashes (2002-01-08) http://python.org/sf/501022 pickle problems (with Boost.Python) (2002-01-10) http://python.org/sf/502085 GNU --option syntax not supported (2002-01-22) http://python.org/sf/507262 Solaris 2.7 make chokes. (2002-01-30) http://python.org/sf/510868 File inheritance across exec/spawn (2002-01-30) http://python.org/sf/510910 Method assignment inconsistency (2002-02-09) http://python.org/sf/515336 Python gettext doesn't support libglade (2002-02-12) http://python.org/sf/516412 Tix:NoteBook add/delete/add page problem (2002-02-12) http://python.org/sf/516703 have a way to search backwards for re (2002-02-12) http://python.org/sf/516762 Option processing in setup.cfg (2002-02-14) http://python.org/sf/517451 Installing Python 2.2 on Solaris 2.x (2002-02-14) http://python.org/sf/517704 Menus and winfo_children() KeyError (2002-02-15) http://python.org/sf/518283 make-pyexpat failed (2002-02-18) http://python.org/sf/519028 Regex object finditer not documented (2002-02-21) http://python.org/sf/520904 Python expects __eprintf on Solaris (2002-02-22) http://python.org/sf/521706 re module syntax documentation omission (2002-03-14) http://python.org/sf/529923 221 still doesn't work on OS 8.1 (2002-03-18) http://python.org/sf/531398 Build python fails after fpectl (2002-03-20) http://python.org/sf/532618 Complex power underflow raises exception (2002-03-21) http://python.org/sf/533198 not building on AIX (2002-03-21) http://python.org/sf/533306 2.2 on HP-UX 11 64-bit - longs crash (2002-03-22) http://python.org/sf/533632 CODESET Doesn't Infer ERA et al. (2002-03-23) http://python.org/sf/534153 New Bugs -------- Potential AV in vgetargskeywords (2002-03-24) http://python.org/sf/534347 remember to sync trees (2002-03-25) http://python.org/sf/534669 Removing _tkinter considered harmful (2002-03-25) http://python.org/sf/534748 profiling with xml parsing asserts (2002-03-25) http://python.org/sf/534864 new.instance() breaks with new classes (2002-03-26) http://python.org/sf/535170 super() broken with classmethods (2002-03-26) http://python.org/sf/535444 xml.sax memory leak with ExpatParser (2002-03-26) http://python.org/sf/535474 make fails at posixmodule.c (2002-03-26) http://python.org/sf/535545 threading.Lock().acquire bug (2002-03-27) http://python.org/sf/536017 pydoc getopt fails (2002-03-28) http://python.org/sf/536449 module array: C type descriptions wrong (2002-03-28) http://python.org/sf/536469 Docs for "es" and "et" confusing (2002-03-28) http://python.org/sf/536516 Closed Patches -------------- Include RLIM_INFINITY constant (2001-12-04) http://python.org/sf/489066 smtplib.py SMTP EHLO/HELO correct (2001-12-29) http://python.org/sf/497736 optimize attribute lookups (2002-01-11) http://python.org/sf/502415 demo warning for expressions w/no effect (2002-01-19) http://python.org/sf/505826 remove extra SET_LINENOs (2002-02-08) http://python.org/sf/514997 iterator for lineinput (2002-02-11) http://python.org/sf/516297 Fixes pydoc http/ftp URL matching (2002-02-25) http://python.org/sf/522587 Allow building python as shared library (2002-03-07) http://python.org/sf/527027 small seek tweak upon reads (gzip) (2002-03-22) http://python.org/sf/533482 Apply semaphore code to Cygwin (2002-03-22) http://python.org/sf/533681 New Patches ----------- PEP 263 phase 2 Implementation (2002-03-24) http://python.org/sf/534304 help asyncore recover from repr() probs (2002-03-25) http://python.org/sf/534862 2.2 patches for BSD/OS 5.0 (2002-03-26) http://python.org/sf/535335 string.zfill and unicode (2002-03-28) http://python.org/sf/536241 force gzip to open files with 'b' (2002-03-28) http://python.org/sf/536278 Comprehensibility patch (typeobject.c) (2002-03-28) http://python.org/sf/536407 patch for bug 462783 mmap bus error (2002-03-28) http://python.org/sf/536578 splitext performances improvement (2002-03-29) http://python.org/sf/536661 SimpleXMLRPCServer auto-docing subclass (2002-03-29) http://python.org/sf/536883 pymalloc for types and other cleanups (2002-03-29) http://python.org/sf/536909

1 0