Mailman 3 June 2002 - Python-Dev

PEP 292, Simpler String Substitutions
by barry＠zope.com 19 Jun '02

19 Jun '02

I'm so behind on my email, that the anticipated flamefest will surely die down before I get around to reading it. Yet still, here is a new PEP. :) -Barry -------------------- snip snip -------------------- PEP: 292 Title: Simpler String Substitutions Version: $Revision: 1.2 $ Last-Modified: $Date: 2002/06/19 02:54:22 $ Author: barry(a)zope.com (Barry A. Warsaw) Status: Draft Type: Standards Track Created: 18-Jun-2002 Python-Version: 2.3 Post-History: 18-Jun-2002 Abstract This PEP describes a simpler string substitution feature, also known as string interpolation. This PEP is "simpler" in two respects: 1. Python's current string substitution feature (commonly known as %-substitutions) is complicated and error prone. This PEP is simpler at the cost of less expressiveness. 2. PEP 215 proposed an alternative string interpolation feature, introducing a new `$' string prefix. PEP 292 is simpler than this because it involves no syntax changes and has much simpler rules for what substitutions can occur in the string. Rationale Python currently supports a string substitution (a.k.a. string interpolation) syntax based on C's printf() % formatting character[1]. While quite rich, %-formatting codes are also quite error prone, even for experienced Python programmers. A common mistake is to leave off the trailing format character, e.g. the `s' in "%(name)s". In addition, the rules for what can follow a % sign are fairly complex, while the usual application rarely needs such complexity. A Simpler Proposal Here we propose the addition of a new string method, called .sub() which performs substitution of mapping values into a string with special substitution placeholders. These placeholders are introduced with the $ character. The following rules for $-placeholders apply: 1. $$ is an escape; it is replaced with a single $ 2. $identifier names a substitution placeholder matching a mapping key of "identifier". "identifier" must be a Python identifier as defined in [2]. The first non-identifier character after the $ character terminates this placeholder specification. 3. ${identifier} is equivalent to $identifier and for clarity, this is the preferred form. It is required for when valid identifier characters follow the placeholder but are not part of the placeholder, e.g. "${noun}ification". No other characters have special meaning. The .sub() method takes an optional mapping (e.g. dictionary) where the keys match placeholders in the string, and the values are substituted for the placeholders. For example: '${name} was born in ${country}'.sub({'name': 'Guido', 'country': 'the Netherlands'}) returns 'Guido was born in the Netherlands' The mapping argument is optional; if it is omitted then the mapping is taken from the locals and globals of the context in which the .sub() method is executed. For example: def birth(self, name): country = self.countryOfOrigin['name'] return '${name} was born in ${country}' birth('Guido') returns 'Guido was born in the Netherlands' Reference Implementation Here's a Python 2.2-based reference implementation. Of course the real implementation would be in C, would not require a string subclass, and would not be modeled on the existing %-interpolation feature. import sys import re dre = re.compile(r'(\$\$)|\$([_a-z]\w*)|\$\{([_a-z]\w*)\}', re.I) EMPTYSTRING = '' class dstr(str): def sub(self, mapping=None): # Default mapping is locals/globals of caller if mapping is None: frame = sys._getframe(1) mapping = frame.f_globals.copy() mapping.update(frame.f_locals) # Escape %'s s = self.replace('%', '%%') # Convert $name and ${name} to $(name)s parts = dre.split(s) for i in range(1, len(parts), 4): if parts[i] is not None: parts[i] = '$' elif parts[i+1] is not None: parts[i+1] = '%(' + parts[i+1] + ')s' else: parts[i+2] = '%(' + parts[i+2] + ')s' # Interpolate return EMPTYSTRING.join(filter(None, parts)) % mapping And here are some examples: s = dstr('${name} was born in ${country}') print s.sub({'name': 'Guido', 'country': 'the Netherlands'}) name = 'Barry' country = 'the USA' print s.sub() This will print "Guido was born in the Netherlands" followed by "Barry was born in the USA". Handling Missing Keys What should happen when one of the substitution keys is missing from the mapping (or the locals/globals namespace if no argument is given)? There are two possibilities: - We can simply allow the exception (likely a NameError or KeyError) to propagate. - We can return the original substitution placeholder unchanged. An example of the first is: print dstr('${name} was born in ${country}').sub({'name': 'Bob'}) would raise: Traceback (most recent call last): File "sub.py", line 66, in ? print s.sub({'name': 'Bob'}) File "sub.py", line 26, in sub return EMPTYSTRING.join(filter(None, parts)) % mapping KeyError: country An example of the second is: print dstr('${name} was born in ${country}').sub({'name': 'Bob'}) would print: Bob was born in ${country} The PEP author would prefer the latter interpretation, although a case can be made for raising the exception instead. We could almost ignore the issue, since the latter example could be accomplished by passing in a "safe-dictionary" in instead of a normal dictionary, like so: class safedict(dict): def __getitem__(self, key): try: return dict.__getitem__(self, key) except KeyError: return '${%s}' % key so that d = safedict({'name': 'Bob'}) print dstr('${name} was born in ${country}').sub(d) would print: Bob was born in ${country} The one place where this won't work is when no arguments are given to the .sub() method. .sub() wouldn't know whether to wrap locals/globals in a safedict or not. This ambiguity can be solved in several ways: - we could have a parallel method called .safesub() which always wrapped its argument in a safedict() - .sub() could take an optional keyword argument flag which indicates whether to wrap the argument in a safedict or not. - .sub() could take an optional keyword argument which is a callable that would get called with the original mapping and return the mapping to be used for the substitution. By default, this callable would be the identity function, but you could easily pass in the safedict constructor instead. BDFL proto-pronouncement: It should always raise a NameError when the key is missing. There may not be sufficient use case for soft failures in the no-argument version. Comparison to PEP 215 PEP 215 describes an alternate proposal for string interpolation. Unlike that PEP, this one does not propose any new syntax for Python. All the proposed new features are embodied in a new string method. PEP 215 proposes a new string prefix representation such as $"" which signal to Python that a new type of string is present. $-strings would have to interact with the existing r-prefixes and u-prefixes, essentially doubling the number of string prefix combinations. PEP 215 also allows for arbitrary Python expressions inside the $-strings, so that you could do things like: import sys print $"sys = $sys, sys = $sys.modules['sys']" which would return sys = <module 'sys' (built-in)>, sys = <module 'sys' (built-in)> It's generally accepted that the rules in PEP 215 are safe in the sense that they introduce no new security issues (see PEP 215, "Security Issues" for details). However, the rules are still quite complex, and make it more difficult to see what exactly is the substitution placeholder in the original $-string. By design, this PEP does not provide as much interpolation power as PEP 215, however it is expected that the no-argument version of .sub() allows at least as much power with no loss of readability. References [1] String Formatting Operations http://www.python.org/doc/current/lib/typesseq-strings.html [2] Identifiers and Keywords http://www.python.org/doc/current/ref/identifiers.html Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End:

