Mailman 3 October 2000 - Python-Dev

Re: [Python-checkins] CVS: python/dist/src/Modules cPickle.c,2.52,2.53
by Neil Schemenauer 06 Oct '00

06 Oct '00

On Wed, Oct 04, 2000 at 09:22:31AM -0700, Neil Schemenauer wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory slayer.i.sourceforge.net:/tmp/cvs-serv16887/Modules > > Modified Files: > cPickle.c > Log Message: > - Fix a GC bug caused by PyDict_New() failing. > > > Index: cPickle.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/cPickle.c,v > retrieving revision 2.52 > retrieving revision 2.53 > diff -C2 -r2.52 -r2.53 > *** cPickle.c 2000/09/07 14:35:37 2.52 > --- cPickle.c 2000/10/04 16:22:26 2.53 > *************** > *** 2876,2880 **** > Py_INCREF(cls); > UNLESS (inst->in_dict=PyDict_New()) { > ! Py_DECREF(inst); > goto err; > } > --- 2876,2881 ---- > Py_INCREF(cls); > UNLESS (inst->in_dict=PyDict_New()) { > ! inst = (PyInstanceObject *) PyObject_AS_GC(inst); > ! PyObject_DEL(inst); > goto err; > } I aways seem to think harder when reviewing a commit message than a diff. :( I just realized that this commit subtly modifies cPickle's behavior. Before the change instances __del__ methods would be called if allocating __dict__ failed. After the change they are not. I think the new behavior is better but the question is will it break existing code? I think probably not. BTW, pickle seems to follow the new behavior. Neil

2 1

select, signals, and "interrupted system call" (EINTR)
by Jim Fulton 06 Oct '00

06 Oct '00

If a select-based (or, presumably, poll-based) server wants to use signals for anything other than shutdown (e.g. closing and reopening log files, rereading configs, etc.), then, on some platforms, a select call can fail with an "interrupted system call" (EINTR) error that should be ignored. The asyncore main loop should check for this error in it's select call and the select module should make this error easier to check for. In Python 1.5.2, the medusa select call can be changed from r,w,e = select.select (r,w,e, timeout) to: while 1: try: r,w,e = select.select (r,w,e, timeout) except select.error, v: if v[0] != EINTR: raise else: break I presume that this works in Python 1.6/2.0, but I haven't tried it yet? This depends on the structure of select.error values and requires that we get EINTR from somewhere. (What should the value be on NT?) I wonder if there should be an InterruptedSystemCall exception somewhere that select raises in this case? At a minimum, code like the above should be added to asyncore. Thoughts? Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

2 2

Proposal -- makefile patches and scripts to generate python RPMs
by Eric S. Raymond 05 Oct '00

05 Oct '00

In the course of maintaining fetchmail, I've developed effective techniques for integrating RPM and lsm generation into the release machinery of a package. I'm willing to do this for Python; it will involve adding a makefile production and a couple of scripts to the distribution. The benefit would be that we could generate correct RPMs automatically and ship them with each release. I think RPM is a sufficiently important distribution format to justify this effort. Comments? -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The prestige of government has undoubtedly been lowered considerably by the Prohibition law. For nothing is more destructive of respect for the government and the law of the land than passing laws which cannot be enforced. It is an open secret that the dangerous increase of crime in this country is closely connected with this. -- Albert Einstein, "My First Impression of the U.S.A.", 1921

8 10

Release candidate schedule
by Jeremy Hylton 05 Oct '00

05 Oct '00

There are still a number of open bugs that need to be addressed before we can issue a release candidate. We plan to issue the release candidate on Monday and the final release a week later. According to the Sourceforge bug report -- http://sourceforge.net/bugs/reporting/?group_id=5470&run_report=1&tech=1 -- the following people still have open bugs: akuchlin (3) bwarsaw (3) dcjim (2) effbot (5) fdrake (4) gvanrossum (12) gward (1) jackjansen (1) jhylton (8) lemburg (2) mhammond (5) nascheme (3) tim_one (5) I don't expect that every bug will be closed before 2.0 final, but there are some open bugs about test failures and build problems with 2.0 beta releases. We should address these if at all possible. Please review your open bugs and make sure you aren't forgetting about something. If you have bugs that will not be fixed for 2.0, make sure they have a fairly low priority. If you have bugs you will not be able to address, assign them to me. Jeremy

1 0

Stackless Python Mailing List
by Christian Tismer 05 Oct '00

05 Oct '00

Hi Pythoneers (without or not without Stack (yet:)) there have been a couple of interviews, and some articles on Stackless Python are published or in preparation. I recognize an increasing number of individual emails concerning Stackless Python. This lets me take the opportunity to start a mailing list on Stackless Python, an overdue task. The goal of this list is two-fold: On the one hand, people should have a forum to discuss their use of SLP, its further development, concurrency in general, and more. The other reason is to increase the support for SLP, with the final goal to get it merged into Standard Python. There are a couple of ways to help me with that, see http://starShip.python.net/mailman/listinfo/stackless Everybody who is interested in Stackless Python and all the related topics may feel invited to join this discussion group. cheers - chris -- Christian Tismer :^) <mailto:tismer@appliedbiometrics.com> Applied Biometrics GmbH : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com

1 0

irritating 'No such file or directory' message (was Re: [Python-checkins] CVS: python/nondist/peps pep-0004.txt,NONE,1.1)
by pf＠artcom-gmbh.de 05 Oct '00

05 Oct '00

Hi, Barry Warsaw : > Update of /cvsroot/python/python/nondist/peps > In directory slayer.i.sourceforge.net:/tmp/cvs-serv14669 > > Added Files: > pep-0004.txt > Log Message: > Added PEP 4, Deprecation of Standard Modules, Martin von Loewis > > > ***** Error reading new file: (2, 'No such file or directory') Whenever Barry adds a new file to the CVS, its initial content is invisible on the checkins mailing list due to the error message above. However if for example fdrake adds a new file (for example the support.py recently added to the doc subtree) then this doesn't happen. Is there anybody out there able to fix this for future checkins-mails? Regards, Peter

3 3

change to Lib/popen2.py break test_popen2 on windows
by Trent Mick 05 Oct '00

05 Oct '00

Fred's checkin: http://www.python.org/pipermail/python-checkins/2000-September/008355.html breaks test_popen2.py on windows. This is because test_popen2.py attempts to refer to popen2's internal '_active' variable, which is now explicitly deleted on Windows platforms. test_popen2.py should be updated for the new popen2 semantics. sorry-no-patch-ly yours, Trent -- Trent Mick TrentM(a)ActiveState.com

2 2

pep42 procedure?
by Mark Hammond 05 Oct '00

05 Oct '00

Please excuse my ignorance... I am in the process of applying the patch to prevent 1.5/1.6 extensions crashing 2.0 under Windows. Based on the feedback here (ie, "this should be a short term patch"), the various other patches that try to do the same thing, and the belief by some that we should be more like Unix anyway, I believe we should try and capture this entire issue in a more formal manner. The 2 logical places would be as a bug, and in pep42. However, after applying this patch, it doesnt really qualify as a bug! Putting it in pep42 is slightly suspect, as it is not a thought-out feature request yet - however, I believe capturing it there, with links to the relevant patches and discussions would be valuable. So, assuming this sounds reasonable - a bug, or pep42? If pep42, what is the procedure for changing it? I couldnt find it (or any pep) in the CVS repository, and the source-force pages would show me the peps, but not their source. I do remember seeing this mentioned some time ago, but can't locate that mail either... Thanks, Mark.

5 5

Installing python in /usr/bin
by Ka-Ping Yee 04 Oct '00

04 Oct '00

The cgi.py discussion brought my attention to this comment from Guido: > No, no, no! The /usr/bin/env form *fails* on most platforms (except > Linux) because Python is not installed in any of the default "bin" > directories -- /usr/local/bin is the standard install place and that's > not in the default path. So the natural question to ask is -- why not install Python in /usr/bin like everyone else? Perhaps a while ago Python wasn't popular enough to belong in /usr/bin and decided to modestly stay out of the way in /usr/local/bin instead? But by now, i think it's quite qualified to take its seat in /usr/bin along with all the other standard Unix binaries like /usr/bin/vi, /usr/bin/ftp, /usr/bin/perl, etc. Python *should* be in the default binary directory. Your thoughts? -- ?!ng

3 2

CIV
by Tim Peters 04 Oct '00

04 Oct '00

No, that's not 104, it's a Call for Indentation Volunteers! An item that mistakenly got dropped on the floor before 2.0b1 was to ensure that the standard Python libraries follow the recommended "4-space indents, no hard tabs" guideline. Since 100s of files (especially older ones in oddball directories) are affected, I moved that it into PEP42 rather than risk destabilizing the release after 2.0b1. So it will happen instead soon after 2.0final is released. I looked at existing tools for doing this, and found they all left way too much manual fiddling to bear, too prone to screw up on comment lines (e.g., try running your favorite tool over pindent.py: does the output bear any resemblance to the input?! The Emacs pymode does OK there because pindent comments match its conventions for "indenting comment lines", but nothing else even gets close; OTOH, if 1: # some insane people like # writing comments # like this too and nobody knows what to do about that). Attached is a new tool that tries much harder to get perverse comments right (everything else is easy). Try it and gripe at will. Since I wrote it while on vacation, it's public domain <0.5 wink>. regularly y'rs - tim #! /usr/bin/env python # Released to the public domain, by Tim Peters, 03 October 2000. """reindent [-d][-r][-v] path ... -d Dry run. Analyze, but don't make any changes to, files. -r Recurse. Search for all .py files in subdirectories too. -v Verbose. Print informative msgs; else no output. Change Python (.py) files to use 4-space indents and no hard tab characters. Also trim excess whitespace from ends of lines, and empty lines at the ends of files. Ensure the last line ends with a newline. Pass one or more file and/or directory paths. When a directory path, all .py files within the directory will be examined, and, if the -r option is given, likewise recursively for subdirectories. Overwrites files in place, renaming the originals with a .bak extension. If reindent finds nothing to change, the file is left alone. If reindent does change a file, the changed file is a fixed-point for reindent (i.e., running reindent on the resulting .py file won't change it again). The hard part of reindenting is figuring out what to do with comment lines. So long as the input files get a clean bill of health from tabnanny.py, reindent should do a good job. """ import tokenize import os import sys verbose = 0 recurse = 0 dryrun = 0 def errprint(*args): sep = "" for arg in args: sys.stderr.write(sep + str(arg)) sep = " " sys.stderr.write("\n") def main(): import getopt global verbose, recurse, dryrun try: opts, args = getopt.getopt(sys.argv[1:], "drv") except getopt.error, msg: errprint(msg) return for o, a in opts: if o == '-d': dryrun += 1 elif o == '-r': recurse += 1 elif o == '-v': verbose += 1 if not args: errprint("Usage:", __doc__) return for arg in args: check(arg) def check(file): if os.path.isdir(file) and not os.path.islink(file): if verbose: print "listing directory", file names = os.listdir(file) for name in names: fullname = os.path.join(file, name) if ((recurse and os.path.isdir(fullname) and not os.path.islink(fullname)) or name.lower().endswith(".py")): check(fullname) return if verbose: print "checking", file, "...", try: f = open(file) except IOError, msg: errprint("%s: I/O Error: %s" % (file, str(msg))) return r = Reindenter(f) f.close() if r.run(): if verbose: print "changed." if dryrun: print "But this is a dry run, so leaving it alone." if not dryrun: bak = file + ".bak" if os.path.exists(bak): os.remove(bak) os.rename(file, bak) if verbose: print "renamed", file, "to", bak f = open(file, "w") r.write(f) f.close() if verbose: print "wrote new", file else: if verbose: print "unchanged." class Reindenter: def __init__(self, f): self.find_stmt = 1 # next token begins a fresh stmt? self.level = 0 # current indent level # Raw file lines. self.raw = f.readlines() # File lines, rstripped & tab-expanded. Dummy at start is so # that we can use tokenize's 1-based line numbering easily. # Note that a line is all-blank iff it's "\n". self.lines = [line.rstrip().expandtabs() + "\n" for line in self.raw] self.lines.insert(0, None) self.index = 1 # index into self.lines of next line # List of (lineno, indentlevel) pairs, one for each stmt and # comment line. indentlevel is -1 for comment lines, as a # signal that tokenize doesn't know what to do about them; # indeed, they're our headache! self.stats = [] def run(self): tokenize.tokenize(self.getline, self.tokeneater) # Remove trailing empty lines. lines = self.lines while lines and lines[-1] == "\n": lines.pop() # Sentinel. stats = self.stats stats.append((len(lines), 0)) # Map count of leading spaces to # we want. have2want = {} # Program after transformation. after = self.after = [] for i in range(len(stats)-1): thisstmt, thislevel = stats[i] nextstmt = stats[i+1][0] have = getlspace(lines[thisstmt]) want = thislevel * 4 if want < 0: # A comment line. if have: # An indented comment line. If we saw the same # indentation before, reuse what it most recently # mapped to. want = have2want.get(have, -1) if want < 0: # Then it probably belongs to the next real stmt. for j in xrange(i+1, len(stats)-1): jline, jlevel = stats[j] if jlevel >= 0: if have == getlspace(lines[jline]): want = jlevel * 4 break if want < 0: # Maybe it's a hanging # comment like this one, # in which case we should shift it like its base # line got shifted. for j in xrange(i-1, -1, -1): jline, jlevel = stats[j] if jlevel >= 0: want = have + getlspace(after[jline-1]) - \ getlspace(lines[jline]) break if want < 0: # Still no luck -- leave it alone. want = have else: want = 0 assert want >= 0 have2want[have] = want diff = want - have if diff == 0 or have == 0: after.extend(lines[thisstmt:nextstmt]) else: for line in lines[thisstmt:nextstmt]: if diff > 0: if line == "\n": after.append(line) else: after.append(" " * diff + line) else: remove = min(getlspace(line), -diff) after.append(line[remove:]) return self.raw != self.after def write(self, f): f.writelines(self.after) # Line-getter for tokenize. def getline(self): if self.index >= len(self.lines): line = "" else: line = self.lines[self.index] self.index += 1 return line # Line-eater for tokenize. def tokeneater(self, type, token, (sline, scol), end, line, INDENT=tokenize.INDENT, DEDENT=tokenize.DEDENT, NEWLINE=tokenize.NEWLINE, COMMENT=tokenize.COMMENT, NL=tokenize.NL): if type == NEWLINE: # A program statement, or ENDMARKER, will eventually follow, # after some (possibly empty) run of tokens of the form # (NL | COMMENT)* (INDENT | DEDENT+)? self.find_stmt = 1 elif type == INDENT: self.find_stmt = 1 self.level += 1 elif type == DEDENT: self.find_stmt = 1 self.level -= 1 elif type == COMMENT: if self.find_stmt: self.stats.append((sline, -1)) # but we're still looking for a new stmt, so leave # find_stmt alone elif type == NL: pass elif self.find_stmt: # This is the first "real token" following a NEWLINE, so it # must be the first token of the next program statement, or an # ENDMARKER. self.find_stmt = 0 if line: # not endmarker self.stats.append((sline, self.level)) # Count number of leading blanks. def getlspace(line): i, n = 0, len(line) while i < n and line[i] == " ": i += 1 return i if __name__ == '__main__': main()

1 0