Mailman 3 July 2000 - Python-Dev

Urgent inquiry for Paper bags!
by S.Debler (Bitways) July 31, 2000

July 31, 2000

Urgent inquiry for Paper bags, Dear Sirs, We are an international trading company, mainly serving the European industry. The Bitways Group purchases globally on own account and then resells the products to various clients. Our aim is to source globally and to offer our clients the best prices worldwide.

1 0

SPAM from "The Western Web Newsletter"
by M.-A. Lemburg July 31, 2000

July 31, 2000

Could someone please add a filter to the Mailman lists to prevent these horse back advocates ?! Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

Product iteration
by Moshe Zadka July 31, 2000

July 31, 2000

A large part of the problem in list comprehensions (I think) is that we need to allow more then one "for" term, so we can iterate over the product of several lists. Why not solve that the same way we solved the parallel iteration problem, by using a function, called, say, "product". Then list comprehensions can limited to be (in pseudo formal grammar): '[' expr 'for' var 'in' seq [ 'if' pred ] ']' Such that "var" can be anything that can today be in a for loop, e.g., (x, (y, z)) Then we wouldn't have the irksome problem of how for's and if's intermix: the predicate at the end can be an and'ed sequence of predicates. Reference implemntation: class _Producter: def __init__(self, lists): if not lists: raise TypeError("must receive at least one list") self.lists = lists self.lengths = map(len, lists) self.n_lists = len(lists) def __getitem__(self, i): if i<0: raise ValueError("only non-negative indices supported") ret = [None] * self.n_lists for j in range(self.n_lists): i, i_j = divmod(i, self.lengths[j]) ret[j] = self.lists[j][i_j] if i != 0: raise IndexError("not that many items") return tuple(ret) def product(*lists): return _Producter(lists) -- Moshe Zadka <moshez(a)math.huji.ac.il> There is no IGLU cabal. http://advogato.org/person/moshez

19 56

checkins and regression tests
by Mark Favas July 31, 2000

July 31, 2000

It'd be nice if the newly checked-in test were run through the test framework before being checked in - the latest test_mmap.py fails due to the "inconsistent tab-space" problem... Mark -- Email - m.favas(a)per.dem.csiro.au Mark C Favas Phone - +61 8 9333 6268, 0418 926 074 CSIRO Exploration & Mining Fax - +61 8 9383 9891 Private Bag No 5, Wembley WGS84 - 31.95 S, 115.80 E Western Australia 6913

3 2

re-ordering op-codes / DDJ
by Greg Wilson July 31, 2000

July 31, 2000

Hi, folks. Given how popular byte code interpreters are these days, I think "Doctor Dobb's Journal" would be very interested in an article if work is done on re-ordering/re-organizing the Python VM to improve performance. Interested parties please mail me directly... Thanks, Greg

1 0

buglet in unary ops on classes.
by Thomas Wouters July 30, 2000

July 30, 2000

While poking around looking for something else, I found this little buglet: >>> class X: ... def __getattr__(self, val): ... print "getattr:", val ... raise AttributeError >>> x = X() >>> ~x getattr: __invert__ Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 4, in __getattr__ AttributeError The unary ops all do this (raising AttributeError), but the binary ops do not: >>> x+1 getattr: __coerce__ getattr: __add__ Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: __add__ nor __radd__ defined for these operands Shouldn't this translation be done for unary ops as well ? Is it safe to assume that instance_getattr() only returns NULL if the attribute is not found ? PyInstance_DoBinOp() takes this assumption wrt. PyObject_GetAttr(), and I don't really see a problem with it. -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 1

Re: [Python-Dev] extended slicing for lists
by Michael Hudson July 30, 2000

July 30, 2000

