Mailman 3 July 2000 - Python-Dev

Re: [Python-Dev] extended slicing for lists
by Michael Hudson Aug. 1, 2000

Aug. 1, 2000

The patch is here, btw: http://sourceforge.net/patch/?func=detailpatch&patch_id=100998&group_id=5470 Ka-Ping Yee <ping(a)lfw.org> writes: > On 28 Jul 2000, Michael Hudson wrote: > > >>> l = range(10) > > >>> l[2:10:2] = [0]*5 > > >>> l > > [0, 1, 0, 3, 0, 5, 0, 7, 0, 9] > > >>> > > Hmph. I'd be perfectly comfortable with > > >>> l[2:10:2] = [0]*5 > TypeError: lists cannot assign to stepped slices > > I can't see this being a commonly desired feature. If it > were perfectly clear what should happen in all cases, i'd > be okay with it -- but the ambiguity you get when the length > of the right side doesn't match the length of the indicated > slice is sufficient for me to suggest just dropping it: > better to avoid confusion altogether. Well, the BDFL spoke. > > (and presumably del l[a:b:c]) > > That seems reasonable and well-defined. Yes. > A separate question: does l[::-1] return l reversed? Yes. All that cleverness is in PySlice_GetIndices, so this patch gets it for free. > That is, are the defaults for omitted start/end exchanged if step is > negative? This would seem to be quite useful -- having to say > l[len(l)-1:-1:-1] would be a royal pain. Well, you could probably always say l[sys.maxint:0:-1] (your example returns the empty list!) but yes, I think l[::-1] is one of the neater bits of new behaviour. Cheers, M. -- "declare"? my bogometer indicates that you're really programming in some other language and trying to force Common Lisp into your mindset. this won't work. -- Erik Naggum, comp.lang.lisp

5 4

test_re fails with re==pre
by Jack Jansen Aug. 1, 2000

Aug. 1, 2000

Test_re now works fine if re is sre, but it still fails if re is pre. Is this an artifact of the test harness or is there still some sort of incompatibility lurking in there? -- 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/ ++++

2 1

Re: [Python-Dev] test turds?
by Jack Jansen July 31, 2000

July 31, 2000

Recently, Trent Mick <trentm(a)ActiveState.com> said: > test_support.TESTFN is a test filename that is intended to be used by Python > test scripts. Currently it is just the file '@test' in the current directory. > A better mechanism might be to use the tempfile.mktemp() module and function. test_dbm.py (and possibly a few others) use /tmp/delete_me. This leaves a nasty turd on the Mac if the test fails. (Nasty because a file called /tmp/delete_me in the Python home directory confuses the hell out of cvs:-) -- 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

1 0

test turds?
by Moshe Zadka July 31, 2000

July 31, 2000

Hi! Recently I patched a bug in whichdb. Following Tim's advice "each bug we find is a bug in the regression testing", I decided to write a test case for whichdb. However, the problem is that I'm not sure where I can create files, which must not be leftovers from the test suite. Does anyone know of a test which creates files, and how it deals with them? Thanks. awake-when-it's-night-in-*civilized*-places-ly y'rs, Z. -- Moshe Zadka <moshez(a)math.huji.ac.il> There is no IGLU cabal. http://advogato.org/person/moshez

2 1

SF bug tracker
by Jeremy Hylton July 31, 2000

July 31, 2000

Which interface do you like better: the SourceForge bug tracker or Jitterbug? I am leaning towards moving the bug database from Jitterbug at python.org to SF. The advantages of moving to SF are: - bugs, patches, and CVS all managed by the same service - bugs can be assigned to specific people for resolution - cleaner interface for searching bugs - bugs can be assigned a priority The primary disadvantage of SF is email support. Jitterbug can receive comments about a bug via email and add them to its database. The SF bug tracker does not. It works like the patch manager, requiring you to use the Web interface to add more information. The SF bug tracker will send an email message every time a bug entry is updated, but that's it. Please let me know what you think. Jeremy

4 3

Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.15,1.16
by Jeremy Hylton July 31, 2000

July 31, 2000

