Mailman 3 July 2000 - Python-Dev

more unicode: \U support?
by Fredrik Lundh July 28, 2000

July 28, 2000

would it be a good idea to add \UXXXXXXXX (8 hex digits) to 2.0? (only characters in the 0000-ffff range would be accepted in the current version, of course). </F>

3 6

Re: [Python-checkins] CVS: python/nondist/peps pep-0000.txt,1.13,1.14
by Peter Schneider-Kamp July 28, 2000

July 28, 2000

Barry Warsaw wrote: > > Update of /cvsroot/python/python/nondist/peps > In directory slayer.i.sourceforge.net:/tmp/cvs-serv2151 > > Modified Files: > pep-0000.txt Hi Barry! I don't know if it is possible to run pep2html.py on your system (I have only used it on Linux), but it would be nice if you could do that after committing changes to the PEPs. Thanks, Peter -- Peter Schneider-Kamp ++47-7388-7331 Herman Krags veg 51-11 mailto:peter@schneider-… [View More]

2 1

failures in the regression tests
by Jeremy Hylton July 28, 2000

July 28, 2000

I am trying to keep track of failures in the regression test suite. At the moment, all the available tests work correctly on my Linux box. I understand there are still problems with test_fork1 on some SMP Linux boxes. (I believe this error has been around for many months.) And that the test_winreg and test_winreg32 tests are failing on Windows builds. If you are aware of any other tests that are failing, please let me know. (Preferably by private email.) We need to get the tests fixed … [View More]

7 7

PEP 201, zip() builtin
by bwarsaw＠beopen.com July 28, 2000

July 28, 2000

