Mailman 3 May 2001 - Python-Dev

SF hacked
by Thomas Wouters 31 May '01

31 May '01

It *seems*, from this site: http://66.92.75.28/~vladimir/themes-org.html that SourceForge has been hacked, and more seriously than SF first admits (if I'm to believe the arrogant sprouting of some script-kiddie, anyway. :) And the same goes for apache.org, it looks like. Anyway, if anyone connected *from* any of sourceforge's machines to anywhere else, in the last couple of months, they'll be well advised to change their passwords and check for intruders. The same goes if you connect through ssh and (foolishly ;) allowed ssh-agent-forwarding to the SF machines. In that case, better check all the machines that ssh-agent would give you unpassworded access to for logins you don't recognize. The site above lists a number of sniffed passwords, in case you want to check, but there's no reason for the hacker not to have even more sniffed passwords lying about :) And if you have a login on apache.org, you probably want to change your password in any case.... the above listed site has what seems to be a copy of the shadow password file. -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 1

Iteration variables and list comprehensions
by David Beazley 30 May '01

30 May '01

I'm not sure if this has ever been brought up before (I don't recall seeing it), but I would like to throw out something that has been bugging me about list comprehensions for quite some time... First of all, I have to say that I've really grown to like list comprehensions a lot. In fact, I find myself using them in just about every Python program I've been writing since switching to Python 2.0. However, I've also been shooting myself in the foot a little more than usual due to the following issue: When I write a list comprehension like this: s = [ expr(x) for x in t ] it is *VERY* easy to overlook the fact that the iteration variable "x" is evaluated in the local scope (and replaces any previous binding to "x" that might have existed outside the context of the list comprehension). Because of this, I have frequently found myself debugging the following programming error: # Some loop for x in r: ... # bunch of statements ... s = [expr(x) for x in t] ... # Try to do something with x. # ???? What in the hell is wrong with my program ???? ... The main problem is that I conceptually tend to think of the list comprehension as being some kind of list operator where the index name is really one of the operands in some sense. Because of this, it is *VERY* easy to get in the habit of throwing list comprehensions all over the place, each of which uses a common index name like x,i,j, etc. Of course, this works just fine until you forget that you're also using x,i,j for some kind of loop variable someplace else :-). Therefore, I'm wondering if it would make any sense to make the iterator variables used inside of a list comprehension private in some manner--either through name mangling or some other technique? For example: s = [expr(x) for x in t] would get expanded into something roughly like this: s = [ ] for _mangled_x in t: s.append(expr(_mangled_x)) del _mangled_x Just as an aside, I have never intentionally used the iterator variable of a list comprehension after the operation has completed. I was actually quite surprised with this behavior the first time I saw it. I suspect most other programmers would not anticipate this side effect either. Comments? Cheers, Dave

8 12

scoping and list comprehensions
by Skip Montanaro 30 May '01

30 May '01

Regarding the issue of how list comprehensions should relate to their environment, perhaps instead of modifying list comprehensions to make them execute in new local scopes (or at least appear to) a better solution would be to allow a new local scope to be introduced inline, sort of like in C: { int i; for (i=0; i < 10; i++) { dostuffwith(i); } } While this might be used more for list comprehensions than other constructs, I'm sure people will find a way to (ab)use it for other things as well. I don't see an obvious way of adding such functionality to Python without introducing a new keyword though, which is going to make it difficult to get past Guido: l = [] scope: l = [i**2 for i in range(10)] print l Hmmm, wait a minute, what if you terminated a block introducer (if or while clause or try/except clauses) with something other than a colon? (I'm just thinking out loud, I don't think this is necessarily a good solution). if 1: # no new scope introduced l = [i**2 for i in range(10)] print l vs. if 1; # new scope introduced for enclosed block l = [i**2 for i in range(10)] print l That certainly has some line noise qualities about it, especially since colons and semicolons are visually so similar, but does offer an alternative to introducing a new keyword into the language. Hmmm, wait another minute, perhaps you could simply overload def: l = [] def: l = [i**2 for i in range(10)] print l There's also the problem of how to export results from the scope, though perhaps the new nested scope stuff provides a solution to that. (I've ignored them so far, so I can't tell...) Would it be possible for the compiler to recognize the degenerate def: and simply mangle any names that would clash instead of introducing an actual new execution frame? The above might be equivalent to l = [] l = [__mangled_i**2 for __mangled_i in range(10)] print l if 'i' already existed in the same scope. Just thinking out loud. I'm not sure any of these ideas is any better than the current state of affairs. Skip