1 0

Re: making dbmmodule still broken
by Skip Montanaro 19 Jun '02

19 Jun '02

I wrote: ... here's what I propose (and what changes I just made locally): I forgot about one other change. In dbmmodule.c I #include <db.h> if HAVE_BERKDB_H is defined: #if defined(HAVE_NDBM_H) #include <ndbm.h> #if defined(PYOS_OS2) && !defined(PYCC_GCC) static char *which_dbm = "ndbm"; #else static char *which_dbm = "GNU gdbm"; /* EMX port of GDBM */ #endif #elif defined(HAVE_GDBM_NDBM_H) #include <gdbm/ndbm.h> static char *which_dbm = "GNU gdbm"; #elif defined(HAVE_BERKDB_H) #include <db.h> static char *which_dbm = "Berkeley DB"; #else #error "No ndbm.h available!" #endif Skip

1 0

popen behavior
by Kevin Butler 19 Jun '02

19 Jun '02

I've done some work implementing popen* for Jython, and had a couple of questions: - Should we maintain the os.popen & popen2.popen dual exposure with their different argument & return value orders? The 'os' exposure is newer, so I assume it is preferred. The calls follow these patterns: stdin, stdout, stderr = os.popen*( command, mode, bufsize ) stdout, stdin, stderr = popen2.popen*( command, bufsize, mode ) - Should we maintain the different behavior for lists of arguments vs strings? (it does not appear to be documented) That is, the command can be either a string or a list of strings. If it is a list of strings, it is executed as a new process without a shell. If it is a string, CPython's popen2 module attempts to execute it as a shell command-line as follows: if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] Thanks kb