Folks, Here is the latest PEP 201, updated based on conversations with Guido yesterday. Notice that there are no more Open Issues. See instead the BDFL Pronouncements section. Plan on seeing a C-based implementation checked into the CVS devel tree soon. If you want to comment on this PEP, you must include "PEP 201" in the Subject: header. Enjoy, -Barry -------------------- snip snip -------------------- PEP: 201 Title: Parallel Iteration Version: $Revision: 1.10 $ Author: bwarsaw(a)… [View More]beopen.com (Barry A. Warsaw) Python-Version: 2.0 Status: Draft Created: 13-Jul-2000 Post-History: 27-Jul-2000 Introduction This PEP describes the `parallel iteration' proposal for Python 2.0, previously known as `parallel for loops'. This PEP tracks the status and ownership of this feature, slated for introduction in Python 2.0. It contains a description of the feature and outlines changes necessary to support the feature. This PEP summarizes discussions held in mailing list forums, and provides URLs for further information, where appropriate. The CVS revision history of this file contains the definitive historical record. Motivation Standard for-loops in Python iterate over every element in a sequence until the sequence is exhausted[1]. However, for-loops iterate over only a single sequence, and it is often desirable to loop over more than one sequence, in a lock-step, "Chinese Menu" type of way. The common idioms used to accomplish this are unintuitive and inflexible. This PEP proposes a standard way of performing such iterations by introducing a new builtin function called `zip'. Parallel For-Loops Parallel for-loops are non-nested iterations over two or more sequences, such that at each pass through the loop, one element from each sequence is taken to compose the target. This behavior can already be accomplished in Python through the use of the map() built-in function: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> for i in map(None, a, b): print i ... (1, 4) (2, 5) (3, 6) >>> map(None, a, b) [(1, 4), (2, 5), (3, 6)] The for-loop simply iterates over this list as normal. While the map() idiom is a common one in Python, it has several disadvantages: - It is non-obvious to programmers without a functional programming background. - The use of the magic `None' first argument is non-obvious. - It has arbitrary, often unintended, and inflexible semantics when the lists are not of the same length: the shorter sequences are padded with `None'. >>> c = (4, 5, 6, 7) >>> map(None, a, c) [(1, 4), (2, 5), (3, 6), (None, 7)] For these reasons, several proposals were floated in the Python 2.0 beta time frame for providing a better spelling of parallel for-loops. The initial proposals centered around syntactic changes to the for statement, but conflicts and problems with the syntax were unresolvable, especially when parallel for-loops were combined with another proposed feature called `list comprehensions' (see pep-0202.txt). The Proposed Solution The proposed solution is to introduce a new built-in sequence generator function, available in the __builtin__ module. This function is to be called `zip' and has the following signature: zip(seqa, [seqb, [...]]) zip() takes one or more sequences and weaves their elements together, just as map(None, ...) does with sequences of equal length. The weaving stops when the shortest sequence is exhausted. Return Value zip() returns a real Python list, the same way map() does. Examples Here are some examples, based on the reference implementation below. >>> a = (1, 2, 3, 4) >>> b = (5, 6, 7, 8) >>> c = (9, 10, 11) >>> d = (12, 13) >>> zip(a, b) [(1, 5), (2, 6), (3, 7), (4, 8)] >>> zip(a, d) [(1, 12), (2, 13)] >>> zip(a, b, c, d) [(1, 5, 9, 12), (2, 6, 10, 13)] Note that when the sequences are of the same length, zip() is reversible: >>> a = (1, 2, 3) >>> b = (4, 5, 6) >>> x = zip(a, b) >>> y = zip(*x) # alternatively, apply(zip, x) >>> z = zip(*y) # alternatively, apply(zip, y) >>> x [(1, 4), (2, 5), (3, 6)] >>> y [(1, 2, 3), (4, 5, 6)] >>> z [(1, 4), (2, 5), (3, 6)] >>> x == z 1 It is not possible to reverse zip this way when the sequences are not all the same length. Reference Implementation Here is a reference implementation, in Python of the zip() built-in function. These would ultimately be replaced by equivalent C code. def zip(*args): if not args: raise TypeError('zip() expects one or more sequence arguments') ret = [] # find the length of the shortest sequence shortest = min(*map(len, args)) for i in range(shortest): item = [] for s in args: item.append(s[i]) ret.append(tuple(item)) return ret BDFL Pronouncements Note: the BDFL refers to Guido van Rossum, Python's Benevolent Dictator For Life. - The function's name. An earlier version of this PEP included an open issue listing 20+ proposed alternative names to zip(). In the face of no overwhelmingly better choice, the BDFL strongly prefers zip() due to it's Haskell[2] heritage. See version 1.7 of this PEP for the list of alteratives. - zip() shall be a built-in function. - Optional padding. An earlier version of this PEP proposed an optional `pad' keyword argument, which would be used when the argument sequences were not the same length. This is similar behavior to the map(None, ...) semantics except that the user would be able to specify pad object. This has been rejected by the BDFL in favor of always truncating to the shortest sequence. - Lazy evaluation. An earlier version of this PEP proposed that zip() return a built-in object that performed lazy evaluation using __getitem__() protocol. This has been strongly rejected by the BDFL in favor of returning a real Python list. If lazy evaluation is desired in the future, the BDFL suggests an xzip() function be added. - zip() with no arguments. the BDFL strongly prefers this raise a TypeError exception. - zip() with one argument. the BDFL strongly prefers that this return a list of 1-tuples. - Inner and outer container control. An earlier version of this PEP contains a rather lengthy discussion on a feature that some people wanted, namely the ability to control what the inner and outer container types were (they are tuples and list respectively in this version of the PEP). Given the simplified API and implementation, this elaboration is rejected. For a more detailed analysis, see version 1.7 of this PEP. References [1] http://www.python.org/doc/current/ref/for.html [2] http://www.haskell.org/onlinereport/standard-prelude.html#$vzip TBD: URL to python-dev archives Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: [View Less]

4 4

RE: [Python-Dev] UTF-16 code point comparison
by Bill Tutt July 28, 2000

July 28, 2000

> From: Tim Peters [mailto:tim_one@email.msn.com] > When the Unicode push started, it was agreed that we would ignore surrogates > "for now". I sounded a caution then that I will repeat: the Unicode folks > made a bad engineering decision, based on the (Eurocentric) assumption that > 64K was a large enough space to meet their stated goals. Don't know how > long it will take this half of the world to realize it, but UCS-4 is > inevitable. On new systems perhaps, but … [View More]

2 1

