Mailman 3 May 2001 - Python-Dev

PyChecker v0.5 released
by Neal Norwitz 29 May '01

29 May '01

I was finally able to get version 0.5 out. Just in case this is the first time you are seeing this message, or you forgot what PyChecker is: PyChecker is a tool for finding common bugs in python source code. It finds problems that are typically caught by a compiler for less dynamic languages, like C and C++. Because of the dynamic nature of python, some warnings may be incorrect; however, spurious warnings should be fairly infrequent. The highlights are that code at the module scope is now checked. There is still a problem with class variables and globals that are default parameter values. But other than that, there should be no more spurious Variable unused warnings. Code that makes PyChecker raise an exception should now be caught in most cases and this produces a warning. Please mail me if you find it blowing up on your code. The last line processed is shown in the warning, so if you include some context, I can hopefully fix the problem. Also, PyChecker should really use the files passed on the command line, even if it uses the same module name internally. So it will check your warn.py, not PyChecker's warn.py. Feedback, comments, criticisms, new ideas, better ideas, etc. are all greatly appreciated. Thanks for everyone who has taken the time to mail me. If you can think of common mistakes that are made that PyChecker doesn't find, please let me know. Here's the CHANGELOG: * Catch internal errors "gracefully" and turn into a warning * Add checking of most module scoped code * Add pychecker subdir to imports to prevent filename conflicts * Don't produce unused local variable warning if variable name == '_' * Add -g/--allglobals option to report all global warnings, not just first * Add -V/--varlist option to selectively ignore variable not used warnings * Add test script and expected results * Print all instructions when using debug (-d/--debug) * Overhaul internal stack handling so we can look for more problems * Fix glob'ing problems (all args after glob were ignored) * Fix spurious Base class __init__ not called * Fix exception on code like: ['xxx'].index('xxx') * Fix exception on code like: func(kw=(a < b)) * Fix line numbers for import statements PyChecker is available on Source Forge: Web page: http://pychecker.sourceforge.net/ Project page: http://sourceforge.net/projects/pychecker/ Neal -- pychecker(a)metaslash.com

1 0

Re: Time for the yearly list.append() panic
by Tim Peters 29 May '01

29 May '01

FYI, I checked in a variation (listobject.c) over the weekend. Win9x is ultimately hopeless, but we can grow a list there to about 35M elements now instead of crapping out at < 2M, and it's zippy the whole way until death. Win2K (and I *assume* WinNT) benefit much more, as non-linear behavior was obvious very early there. Now it's flat and fast until physical RAM is exhausted, and then it suffers looong (15-30 seconds) "hiccups" at resize points. Fred kindly confirmed that Linux isn't hurt. Its behavior looks the same as the new Win2K behavior, except that the Linux hiccups are much briefer (although still obvious when they occur). time-for-the-yearly-list.append()-celebration-ly y'rs - tim

1 0

Re: string repr in 2.1 (fwd)
by Thomas Wouters 29 May '01

29 May '01

Robin apparently ran into a real problem caused by the change in string repr() semantics. Now, arguably this is his own stupid fault <wink> (and indeed he argues that himself) but that doesn't mean we shouldn't take this into account. We could, for instance, revert 2.1.1 to the old behaviour, giving at least *someone* a reason to switch to 2.1.1 ;) Or we could decide what the string repr() change really wanted was just for the REPL to print it like this, in which case the displayhook should fix it, not string_repr. Opinions ? Ping, IIRC, this was your proposal, so yours would be especially valuable ;) ----- Forwarded message from Robin Becker <robin(a)jessikat.fsnet.co.uk> ----- Date: Tue, 29 May 2001 09:58:49 +0100 From: Robin Becker <robin(a)jessikat.fsnet.co.uk> To: Thomas Wouters <thomas(a)xs4all.net> Cc: python-list(a)python.org Subject: Re: string repr in 2.1 In message <20010529102414.P690(a)xs4all.nl>, Thomas Wouters <thomas(a)xs4all.net> writes >On Tue, May 29, 2001 at 12:47:39AM +0100, Robin Becker wrote: >> In article <slrn9h5m4o.1hk.scarblac(a)pino.selwerd.nl>, Remco Gerlich >> <scarblac(a)pino.selwerd.nl> writes > >> >Since 2.1, string repr uses heximal escapes instead of octal ones. > >> yes I guess all those *nix tools that like octal should be whipped and >> made to obey the malevolent dictator. > >Do you have tools you use to parse quoted (repr'd) Python strings that >handle octal correctly, but don't handle \x and \n\r escape codes ? Which >ones ? And were you aware that they were going to break sooner or later, >just because someone can prefer 'readable' escape codes and feed it that >instead ? :) > Yes I have such tools. One is called Acrobat Reader, another is traditional sed and awk. My dos grep doesn't seem to like hex, I suppose I must update it and all other tools. My C compiler understands octal and the newer ones do hex as well. I can read octal and do arithmetic in it probably easier than hex. I don't defend the octal representation it's just very widespread in the older tools. Our usage of repr was probably stupid as clearly repr can change. How I long for my 18-bit PDP-15 :) what happened to my 15 octal digit cdc! Oh woe is me! Where are the duo-decimal calculators of yore? -- Robin Becker ----- End forwarded message ----- -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 1