2 2

making dbmmodule still broken
by Guido van Rossum 18 Jun '02

18 Jun '02

On my 2yo Mandrake 8.1 (?) system, when I do "make" in the latest CVS tree, I always get an error from building dbmmodule.c: [guido@odiug linux]$ make case $MAKEFLAGS in \ *-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ../setup.py build;; \ esac running build running build_ext building 'dbm' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I. -I/home/guido/python/dist/src/./Include -I/usr/local/include -I/home/guido/python/dist/src/Include -I/home/guido/python/dist/src/linux -c /home/guido/python/dist/src/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o /home/guido/python/dist/src/Modules/dbmmodule.c:25: #error "No ndbm.h available!" running build_scripts [guido@odiug linux]$ There's an ndbm.h is in /usr/include/db1/ndbm.h Skip, didn't you change something in this area recently? I think it's still busted. :-( --Guido van Rossum (home page: http://www.python.org/~guido/)

3 2

mkdev, major, st_rdev, etc
by Gustavo Niemeyer 18 Jun '02

18 Jun '02

After thinking for a while, and doing some research about these functions, I've changed my mind about the best way to implement the needed functionality for tarfile. Maybe including major, minor, and makedev is the best solution. Some of the issues I'm considering: - st_rdev was already available in 2.2, so we'd have to introduce a new redundant pair attribute to provide a (major, minor) pair. - mkdev would be able to use the standard posix format, and would work regardless of makedev's availability (mkdev is being introduced in 2.3). - more flexible. major, minor, and makedev may be needed in other cases, besides st_rdev parsing and mknod device creation. - TYPES.py is already trying to provide them, but it's broken (indeed, it's more broken than that. h2py should use cpp to preprocess the files, but that's something for another occasion). - these "functions" are usually macros, thus should introduce little overhead. A patch providing these functions is available at http://www.python.org/sf/569139 -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

2 3

Slicing
by David Abrahams 18 Jun '02

18 Jun '02