FW: [Patch #101006] fix mmapmodule test failures
by Mark Hammond July 27, 2000

July 27, 2000

Hi all, I just uploaded a patch of mmapmodule to fix the test failures. The patch is not trivial, so I didnt just check it in. However, the patch also isnt _that_ large, so if some Windows people could give it a quick eyeball I would appreciate it. http://sourceforge.net/patch/?func=detailpatch&patch_id=101006&group_id=547 0 [Doh: Just noticed - the clode block that handles the DuplicateHandle() function failing needs to Py_DECREF the new object - Damn! So ignore that particular … [View More]

1 0

RE: [Python-Dev] Fork on Win32 - was (test_fork1 failing...)
by Bill Tutt July 27, 2000

July 27, 2000

[ActivePerl's hack for fork()] Oh gack. I think I'd rather just not go down this road. This is one huge ugly hack. :( Having to maintain separate environments, and separate working directories. *shiver* Bill

1 0

RE: [Python-Dev] more unicode: \U support?
by Bill Tutt July 27, 2000

July 27, 2000

[Tim stating that we need 8 digits to mimic C99's \U notation due to the ISO 10646 UCS-4 stuff.] Heh, I suppose. ISO has approved the following document for the next rev of 10646 though. "Proposal to restrict the range of code positions to the values up to U-0010FFFF": http://anubis.dkuug.dk/jtc1/sc2/wg2/docs/n2175.htm FYI, Bill

1 0

RE: [Python-Dev] more unicode: \U support?
by Bill Tutt July 27, 2000

July 27, 2000

Actually, it'd be \U10FFFF, no need for 8 digits. Java doesn't support surrogates yet, so what Java does for \u doesn't make any difference. :) \U10FFFF should expand to either one character in UCS-4, or two characters in UTF-16/UCS-2. No particular reason why it can't work for 2.0. This is similar to the UTF-8 issue wrt surrogates. Bill

2 1

Re: [Python-Dev] PEP 203 Augmented Assignment
by Michael Hudson July 27, 2000

July 27, 2000

Guido van Rossum <guido(a)beopen.com> writes: > > Good idea. Are lists and tuples going to support seq[a:b:c] anytime soon? > > It's on my wish list, but can't be done for 2.0. This would involve the list type implementing the mapping API wouldn't it? This would seem to be a little on the silly side. Never mind; here's a quick-hack patch that "seems to work" for lists: Index: listobject.c =================================================================== RCS file: /… [View More]cvsroot/python/python/dist/src/Objects/listobject.c,v retrieving revision 2.83 diff -u -c -r2.83 listobject.c *** listobject.c 2000/07/25 12:56:38 2.83 --- listobject.c 2000/07/27 20:38:50 *************** *** 1400,1405 **** --- 1400,1441 ---- (objobjproc)list_contains, /*sq_contains*/ }; + static PyObject* + list_subscript(PyObject* list, PyObject* item) + { + if (PyInt_Check(item)) { + return list_item((PyListObject*)list,PyInt_AS_LONG(item)); + } else if (PySlice_Check(item)) { + int start, stop, step, cur, i; + PyObject* result; + PyObject* it; + + if (PySlice_GetIndices((PySliceObject*)item,PyList_Size(list),&start,&stop,&step) < 0) { + PyErr_SetString(PyExc_TypeError, "slice indices must be integers"); + return NULL; + } + + result = PyList_New((stop-start)/step+1); + + for (cur = start, i = 0; cur < stop; cur += step, i++) { + it = PyList_GET_ITEM(list,cur); + Py_INCREF(it); + PyList_SET_ITEM(result,i,it); + } + + return result; + } else { + PyErr_SetString(PyExc_TypeError, "list indices must be integers"); + return NULL; + } + }; + + static PyMappingMethods list_as_mapping = { + (inquiry)list_length, + (binaryfunc)list_subscript, + (objobjargproc)NULL + }; + PyTypeObject PyList_Type = { PyObject_HEAD_INIT(&PyType_Type) 0, *************** *** 1414,1420 **** (reprfunc)list_repr, /*tp_repr*/ 0, /*tp_as_number*/ &list_as_sequence, /*tp_as_sequence*/ ! 0, /*tp_as_mapping*/ 0, /*tp_hash*/ 0, /*tp_call*/ 0, /*tp_str*/ --- 1450,1456 ---- (reprfunc)list_repr, /*tp_repr*/ 0, /*tp_as_number*/ &list_as_sequence, /*tp_as_sequence*/ ! &list_as_mapping, /*tp_as_mapping*/ 0, /*tp_hash*/ 0, /*tp_call*/ 0, /*tp_str*/ Have I missed anything obvious? I'd upload it to SF, but I don't really want something I've put such little effort into to be seriously considered... Cheers, M. -- 112. Computer Science is embarrassed by the computer. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html [View Less]

1 0