Mailman 3 April 2003 - Python-Dev

Re: [PythonLabs] Re: [Python-checkins] python/dist/src/Modules gcmodule.c,2.33.6.5,2.33.6.6
by Jeremy Hylton April 10, 2003

April 10, 2003

On Thu, 2003-04-03 at 23:37, Tim Peters wrote: > > ! next = gc->gc.gc_next; > > if (has_finalizer(op)) { > > gc_list_remove(gc); > > gc_list_append(gc, finalizers); > > gc->gc.gc_refs = GC_MOVED; > > } > > } > > } > > --- 277,290 ---- > > for (; gc != unreachable; gc=next) { > > PyObject *op = FROM_GC(gc); > > ! /* has_finalizer() may result in arbitrary Python > > ! code being run. */ > > if (has_finalizer(op)) { > > + next = gc->gc.gc_next; > > gc_list_remove(gc); > > gc_list_append(gc, finalizers); > > gc->gc.gc_refs = GC_MOVED; > > } > > + else > > + next = gc->gc.gc_next; > > } > > } > > Are we certain that has_finalizer() can't unlink gc itself from the > unreachable list? If it can, then > > > + else > > + next = gc->gc.gc_next; > > will set next to the content of free()ed memory. In fact, I believe the > Boom program will suffer this fate ... yup, it does. "The problem" isn't > yet really fixed in any version of Python, although I agree it's a lot > better with the change above. It looks like it's hard to find a place to stand. Since arbitrary Python code can run, then an arbitrary set of objects in the unreachable list can suddenly become unlinked. The previous, current, and next objects are all suspect. I think a safe approach would be to move everything out of unreachable and into either "collectable" or "finalizers". That way, we can do a while (!gc_list_is_empty(unreachable)) loop and always deal with the head of the unreachable list. Each time through the loop, the head of the list can be moved to collectable or finalizers or become unlinked, so we always make progress. Sound plausible? Jeremy

7 14

RE: Adding item in front of a list
by Tim Peters April 9, 2003

April 9, 2003

[Andrew Koenig, starting with l=[2, 3, 4]] > ... > I would have thought that after l.insert(-1, 1), l would be > [2, 3, 1, 4], but it doesn't work that way. Alas, list.insert() existed before sequence indices were generalized to give a "count from the right end" meaning to negative index values. When the generalization happened, it appears that list.insert() was just overlooked. I'd like to change this. If I did, how loudly would people scream? Guido says he also wishes list.insert() had been defined with the arguments in the opposite order, so that list.insert(object) could have a natural default index argument of 0. I'd like to change that too, but it's clearly too late for that one.

1 0

SF file uploads work now
by Neal Norwitz April 9, 2003

April 9, 2003

SF has fixed the problem which prevented a file from being uploaded when submitting a new patch. I just tested this and it worked. Neal

2 1

PEP305 csv package: from csv import csv?
by Hamish Lawson April 9, 2003

April 9, 2003