2 1

Most recent documentation update
by Fred L. Drake, Jr. 30 May '01

30 May '01

One thing I forgot to mention in my announcement of the update to the development documnetation which I just posted is that I went ahead and converted all but one of the productions in the Reference Manual to the new markup. The print_stmt production, unfortunately, is given twice instead of using a single model for the statement. The formatting tools don't support that (yet), and it's not clear that they should. (No, Barry, don't go changing it...!) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations

2 1

[development doc updates]
by fdrake＠cj42289-a.reston1.va.home.com 30 May '01

30 May '01

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Update for development version of Python (2.2). This update substantially re-works the prototype support for productions of a formal grammar. They look better, support forward references to symbol definitions, and allow download of an all-text version of the complete grammar (with productions ordered the same way as they are in the documentation sources). "Documeting Python" now includes documentation for the LaTeX markup used to describe productions: http://python.sourceforge.net/devel-docs/doc/grammar-displays.html

1 0

Re: [Patches] [ python-Patches-428326 ] Timer class for threading
by Thomas Wouters 30 May '01

30 May '01

On Wed, May 30, 2001 at 02:16:31AM -0700, noreply(a)sourceforge.net wrote: > OK, I'm un-withdrawing this patch. Just had to get things > straight with our lawyer. The patch is released under the > following license (the X11 license with 4 extra paragraphs > of disclaimers :): > http://www.zoteca.com/opensource/LICENSE.txt This raises an interesting point. Do we want separate pieces of the Python distribution to have separate licences ? I'd point out that the zoteca licence isn't mentioned on the OSI site as an Approved Licence, and that the licence contains a copyright notice, but no clear statement whether it's allowed to copy the licence other than together with the piece of software it's distributed with. The easiest solution would of course be for Itamar to get his boss/lawyers to give us the right to relicence it under the PSF licence :) -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

3 2

Autoconf problems on BeOS
by M.-A. Lemburg 30 May '01

30 May '01

I have a bug report assigned to myself which really is more about autoconf than Unicode. The problem is that the SIZEOF_xxx tests cause the Metroworks compiler on BeOS to fail and this again causes these defines to be set to 0 ! Could someone with more autoconf experience please have a look ? https://sourceforge.net/tracker/?func=detail&aid=420416&group_id=5470&atid=… Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

1 0

Re: [Python-Dev] Re: [Patches] [ python-Patches-428326 ] Timer class for threading
by Jack Jansen 30 May '01

30 May '01

> On Wed, May 30, 2001 at 02:16:31AM -0700, noreply(a)sourceforge.net wrote: > > > OK, I'm un-withdrawing this patch. Just had to get things > > straight with our lawyer. The patch is released under the > > following license (the X11 license with 4 extra paragraphs > > of disclaimers :): > > http://www.zoteca.com/opensource/LICENSE.txt > > [...] > > The easiest solution would of course be for Itamar to get his boss/lawyers > to give us the right to relicence it under the PSF licence :) I think this is the only viable solution. If various parts of Python have different license agreements this may well be a reason for people not to use Python because the hassle of figuring out which pieces fit their own licensing policy. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

[development doc updates]
by fdrake＠cj42289-a.reston1.va.home.com 29 May '01

29 May '01

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Incremental update for development version of Python (2.2). Mostly small updates, but I've worked on new markup for grammar productions used in the Reference Manual. Currently, only the lexical productions in Chapter 2 of the manual have been converted to the new markup and layout. Please take a look and send comments to doc-sig(a)python.org; the first page containing these changes is at: http://python.sourceforge.net/devel-docs/ref/identifiers.html The changes needed to implement the markup have not been checked in yet, and there are some bugs in the implementation (both for HTML and PDF), but this should make the productions easier to navigate. I've tested the HTML version on Linux only with Mozilla 0.9, Opera 5.0b8, and Netscape Navigator 4.77. Navigator is definately lagging behind in CSS support! Also added Michel Pelletier's documentation for the HTMLParser module, with some small changes.

3 2

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