I did a little experiment to see if I could use a uniform interface for slicing (from C++): >>> range(10)[slice(3,5)] Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: sequence index must be integer >>> class Y(object): ... def __getslice__(self, a, b): ... print "getslice",a,b ... >>> y = Y() >>> y[slice(3,5)] Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: unsubscriptable object >>> y[3:5] getslice 3 5 This seems to indicate that I can't, in general, pass a slice object to PyObject_GetItem in order to do slicing.** Correct? So I went looking around for alternatives to PyObject_GetItem. I found PySequence_GetSlice, but that takes int parameters, and AFAIK there's no rule saying you can't slice on strings, for example. Further experiments revealed: >>> y['hi':'there'] Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: unsubscriptable object >>> class X(object): ... def __getitem__(self, x): ... print 'getitem',x ... >>> X()['hi':'there'] getitem slice('hi', 'there', None) So I /can/ slice on strings, but only through __getitem__(). And... >>> class Z(Y): ... def __getitem__(self, x): ... print 'getitem',x ... >>> Z()[3:5] getslice 3 5 >>> Z()['3':5] getitem slice('3', 5, None) So Python is doing some dispatching internally based on the types of the slice elements, but: >>> class subint(int): pass ... >>> subint() 0 >>> Z[subint():5] Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: unsubscriptable object So it's looking at the concrete type of the slice elements. I'm not sure I actually understand how this one fails. I want to make a generalized getslice function in C which can operate on a triple of arbitrary objects. Here's the python version I came up with: def getslice(x,start,finish): if (type(start) is type(finish) is int and hasattr(type(x), '__getslice__')): return x.__getslice__(start, finish) else: return x.__getitem__(slice(start,finish)) Have I got the logic right here? Thanks, Dave **it seems like a good idea to make it work in the Python core, by recognizing slice objects and dispatching the elements to __getslice__ if they are ints and if one is defined. Have I overlooked something? +---------------------------------------------------------------+ David Abrahams C++ Booster (http://www.boost.org) O__ == Pythonista (http://www.python.org) c/ /'_ == resume: http://users.rcn.com/abrahams/resume.html (*) \(*) == email: david.abrahams(a)rcn.com +---------------------------------------------------------------+

1 0

MultiDict / Table, suggestion for a new module
by Edward C. Jones 18 Jun '02

18 Jun '02

I have written a module called MultiDict.py which can be found at http://members.tripod.com/~edcjones/MultiDict.py . It contains two classes MultiDict and Table. MultiDict is like a dictionary except that each key can occur more than once. It is like the multimap in the C++ Standard Template Library except that MultiDicts are hashed rather than sorted. Table views a 2 dimensional nested list as a "relation" (a set of n-tuples). I use it for simple one table databases where the full panoply of SQL is not needed. If there is interest in this, I will write a PEP and some documentation. Thanks, Edward C. Jones

1 0

large file support
by Jeremy Hylton 18 Jun '02

18 Jun '02

I've run into a problem with large files using Python 2.1.2 and a Linux 2.4.9 box. We've got a large file -- almost 6GB -- that Python chokes on even though regular shell tools seem to be fine. In particular, os.stat() of the file fails with EOVERFLOW and open() of the file fails with EFBIG. The stat() failure is really bad because it means os.path.exists() returns false. strace tells me that other tools open the file passing O_LARGEFILE, but Python does not. (They pass it even for small files.) I can't find any succient explanation of O_LARGEFILE, but Google turns up all sorts of pages that mention it. It looks like the right way to open large files, but it only seems to be defined in <asm/fcntl.h> on the Linux box in question. I haven't had any luck searching for a decent way to invoke stat() and have it be prepared for a very large file. I think Python is definitely broken here. Can anyone offer any clues or pointers to documentation? Better yet, a fix. I'm happy to help integrate and test it. Jeremy

8 23

Quota on sf.net
by loewis＠informatik.hu-berlin.de 18 Jun '02

18 Jun '02

It appears SF is rearranging servers, and asks projects to honor their disk quota, see https://sourceforge.net/forum/forum.php?forum_id=183601 There is a per-project disk quota of 100MB; /home/groups/p/py/python currently consumes 880MB. Most of this (830MB) is in htdocs/snapshots. Should we move those onto python.org? Regards, Martin

8 12

addressing distutils inability to track file dependencies
by Skip Montanaro 18 Jun '02

18 Jun '02

I wonder if it would be better to have distutils generate the appropriate type of makefile and execute that instead of directly building objects and shared libraries. This would finesse some of the dependency tracking problems that pop up frequently. Skip

28 109

RE: [Python-Dev] Playstation 2 and GameCube ports
by Gustavo Cordova 18 Jun '02

18 Jun '02

> > > That would certainly get my son's attention and might even > > get him started in programming. I wouldn't mind seeing your > > efforts written up in a PEP. > > What exactly can you accomplish with Python on one of these boxes? > > Don't you need a (costly) developers license in order to use this? > > --Guido van Rossum (home page: http://www.python.org/~guido/) > Nope, just hack away at it in PS2-Linux, quite nice; you can distribute your own games. Now, if there's a PyGame and PyGL for PS2, then I think that some very cool hacks and demos are gonna start appearing for the piss-two in a little time. :-) -gus

1 0

unicode() and its error argument
by Skip Montanaro 18 Jun '02

18 Jun '02

The unicode() builtin accepts an optional third argument, errors, which defaults to "strict". According to the docs if errors is set to "ignore", decoding errors are silently ignored. I seem to still get the occasional UnicodeError exception, however. I'm still trying to track down an actual example (it doesn't happen often, and I hadn't wrapped unicode() in a try/except statement, so all I saw was the error raised, not the input string value). This reminds me, it occurred to me the other day that a plain text version of cgitb would be useful to use for non-web scripts. You'd get a lot more context about the environment in which the exception was raised. Skip

6 11

