Mailman 3 September 2000 - Python-Dev

_PyPclose
by Guido van Rossum 01 Sep '00

01 Sep '00

The _PyPclose fix looks good, Tim! The sad thing is that if they had implemented their own data structure to keep track of the mapping between files and processes, none of this would have been necessary. Look: _PyPopenProcs is a dictionary whose keys are FILE* pointers wrapped in Python longs, and whose values are lists of length 2 containing a process handle and a file count. Pseudocode: # global: _PyPopenProcs = None # in _PyPopen: global _PyPopenProcs if _PyPopenProcs is None: _PyPopenProcs = {} files = <list of files created> list = [process_handle, len(files)] for file in files: _PyPopenProcs[id(file)] = list # in _PyPclose(file): global _PyPopenProcs list = _PyPopenProcs[id(file)] nfiles = list[1] if nfiles > 1: list[1] = nfiles-1 else: <wait for the process status> del _PyPopenProcs[id(file)] if len(_PyPopenProcs) == 0: _PyPopenProcs = None This expands to pages of C code! There's a *lot* of code dealing with creating the Python objects, error checking, etc. I bet that it all would become much smaller and more readable if a custom C-based data structure was used. A linked list associating files with processes would be all that's needed. We can even aford a linear search of the list to see if we just closed the last file open for this process. Sigh. Maybe for another time. (That linked list would require a lock of its own. Fine.) --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

1 0

Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.200,2.201
by Thomas Wouters 01 Sep '00

01 Sep '00

On Thu, Aug 31, 2000 at 05:02:01PM -0700, Tim Peters wrote: > Log Message: > Supply missing prototypes for new Py_{Get,Set}RecursionLimit; fixes compiler wngs; > un-analize Get's definition ("void" is needed only in declarations, not defns, & > is generally considered bad style in the latter). Funny. I asked this while ANSIfying, and opinions where, well, scattered :) There are a lot more where that one came from. (See the Modules/ subdir <wink>) -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

RE: [Python-Dev] Namespace collision between lib/xml and site-pac kages/xml
by Favas, Mark (EM, Floreat) 01 Sep '00

01 Sep '00

Guido wrote: >I remember our group discussion about this. What's currently >implemented is what we decided there, based upon (Fred's >representation of) what the XML-sig wanted. So you don't like this >either, right? Hey - not so. I saw the original problem, asked about it, was told it would be discussed, heard nothing of the results of the disccussion, saw that I still had the same problem close to the release of 2.0b1, thought maybe it had slipped through the cracks, and asked again in an effort to help. I apologise if it came across in any other way. >I believe there are two conflicting desires here: (1) the standard XML >package by the core should be named simply "xml"; (2) you want the old >XML-sig code (which lives in a package named "xml" but installed in >site-packages) to override the core xml package. I'm happy with (1) being the standard XML package - I thought from Fred's original post that there might be some way of having both work together. >I don't think that's possible -- at least not without a hack that's >too ugly to accept. Glad to have this clarified. >You might be able to get the old XML-sig code to override the core xml >package by creating a symlink named _xmlplus to it in site-packages >though. Thanks for the suggestion - I'll try it. Since my code has to run on Windows as well, probably the best thing I can do is bundle up the xml-sig stuff in my distribution, call it something else, and get around it all that way. Mark

1 0

static int debug = 0;
by Jeremy Hylton 01 Sep '00

01 Sep '00

Quick note on BDFL-approved style for C code. I recently changed a line in gcmodule.c from static int debug; to static int debug = 0; The change is redundant, as several people pointed out, because the C std requires debug to be initialized to 0. I didn't realize this. Inadvertently, however, I made the right change. The preferred style is to be explicit about initialization if other code depends on or assumes that it is initialized to a particular value -- even if that value is 0. If the code is guaranteed to do an assignment of its own before the first use, it's okay to omit the initialization with the decl. Jeremy

3 3

Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.200,2.201
by Greg Stein 01 Sep '00

01 Sep '00

On Thu, Aug 31, 2000 at 05:02:01PM -0700, Tim Peters wrote: > Update of /cvsroot/python/python/dist/src/Python > In directory slayer.i.sourceforge.net:/tmp/cvs-serv20859/python/dist/src/Python > > Modified Files: > ceval.c > Log Message: > Supply missing prototypes for new Py_{Get,Set}RecursionLimit; fixes compiler wngs; > un-analize Get's definition ("void" is needed only in declarations, not defns, & > is generally considered bad style in the latter). wtf? Placing a void in both declaration *and* definition is "good style". static int foo(void) { ... } int bar() { ... } You're setting yourself up for inconsistency if you don't always use a prototypical definition. In the above example, foo() must be declared/defined using a prototype (or you get warnings from gcc when you compile with -Wmissing-prototypes (which is recommended for developers)). But you're saying bar() should *not* have a prototype. -1 on dropping the "void" from the definition. I disagree it is bad form, and it sets us up for inconsistencies. Cheers, -g -- Greg Stein, http://www.lyra.org/

3 2

test_popen2 broken on Windows
by Tim Peters 01 Sep '00

01 Sep '00

FYI, we know that test_popen2 is broken on Windows. I'm in the process of fixing it.

2 2

FW: test_largefile cause kernel panic in Mac OS X DP4
by Tim Peters 01 Sep '00

01 Sep '00

-----Original Message----- From: python-list-admin(a)python.org [mailto:python-list-admin@python.org]On Behalf Of Sachin Desai Sent: Thursday, August 31, 2000 2:49 AM To: python-list(a)python.org Subject: test_largefile cause kernel panic in Mac OS X DP4 Has anyone experienced this. I updated my version of python to the latest source from the CVS repository and successfully built it. Upon executing a "make test", my machine ended up in a kernel panic when the test being executed was "test_largefile". My configuration is: Powerbook G3 128M RAM Mac OS X DP4 I guess my next step is to log a bug with Apple. -- http://www.python.org/mailman/listinfo/python-list

2 2

ANNOUNCE: Distutils 0.9.2
by Greg Ward 01 Sep '00

01 Sep '00

...just in time for the Python 2.0b1 feature freeze, Distutils 0.9.2 has been released. Changes since 0.9.1: * fixed bug that broke extension-building under Windows for older setup scripts (not using the new Extension class) * new version of bdist_wininst command and associated tools: fixes some bugs, produces a smaller exeuctable, and has a nicer GUI (thanks to Thomas Heller) * added some hooks to 'setup()' to allow some slightly sneaky ways into the Distutils, in addition to the standard "run 'setup()' from a setup script" Get your copy today: http://www.python.org/sigs/distutils-sig/download.html Greg

1 0

Re: [Python-checkins] CVS: python/dist/src/Python ceval.c,2.200,2.201
by Greg Stein 01 Sep '00

01 Sep '00

On Thu, Aug 31, 2000 at 08:53:20PM -0400, Jeremy Hylton wrote: > Any opinion on whether the Py_SetRecursionLimit should do sanity > checking on its arguments? -1 ... it's an advanced function. It's the caller's problem if they monkey it up. Cheers, -g -- Greg Stein, http://www.lyra.org/

1 0