Barry, A couple of suggestions on assigning PEP numbers: Let's require at least an abstract before we assign a number. We've got a bunch of PEPs that have been assigned and never touched; all they've got is a title and a name. If we have an abstract, non-experts and non-channelers have a better chance of figuring out what the PEP is. We might also think about a deadline or time limit. If a PEP has no activity for N days (90?), it is automatically changed to status deferred. After it has been deferred, we can assign it to a new author. There's not much point in making a big list of topics that people would like to write about some day if they get the time. It looks like we now have seven PEPs with only a name and title. Jeremy

2 1

Internet Groupware for Scientific Collaboration
by Greg Wilson July 31, 2000

July 31, 2000

[Not strictly related to Python development, but likely to be of interest to many readers of this list.] Jon Udell (architect of www.byte.com and O'Reilly's new Safari site, author of "Practical Internet Groupware", a Python fan) has prepared a report for Software Carpentry called "Internet Groupware for Scientific Collaboration". It is on-line at: http://www.software-carpentry.com/Groupware/report.html Hope you enjoy it, Greg Wilson

1 0

Re: doctest.py and testing frameworks (was Re: [Python-Dev] Fire, may I present accellerant. Accellerant, thi...)
by pf＠artcom-gmbh.de July 31, 2000

July 31, 2000

Hi, Mitchell Morris wrote to me: > Peter: > > Thanks for reading my post, and I especially appreciate your taking > the time and effort to respond. I also appreciate that you didn't take > me to task for using "it's" instead of "its" as the possessive form. > (I've been completely reeducated now, I assure you). As I'm not > currently a subscriber to python-dev, I don't know if this should > have been replied to the list or directly to you, so I'm sending it to > you only. If you feel it appropriate, please redistribute it as you > wish. [...I wrote to Mitchell:...] > > I've used doctest in my own code and found the idea to integrate > > test cases as sequences of calling code and expected result tuples > > as documentation (exmaples of use) into the doc string of modules, > > classes and methods very appealing. > > > > However this promising approach needs further work: Especially > > GUI parts can't be tested this way and in larger contexts, it > > is indeed very tedious to place *all* test code into doc strings. > > Often you need to prepare a defined starting point for the tests > > of several methods. It is not easy to decide, where to put this. > > I used doctest rather extensively a little while ago, but it was only > the vanilla variant originally posted by Tim. I thought it was really an > excellent work, but ran into similar stumbling blocks. The largest > issue for me was the aggregation of several modules worth of tests > into larger chunks, but I now know (from what I had to build to > complete the test plan I was working with) that I would very shortly > have run into the problems of replicating the test environment: > preparing input files/directories/databases, creating all the > supplementary bits and pieces, etc ad nauseam. > > A secondary issue which none of these tools address yet, but I feel > will be significant eventually, is the explicit naming of inter-test > dependence. If my class B tests require using some functionality > from class A, I would want the A tests to succeed before trying the > B tests at all (assuming I'm going to run both A and B in a single > iteration). I suspect, then, that one of these candidates will require > additional work to be our complete solution; I want to make sure > that I/we are working on the best candidate possible before > spending the effort. > > > > > again, additional effort could obviously provide the missing > > > functionality. On the other hand, doctest.py isn't currently > > > part of the standard distribution. > > > > Yes. :-( > > This, I feel, represents a significant problem. We should have a > testing framework as part of the core distribution. I agree. > We have HTML > tokenizing, mail sending, RFC822 parsing, /bin/sh-like lexing, etc > etc but don't feel that providing test support to our community of > developer is appropriate? Bizarre. Perhaps even more bizarre is > that there is a non-trivial regrtest.py that is part of the distribution, > but it's hidden away and not documented. Perhaps because no one volunteered to write documentation for it. Writing docs is an tedious task especially if you are no native english speaker. > I think we are not > providing all the service to the Python community that we could > and should. You are welcome to do something about this. > One of the strengths of Python, in my experience, has been the > ease with which code is written. This makes it much easier to > convince yourself and others to refactor mercilessly; the kinds of > cruft that grow on C++ solutions are rarely seen in Python code > because we can repartition and rewrite our work much more easily. > Providing a standard means to verify functionality before refactoring > makes it much safer to proceed, since we can "prove" (for a very > loose definition of "prove") that we haven't broken anything that > anybody else cares about. I think this is a direction we should > encourage, both through example and explicit > direction/documentation. > > > > I attach my version of 'doctest' to this email. Do what you want with it. > > Currently I favour 'doctest' over 'pyunit'. > > If you don't mind, could you elaborate why you prefer doctest, or at > least what you find unpleasant about pyunit? I would like to include > this in the document for future reference, and you may even > convince me to change my vote for doctest.py instead. I must admit that I didn't had a look at PyUnit since January. I've just downloaded pyunit-1.2.0 and had a closer look at it. Nevertheless it is very hard to beat the elegance of Tim Peters approach to cut'n'paste test cases from the interpreter prompt. Although you usually get 2 lines for each test case, building the test cases is much easier in the first place. May be both approaches to unit testing can be integrated somehow? Steal the concept of 'fixtures' from PyUnit and steal the idea to define simple test cases in the doc strings from 'doctest'. It shouldn't be that hard to add a semiautomatic import hierarchy traversal tool. Regards, Peter