[Stackless] Stackless for 2.1: Progress Report (fwd)
by Skip Montanaro 29 May '01

29 May '01

I pass this along in case anyone here has some ideas for Jeff about how to workaround his problems with pyexpat.c. Skip

1 0

Killing threads
by aahz＠rahul.net 29 May '01

29 May '01

Okay, so we all know it isn't possible to kill threads cleanly and safely in any kind of cross-platform way. At the same time, a program that has a thread running haywire should be able to kill itself completely, so that a monitoring process can restart it. How hard would it be to do only that in a cross-platform way? I'm guessing that for Unix, we'd just send a hard signal (9 or 15). No clue what would need to happen for Windows and Mac. (This got brought up because I experimented with os._exit() as a possible solution, but that GPFs on Win98SE.) -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista I don't really mind a person having the last whine, but I do mind someone else having the last self-righteous whine.

3 6

Removing doc/howto on python.org
by Andrew Kuchling 29 May '01

29 May '01

Looking at a bug report Fred forwarded, I realized that after py-howto.sourceforge.net was set up, www.python.org/doc/howto was never changed to redirect to the SF site instead. As of this afternoon, that's now done; links on www.python.org have been updated, and I've added the redirect. Question: is it worth blowing away the doc/howto/ tree now, or should it just be left there, inaccessible, until work on www.python.org resumes? --amk

2 2

Comparison speed
by Martin v. Loewis 29 May '01

29 May '01

> Anybody care to take a stab at making the new richcmp and/or coerce > code ugly again? When stepping through the code, I also missed support for the relationship between identity and equality. E.g. in PyObject_RichCompare, I'd expect if (v == w) { switch (op) case Py_EQ:case Py_LE:case Py_GE: Py_INCREF(Py_True); return Py_True; case Py_NE:case Py_LT:case Py_GT: Py_INCREF(Py_False); return Py_False; } } That would not help in your case, of course. I don't even know how frequent comparing identical objects is in real life - but this is something that PyObject_Compare has that PyObject_RichCompare currently doesn't. Regards, Martin

9 46

file.writelines("foo\n","bar\n")
by Martin v. Loewis 29 May '01

29 May '01

When investigating calling conventions, I took a special look at METH_OLDARGS occurrences. While most of them look reasonable, file.writelines caught my attention. It has if (args == NULL || !PySequence_Check(args)) { PyErr_SetString(PyExc_TypeError, "writelines() argument must be a sequence of strings"); return NULL; } Because it is a METH_OLDARGS method, you can do f=open("/tmp/x","w") f.writelines("foo\n","bar\n") With my upcoming patches, I'd replace this with METH_O, making this call illegal. Does anybody see a problem with that change in semantics? Regards, Martin

5 5

Python 2.1.1
by Thomas Wouters 28 May '01

28 May '01

As those of you on python-checkins might have noticed ;) I started checking in Python 2.1.1 bufixes. I'd hoped to finish all of my backlog today, but unfortuantely I'm now called away on a suprise emergency meeting, so I'm not sure if I'll make it. The 2.1.1 tree is sort of an unstable state right now, I'll fix that today in any case, but after the meeting. (As for why I started doing it: I just spent about two weeks of digging through Pine sourcecode, and its imap server in particular, and I decided I deserved a break -- Python reads like a Heinlein novel, after pine code: readable, straight-forward, and just enough complexity to keep it entertaining :) -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

6 11

nested scopes and global: some corner cases
by Samuele Pedroni 28 May '01

28 May '01

Hi. Writing nested scopes support for jython (now it passes test_scope and test_future <wink>), I have come across these further corner cases for nested scopes mixed with global decl, I have tried them with python 2.1b1 and I wonder if the results are consistent with the proposed rule: a free variable is bound according to the nearest outer scope binding (assign-like or global decl), class scopes (for backw-comp) are ignored wrt this. (I) from __future__ import nested_scopes x='top' def ta(): global x def tata(): exec "x=1" in locals() return x # LOAD_NAME return tata print ta()() prints 1, I believed it should print 'top' and a LOAD_GLOBAL should have been produced. In this case the global binding is somehow ignored. Note: putting a global decl in tata xor removing the exec make tata deliver 'top' as I expected (LOAD_GLOBALs are emitted). Is this a bug or I'm missing something? (II) from __future__ import nested_scopes x='top' def ta(): x='ta' class A: global x def tata(self): return x # LOAD_GLOBAL return A print ta()().tata() # -> 'top' should not the global decl in class scope be ignored and so x be bound to x in ta, resulting in 'ta' as output? If one substitutes global x with x='A' that's what happens. Or only local binding in class scope should be ignored but global decl not? regards, Samuele Pedroni

6 12