[Please excuse my posting this message here after initially posting it to python-list, but I realised afterwards that this might be the more appropriate forum (it hasn't so far had any responses on python-list anyway).] According to the documentation in progress at http://www.python.org/dev/doc/devel/whatsnew/node14.html use of the forthcoming csv module (as described in PEP305) requires it to be imported from the csv package: from csv import csv input = open('datafile', 'rb') reader = csv.reader(input) for line in reader: print line Is there some reason why the cvs package's __init__.py doesn't import the required names from cvs.py, so allowing the shorter form below? import csv input = open('datafile', 'rb') reader = csv.reader(input) for line in reader: print line Hamish Lawson

2 1

Re: [PythonLabs] Re: [Python-Dev] Re: [Python-checkins]python/dist/src/Modules gcmodule.c,2.33.6.5,2.33.6.6
by Jim Fulton April 8, 2003

April 8, 2003

Tim Peters wrote: ... > While a __getattr__ side effect may resurrect an object in gc's unreachable > list, gc has no way to know that an object has been resurrected short of > starting over again. In the absence of that, the object remains in gc's > unreachable list, and its tp_clear slot eventually gets called. The > internal C stuff remains self-consistent, so this won't cause a segfault > (etc), but it may (as above) be surprising. I don't see a sane way to fix > this so long as asking whether __del__ exists can execute arbitrary mounds > of Python code. If I understand the problem, it can be avoided by avoiding old-style classes. Maybe it's time to, at least optionally, cause a warning when old-style classes are used. :) I'm not kidding for Zope. I think it might be worth-while to be issue such a warning in Zope. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (703) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

4 3

LONG_LONG (Was: [Python-checkins] python/dist/src/Misc NEWS,1.703,1.704)
by Thomas Heller April 7, 2003

April 7, 2003

loewis(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Misc > In directory sc8-pr-cvs1:/tmp/cvs-serv28757/Misc > > Modified Files: > NEWS > Log Message: > Rename LONG_LONG to PY_LONG_LONG. Fixes #710285. > What is the recommended way to port code like this to Python 2.3, and still remain compatible with 2.2? Thanks, Thomas typedef struct { PyObject_HEAD char tag; union { char c; char b; short h; int i; long l; #ifdef HAVE_LONG_LONG LONG_LONG q; #endif double d; float f; void *p; } value; PyObject *obj; } PyCArgObject;

4 3

socket question
by Rick Y April 7, 2003

April 7, 2003

how can i enable _sockt module in my solaris python?. i did not build it. Downloaded it from sunfreeware. ./viewcvs-install Traceback (most recent call last): File "./viewcvs-install", line 35, in ? import compat File "./lib/compat.py", line 20, in ? import urllib File "/usr/local/lib/python2.1/urllib.py", line 26, in ? import socket File "/usr/local/lib/python2.1/socket.py", line 41, in ? from _socket import * ImportError: ld.so.1: python: fatal: libssl.so.0.9.6: open failed: No such file or directory __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

3 2

RE: [PythonLabs] Re: [Python-Dev] Re: [Python-checkins]python/dist/src/Modules gcmodule.c,2.33.6.5,2.33.6.6
by Tim Peters April 7, 2003

April 7, 2003

[Jim Fulton] > If I understand the problem, it can be avoided by avoiding > old-style classes. In Python 2.3, that appears to be true. In Python 2.2.2, not true. The problems are caused by __getattr__ hooks that resurrect unreachable objects, and/or remove the last reference to an unreachable object, when such a hook is on an instance reachable only from an unreachable cycle, and the class doesn't explicitly define a __del__ method, and the class has a getattr hook, and the getattr hook does extreme things instead of just saying "no, there's no __del__ here". Python 2.3 introduced new machinery for new-style classes specifically aimed at answering the "does it support __del__?" question without invoking getattr hooks, and that's why it's not a problem for new-style classes in 2.3. New-style classes still go thru getattr hooks to answer this question in 2.2.2. There were problem in Python and problems in Zope here. Jeremy fixed the Zope problems under 2.2 by breaking the and the getattr hook does extreme things instead of just saying "no, there's no __del__ here" link of the chain for persistent objects. > Maybe it's time to, at least optionally, cause a warning when > old-style classes are used. :) I'm not kidding for Zope. I think it > might be worth-while to be issue such a warning in Zope. There may be good reasons for wanting that, but none raised in this thread so far are relevant (unless 2.3 is mandated for Zope, which I'm sure we don't want to do).

1 0

Weekly Python Bug/Patch Summary
by Skip Montanaro April 6, 2003

April 6, 2003

Bug/Patch Summary ----------------- 384 open / 3510 total bugs (+7) 136 open / 2062 total patches (no change) New Bugs -------- test_zipimport failing on ia64 (at least) (2003-03-30) http://python.org/sf/712322 Cannot change the class of a list (2003-03-31) http://python.org/sf/712975 test_pty fails on HP-UX and AIX when run after test_openpty (2003-03-31) http://python.org/sf/713169 site.py breaks if prefix is empty (2003-04-01) http://python.org/sf/713601 Distutils documentation amputated (2003-04-01) http://python.org/sf/713722 cPickle fails to pickle inf (2003-04-03) http://python.org/sf/714733 bsddb.first()/next() raise undocumented exception (2003-04-03) http://python.org/sf/715063 pydoc support for keywords (2003-04-05) http://python.org/sf/715782 Minor nested scopes doc issues (2003-04-06) http://python.org/sf/716168 New Patches ----------- Bug fix 548176: urlparse('http://foo?blah') errs (2003-03-30) http://python.org/sf/712317 sre fixes for lastindex and minimizing repeats+assertions (2003-03-31) http://python.org/sf/712900 Fixes for 'commands' module on win32 (2003-04-01) http://python.org/sf/713428 rfc822.parsedate returns a tuple (2003-04-01) http://python.org/sf/713599 freeze fails when extensions_win32.ini is missing (2003-04-01) http://python.org/sf/713645 iconv_codec NG (2003-04-02) http://python.org/sf/713820 Unicode Codecs for CJK Encodings (2003-04-02) http://python.org/sf/713824 Guard against segfaults in debug code (2003-04-02) http://python.org/sf/714348 timeouts for FTP connect (and other supported ops) (2003-04-03) http://python.org/sf/714592 Document freeze process in PC/config.c (2003-04-03) http://python.org/sf/714957 Closed Bugs ----------- locale.getpreferredencoding fails on AIX (2003-01-31) http://python.org/sf/678259 configure option --enable-shared make problems (2003-03-11) http://python.org/sf/701823 -i -u options give SyntaxError on Windows (2003-03-21) http://python.org/sf/707576 Closed Patches -------------- sgmllib support for additional tag forms (2002-04-17) http://python.org/sf/545300 posixfy some things (2002-12-08) http://python.org/sf/650412 Add missing constants for IRIX al module (2003-01-13) http://python.org/sf/667548 Py_Main() removal of exit() calls. Return value instead (2003-01-21) http://python.org/sf/672053 fix for bug 672614 :) (2003-02-28) http://python.org/sf/695250 Wrong prototype for PyUnicode_Splitlines on documentation (2003-03-11) http://python.org/sf/701395 more apply removals (2003-03-11) http://python.org/sf/701494 Fix a few broken links in pydoc (2003-03-19) http://python.org/sf/706338 Adds Mock Object support to unittest.TestCase (2003-03-19) http://python.org/sf/706590 Make "%c" % u"a" work (2003-03-26) http://python.org/sf/710127 Backport to 2.2.2 of codec registry fix (2003-03-27) http://python.org/sf/710576 Obsolete comment in urlparse.py (2003-03-30) http://python.org/sf/712124

1 0

Re: Capabilities (we already got one)
by Michael Chermside April 4, 2003

April 4, 2003

> The objection to doing it the other way round is that for capability > languages to be truly usable the capability functionality needs to be > automatic, not something that is painfully added to each class or object > (at least, that is the claim we capability mavens are making). Just how strong a claim are you making here? It seems to me that the need for security (via capabilities or any other mechanism) is an UNUSUAL need. Most programs don't need it at all, others need it in only a few places. Now don't get me wrong... when you DO need it, you really need it, and just throwing something together without explicit language support is somewhere between impossible and terrifically-difficult-and-error-prone. So supporting secure execution (via capabilities or whatever) in the language is a great idea. And I like the capabilities-as-references approach... it's simple, elegant, and not error prone. But if you're going so far as to imply that capability functionality needs to be present ALWAYS, and supported (and considered) in every class or object, then that's going too far. A random module should, for instance, be able to open arbitrary files in the file system without being passed any special objects, UNLESS we do something special when we load it to indicate that we want it to run in a restricted mode. I think that zipfile is a good example here. As a library developer, I should be able to write and distribute a zipfile module without thinking about capabilities or security at all. Of course, when others go to use it in a secure or restricted mode, they may find that it isn't as useful as they'd like, but (I believe) we shouldn't say NO ONE can have a zipfile module unless the module author is willing to address security issues. Someone can write securezipfile when they get the itch. Now, if we really built security (via capabilities) into the language from the ground up, then ALL modules would work by being passed appropriate capability objects, and only the starting script would possess all capabilities. There would be no "file" builtin, just file objects (and ReadOnlyFile objects, and DirectorySubTree objects, and so forth) which got passed around. So OF COURSE the original author of zipfile would write it to accept a file at construction rather than allowing it to open files... that would be the natural way to do things. But that language isn't python... and I don't think it's worth changing Python enough to get there. So if you're proposing this drastic a change (which I doubt), then I think it's too drastic. But if you're NOT, then you have to realize that there will be lots of library modules like zipfile, which were written by people who didn't give any thought to security (since it's a rarely-used feature of the language). So we need workarounds (like wrappers or proxies) that can be applied after-the-fact to modules and classes that weren't written with security in mind. If that's "painfully adding something to each class or object", then I don't see how it's to be avoided. -- Michael Chermside

3 2