1 0

TCP socket timeout module?
by Peter Schneider-Kamp July 31, 2000

July 31, 2000

How hard would it be to implement a functionality like this in socketmodule.c? Is such a functionality desirable? guess-this-has-been-discussed-a-thousand-times-before-ly y'rs Peter -------- Original Message -------- Subject: [ANN] TCP socket timeout module --> timeoutsocket.py Date: Sun, 30 Jul 2000 20:54:23 -0400 From: "Timothy O'Malley" <timo(a)alum.mit.edu> Organization: Posted via Supernews, http://www.supernews.com To: python-list(a)python.org Newsgroups: comp.lang.python Numerous times I have seen people request a solution for TCP socket timeouts in conjunction with urllib. Recently, I found myself in the same boat. I wrote a server that would connect to skytel.com and send automated pages. Periodically, the send thread in the server would hang for a long(!) time. Yup -- I was bit by a two hour timeout built into tcp sockets. Thus, I wrote timeoutsocket.py With timeoutsocket.py, you can force *all* TCP sockets to have a timeout. And, this is all accomplished without interfering with the standard python library! Here's how to put a 20 second timeout on all TCP sockets for urllib: import timeoutsock import urllib timeoutsocket.setDefaultSocketTimeout(20) Just like that, any TCP connection made by urllib will have a 20 second timeout. If a connect(), read(), or write() blocks for more than 20 seconds, then a socket.Timeout error will be raised. Want to see how to use this in ftplib? import ftplib import timeoutsocket timeoutsocket.setDefaultSocketTimeout(20) Wasn't that easy! The timeoutsocket.py module acts as a shim on top of the standard socket module. Whenever a TCP socket is requested, an instance of TimeoutSocket is returned. This wrapper class adds timeout support to the standard TCP socket. Where can you get this marvel of modern engineering? http://www.timo-tasi.org/python/timeoutsocket.py And it will very soon be found on the Vaults of Parnassus. Good Luck! -- -- happy daze -tim O -- http://www.python.org/mailman/listinfo/python-list

1 0

UTF-16 code point comparison
by bckfnn＠worldonline.dk July 31, 2000

July 31, 2000

CPythons unicode compare function contains some code to compare surrogate characters in code-point order (I think). This is properly a very neat feature but is differs from java's way of comparing strings. Python 2.0b1 (#0, Jul 26 2000, 21:29:11) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> print u'\ue000' < u'\ud800' 1 >>> print ord(u'\ue000') < ord(u'\ud800') 0 >>> Java (and JPython) compares the 16-bit characters numericly which result in: JPython 1.1+08 on java1.3.0 (JIT: null) Copyright (C) 1997-1999 Corporation for National Research Initiatives >>> print u'\ue000' < u'\ud800' 0 >>> print ord(u'\ue000') < ord(u'\ud800') 0 >>> I don't think I can come up with a solution that allow JPython to emulate CPython on this type of comparison. regards, finn

4 13