Re: [Python-checkins] python/dist/src/Objects bufferobject.c,2.17,2.18 classobject.c,2.156,2.157 descrobject.c,2.26,2.27 funcobject.c,2.54,2.55 sliceobject.c,2.14,2.15
by Michael Hudson 18 Jun '02

18 Jun '02

gvanrossum(a)users.sourceforge.net writes: > Index: classobject.c [...] > + static PyObject * > + new_class(PyObject* unused, PyObject* args) > + { > + PyObject *name; > + PyObject *classes; > + PyObject *dict; > + > + if (!PyArg_ParseTuple(args, "SO!O!:class", > + &name, > + &PyTuple_Type, &classes, > + &PyDict_Type, &dict)) > + return NULL; > + return PyClass_New(classes, dict, name); > + } > + What's this for? It's not referred to anywhere, so I'm getting warnings about it. I'd just hack it out, but it only just got added... Cheers, M. -- ARTHUR: Don't ask me how it works or I'll start to whimper. -- The Hitch-Hikers Guide to the Galaxy, Episode 11

2 1

Re: [Python-Dev] test_socket failures
by Michael Gilfix 18 Jun '02

18 Jun '02

Guido, please let me know if you want me to do anything more regarding the test_socket.py stuff and perhaps some timeout stuff before I take off (this wednsday). A note for the interested: I'll be gone for a month on vacation, so response won't be timely. Regards, -- Mike -- Michael Gilfix mgilfix(a)eecs.tufts.edu For my gpg public key: http://www.eecs.tufts.edu/~mgilfix/contact.html

1 0

behavior of inplace operations
by David Abrahams 17 Jun '02

17 Jun '02

My initial post asking about the implementation of += sparked a small thread over on python-list, from which I've come to the conclusion that my little optimization suggestion (don't try to set the attribute or item if the inplace op returns its first argument) is actually more semantically correct. For better or worse, these ideas aren't all mine, as http://aspn.activestate.com/ASPN/Mail/Message/python-list/1222524 attests. Consider: >>> t = ([1],[2],[3]) >>> t[0].append(2) # OK, the elements of the tuple are mutable >>> t ([1, 2], [2], [3]) >>> >>> t[1] += [3] # ?? Just did the equivalent operation above Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: object doesn't support item assignment >>> t # Despite the exception, the operation succeeded! ([1, 2], [2, 3], [3]) So, the exception happens because the user is ostensibly trying to modify this immutable tuple... but of course she's not. She's just trying to modify the element of the tuple, which is itself mutable, and that makes the exception surprising. Even more surprising in light of the exception is the fact that everything seems to have worked. In order to get this all to make sense, she needs to twist her brain into remembering that inplace operations don't really just modify their targets "in place", but also try to "replace" them. However, if we just set up the inplace operations so that when they return the original object there's no "replace", all of these problems go away. We don't lose any safety; trying to do += on an immutable tuple element will still fail. Also it makes tuples a generic replacement for lists in more places. There are other, more-perverse cases which the proposed change in semantics would also fix. For example: >>> class X(object): ... def __init__(self, l): ... self.container = l # will form a cycle ... self.stuff = [] ... def __iadd__(self, other): ... self.stuff += other # add to X's internal list ... del self.container[0] ... return self ... >>> l = [ 1, 2, 3] >>> l.append(X(l)) # the X element refers to l >>> l [1, 2, 3, <__main__.X object at 0x00876668>] >>> l[3] += 'a' # the element is gone by write-back time. Traceback (most recent call last): File "<stdin>", line 1, in ? IndexError: list assignment index out of range >>> l # But everything succeeded [2, 3, <__main__.X object at 0x00876668>] >>> l[2].stuff ['a'] >>> l.append('tail') # this one's even wierder >>> l[2] += 'a' >>> l [3, <__main__.X object at 0x00876668>, <__main__.X object at 0x00876668>] These are too esoteric to be compelling on their own, but my proposal would also make them work as expected. Thoughts? -Dave ------------ P.S. This error message is kind of wierd: >>> t = ([1],[2],[3]) >>> t[1] += 3 Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: argument to += must be iterable ^^^^^^^^^^^^^^^^ ?? +---------------------------------------------------------------+ David Abrahams C++ Booster (http://www.boost.org) O__ == Pythonista (http://www.python.org) c/ /'_ == resume: http://users.rcn.com/abrahams/resume.html (*) \(*) == email: david.abrahams(a)rcn.com +---------------------------------------------------------------+