Ka-Ping Yee <ping(a)lfw.org> writes: > Hey, wait a second. To get l[start:end:step], you start with 'start' > and keep adding 'step' until you get to -- but not including -- 'end', > right? So l[len(l)-1:-1:-1] should return the entire list reversed, > not the empty list. Yes, but "-1" also means the last element of the list, so >>> range(10)[3:-1:2] [3, 5, 7] If you want "to the end" behaviour, use None (or nothing): >>> range(10)[5::-2] [5, 3, 1] >>> range(10)[5:None:-2] [5, 3, 1] (these two are indistinguishable) Also, can I plead my case in that this was not my decision - it's the logic implemented by PySlice_GetIndices. > range() demonstrates the behaviour nicely: > > >>> size = 5 > >>> range(size-1,-1,-1) > [4, 3, 2, 1, 0] > > Wouldn't l[sys.maxint:0:-1] return all but the first element of l in > reverse order? Yes. > >>> range(size-1,0,-1) > [4, 3, 2, 1] > > Note that we should deprecate the use of sys.maxint (preferring None) > in this situation, since if the step is less than -1, the elements > you get ought to depend on the value of sys.maxint % step. I'd expect: > > >>> l = [0, 1, 2, 3, 4, 5] > >>> l[5:0:-3] > [5, 2] > >>> l[6:0:-3] > [4, 1] > >>> l[7:0:-3] > [3, 0] > >>> l[8:0:-3] > [5, 2] Whereas at the moment you get: >>> l[5:0:-3] [5, 2] >>> l[6:0:-3] Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: slice indices must be integers >>> l[7:0:-3] Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: slice indices must be integers >>> l[8:0:-3] Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: slice indices must be integers (which is definitely screwy). Perhaps I shouldn't use PySlice_GetIndices (but then if I don't use it for this patch, what on earth would you use it for?). At any rate PySlice_GetIndices needs mending to accept longs (in the style of PyObject_GetItem). > hence > > >>> l[sys.maxint:0:-3] > [???, ???] # depends on sys.maxint % 3 > > My guiding principle is that the indices should always match what > you get from range(), and if start or end are missing, you get the > items you would have gotten if you extend the sequence out forever. Aside from the interpretation of negative indices, I basically agree. Cheers, M. -- languages shape the way we think, or don't. -- Erik Naggum, comp.lang.lisp

1 0

Request for guidance on documentation
by Eric S. Raymond July 30, 2000

July 30, 2000

I have now made two passes through the docs for the new curses module, correcting minor errors and adding explanatory material. The question is what to do next, and that turns on whether discursive tutorial sections are are considered fit for inclusion in the library reference. If they are, I'll rewrite the existing curses HOWTO and slide it in there, perhaps adding some stuff from the "Introduction to ncurses" HTML tutorial I wrote lo those many moons ago for the ncurses distribution. Can anybody point me at the TeX source for the curses HOWTO? Also, I'm not sure where the material for curses.textbox should go. New section? Or a subsection in the curses document? -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> 'Faith' means not _wanting_ to know what is true. -- Nietzsche, Der Antichrist

6 12

urllib - {quote,unquote} vs. {quote_plus,unquote_plus}
by Skip Montanaro July 30, 2000

July 30, 2000

I realize there is a symmetry between the functionality of urllib.{quote,unquote} and urllib.{quote_plus,unquote_plus}, but why doesn't unquote function like unquote_plus and map "+" to " "? Skip

2 1

SF most active project listing
by Andrew Kuchling July 29, 2000

July 29, 2000

I was curious about how "most active project" is defined, and took a look at the SF code. It's computed by the util/db_project_weekly_metric.pl script, which sums up a bunch of parameters to get a number. The parameters are: 3 * # of forum postings 4 * # of tasks 3 * # of bugs 10 * # of patches 5 * # of support 1 * # of CVS commits 5 * # of developers 5 * # of file releases .3 * # of downloads All of these numbers seem to be counted over the past week. I suspect the code has a mathematical bug: the queries use, for example, log(4*count(project_task.project_task_id)) for counting things. However, IIRC, log ab = log a + log b, so the multipliers just add a constant to every project's number, and therefore it's a flat sum of all the parameters. IMHO that should be 4*log(count(....)), and will report it. --amk

2 1