4 11

PEP 290 - Code Modernization and Migration
by Raymond Hettinger 17 Jun '02

17 Jun '02

The migration guide has been codified in a new informational pep at http://www.python.org/peps/pep-0290.html. Developers with CVS access can add their contributions or improvements be directly to the PEP. Over time, it is expected to grow and serve as a repository of collective wisdom regarding version upgrades.

1 0

Re: [Python-Dev] 'new' and 'types'
by Oren Tirosh 17 Jun '02

17 Jun '02

On Mon, Jun 17, 2002 at 09:49:05AM -0400, Greg Ward wrote: > On 14 June 2002, Oren Tirosh said: > > Patch 568629 removes the built-in module new (with sincere apologies to > > Tommy Burnette ;-) and replaces it with a tiny Python module consisting of a > > single import statement: > [...] > > Now, what about the types module? It has been suggested that this module > > should be deprecated. I think it still has some use: we need a place to put > > all the types that are not used often enough to be added to the builtins. > > I suggest that they be placed in the module 'types' with names matching their > > __name__ attribute. The types module will still have the long MixedCaseType > > names for backward compatibility. The use of the long names should be > > deprecated, not the types module itself. > > Two great ideas. I think you should write up a *short* PEP to keep them > alive -- this feels like one of those small, not-too-controversial > changes that will slip between the cracks unless/until someone with > checkin privs takes up the cause. Don't let that discourage you! The first is very much alive - my patch for the new module has already been checked in by Guido. No need for a PEP there because it's a transparent change. For the types module I have a pending patch but I guess it won't sneak into the CVS without a PEP. It requires general agreement that it's a bad thing for types to have two names, that the long names should be deprecated and that the right place for short names that are not builtins is in the types module. It's PEP time... Oren

2 1

Re: [Python-checkins] python/dist/src/Modules unicodedata.c,2.16,2.17
by Michael Hudson 17 Jun '02

17 Jun '02

Guido van Rossum <guido(a)python.org> writes: > > in my experience, simple names without underscores always conflicts > > with something on platforms that I don't have access to, while simple > > names with leading underscores never causes any problems... > > Unfortunately, that's exactly the opposite of what the C > standardization committee wants you to do. Huh? I thought underscore-lowercase character was fine, and double-underscore and underscore-capital were the verboten combinations. Cheers, M. -- SPIDER: 'Scuse me. [scuttles off] ZAPHOD: One huge spider. FORD: Polite though. -- The Hitch-Hikers Guide to the Galaxy, Episode 11

2 1

Re: [Python-Dev] extended slicing again
by Michael Hudson 17 Jun '02

17 Jun '02

Email back. Guido van Rossum <guido(a)python.org> writes: > > The trouble is, there's no way to distinguish between > > > > l1[a:b:] > > l1[slice(a,b)] > > > > I deliberately made the former be the same as l1[a:b:1] (and so have the > > restriction on the length of slice) to reduce special-casing (both for > > the user and me). Do you think I got that wrong? > > Yes I think you got that wrong. __getslice__ and __setlice__ are > being deprecated (or at least discouraged), so you'll have objects > implementing only __getitem__. Such objects will get a slice object > passed to __getitem__ even for simple (one-colon) slices. If such an > object wants to pass the slice on to a list object underlying the > implementation, it should be allowed to. > > IOW slice(a, b, None) should be considered equivalent to L[a:b] in all > situations. OK. I'll do this soon. It's not as bad as I thought at first -- only mutable sequences are affected, so it's only lists and arrays that need to be tweaked. Cheers, M. -- Our lecture theatre has just crashed. It will currently only silently display an unexplained line-drawing of a large dog accompanied by spookily flickering lights. -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year)

1 0

(no subject)
by Michael Hudson 17 Jun '02

17 Jun '02

My starship mail currently seems to be broken in and out, so this is my first mail sent with Mac OS X's Mail.app. I hope it comes out plain text... > Current CVS says: > > >>> a = range(12) > >>> t0,t1 = a,slice(2, 9) > >>> t0[t1] = t0[t1] + [666] > Traceback (most recent call last): > File "<stdin>", line 1, in ? > ValueError: attempt to assign list of size 8 to extended slice of > size 7 > > I suspect this is a bug, since I didn't ask for an extended slice. Yes you did :) If you'd have tried that with any released Python, you'd have got a TypeError. The trouble is, there's no way to distinguish between l1[a:b:] l1[slice(a,b)] I deliberately made the former be the same as l1[a:b:1] (and so have the restriction on the length of slice) to reduce special-casing (both for the user and me). Do you think I got that wrong? Cheers, M.

2 1

test_socket failures
by Guido van Rossum 16 Jun '02

16 Jun '02

I know that there are problem with the two new socket tests: test_timeout and test_socket. The problems are varied: the tests assume network access and a working and consistent DNS, they assume predictable timing, and there is a number of Windows-specific failures that I'm trying to track down. Also, when the full test suite is run, test_socket.py may hang, while in isolation it will work. (Gosh if only we had had these unit tests a few years ago. They bring up all sorts of issues that are good to know about.) I'll try to fix these ASAP. --Guido van Rossum (home page: http://www.python.org/~guido/)

2 2

Weekly Python Bug/Patch Summary
by Skip Montanaro 16 Jun '02

16 Jun '02

Bug/Patch Summary ----------------- 254 open / 2582 total bugs (-12) 128 open / 1554 total patches (-3) New Bugs -------- tarball to untar into a single dir (2002-06-11) http://python.org/sf/567576 whatsnew explains noargs incorrectly (2002-06-11) http://python.org/sf/567607 Various Playstation 2 Linux Test Errors (2002-06-12) http://python.org/sf/567892 urllib needs 303/307 handlers (2002-06-12) http://python.org/sf/568068 asynchat module undocumented (2002-06-12) http://python.org/sf/568134 Misleading string constant. (2002-06-12) http://python.org/sf/568269 socket module htonl/ntohl bug (2002-06-12) http://python.org/sf/568322 minor improvement to Grammar file (2002-06-13) http://python.org/sf/568412 __slots__ attribute and private variable (2002-06-14) http://python.org/sf/569257 cgi.py broken with xmlrpclib on Python 2 (2002-06-15) http://python.org/sf/569316 LINKCC incorrectly set (2002-06-16) http://python.org/sf/569668 New Patches ----------- unicode in sys.path (2002-06-10) http://python.org/sf/566999 GetFInfo update (2002-06-11) http://python.org/sf/567296 A different patch for python-mode vs gdb (2002-06-11) http://python.org/sf/567468 Add param to email.Utils.decode() (2002-06-12) http://python.org/sf/568348 Convert slice and buffer to types (2002-06-13) http://python.org/sf/568544 gettext module charset changes (2002-06-13) http://python.org/sf/568669 Implementation of major, minor and makedev (2002-06-14) http://python.org/sf/569139 names in types module (2002-06-15) http://python.org/sf/569328 plain text enhancement for cgitb (2002-06-15) http://python.org/sf/569574 Closed Bugs ----------- tuple __getitem__ limited (2001-09-06) http://python.org/sf/459235 str, __getitem__ and slices (2001-10-23) http://python.org/sf/473985 string.{starts,ends}with vs slices (2001-12-16) http://python.org/sf/493951 HTMLParser fail to handle '&foobar' (2002-01-06) http://python.org/sf/500073 markupbase handling of HTML declarations (2002-01-19) http://python.org/sf/505747 Recursive class instance "error" (2002-03-20) http://python.org/sf/532646 fcntl module with wrong module for ioctl (2002-04-30) http://python.org/sf/550777 deepcopy can't handle custom metaclasses (2002-05-26) http://python.org/sf/560794 Assertion with very long lists (2002-05-29) http://python.org/sf/561858 test_signal.py fails on FreeBSD-4-stable (2002-05-29) http://python.org/sf/562188 xmlrpclib.Binary.data undocumented (2002-05-31) http://python.org/sf/562878 Clarify documentation for inspect (2002-06-01) http://python.org/sf/563273 os.tmpfile should use w+b, not w+ (2002-06-02) http://python.org/sf/563750 getttext defaults with unicode (2002-06-03) http://python.org/sf/563915 IDLE needs printing (2002-06-06) http://python.org/sf/565373 urllib FancyURLopener.__init__ / urlopen (2002-06-06) http://python.org/sf/565414 string.replace() can corrupt heap (2002-06-07) http://python.org/sf/565993 telnetlib makes Python dump core (2002-06-07) http://python.org/sf/566006 rotormodule's set_key calls strlen (2002-06-10) http://python.org/sf/566859 Typo in "What's new in Python 2.3" (2002-06-10) http://python.org/sf/566869 Closed Patches -------------- experimental support for extended slicing on lists (2000-07-27) http://python.org/sf/400998 getopt with GNU style scanning (2001-10-21) http://python.org/sf/473512 AtheOS port of Python 2.2b2 (2001-12-02) http://python.org/sf/488073 Silence AIX C Compiler Warnings. (2002-03-21) http://python.org/sf/533070 Floating point issues in body of text (2002-04-26) http://python.org/sf/548943 Deprecate bsddb (2002-05-06) http://python.org/sf/553108 Prevent duplicates in readline history (2002-05-30) http://python.org/sf/562492 First patch: start describing types... (2002-05-30) http://python.org/sf/562529 posixmodule.c RedHat 6.1 (bug #535545) (2002-06-03) http://python.org/sf/563954 error in weakref.WeakKeyDictionary (2002-06-04) http://python.org/sf/564549 modulefinder and string methods (2002-06-05) http://python.org/sf/564840 fix bug in shutil.rmtree exception case (2002-06-09) http://python.org/sf/566517

1 0

SF bug count
by Gordon McMillan 16 Jun '02

16 Jun '02

Hi all, SF's "tracker" page http://sourceforge.net/tracker/?group_id=5470 says there are a total of 2581 bugs. Using a url template of (broken so as to be readable): bugurlfmt = http://sourceforge.net/tracker/index.php ?group_id=5470 &atid=105470 &set=custom &_assigned_to=100 &_status=100 &_category=100 &_group=100 &order=artifact_id &sort=ASC&offset=%d to get 51 at a time, I get only 636. Whose bug? -- Gordon http://www.mcmillan-inc.com/

3 3

'new' and 'types'
by Oren Tirosh 14 Jun '02

14 Jun '02

Patch 568629 removes the built-in module new (with sincere apologies to Tommy Burnette ;-) and replaces it with a tiny Python module consisting of a single import statement: """This module is no longer required except for backward compatibility. Objects of most types can now be created by calling the type object. """ from types import \ ClassType as classobj, \ CodeType as code, \ FunctionType as function, \ InstanceType as instance, \ MethodType as instancemethod, \ ModuleType as module These types (as well as buffer and slice) have been made callable. It looks like the Python core no longer has any objects that are created by a separate factory function (there are still some in the Modules). Now, what about the types module? It has been suggested that this module should be deprecated. I think it still has some use: we need a place to put all the types that are not used often enough to be added to the builtins. I suggest that they be placed in the module 'types' with names matching their __name__ attribute. The types module will still have the long MixedCaseType names for backward compatibility. The use of the long names should be deprecated, not the types module itself. Oren

2 1

Re: [Python-Dev] [development doc updates]
by David Abrahams 14 Jun '02

14 Jun '02

Hi Fred, I wasn't aware of how it would be formatted when I submitted my PyObject_RichCompare patches. I think the different italic "op" usages are too similar. Probably \emph should be replaced with something that bold-ifies. Best, Dave ----- Original Message ----- From: "Fred L. Drake" <fdrake(a)acm.org> To: <python-dev(a)python.org>; <doc-sig(a)python.org>; <python-list(a)python.org> Sent: Friday, June 14, 2002 8:20 AM Subject: [Python-Dev] [development doc updates] > The development version of the documentation has been updated: > > http://www.python.org/dev/doc/devel/ > > Updated to reflect recent changes. > > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev

2 3