Mailman 3 January 2001 - Python-Dev

webbrowser.py
by Eric S. Raymond 25 Jan '01

25 Jan '01

Ping's complaints are justified -- I've been looking at and testing webbrowser.py and it's a mess. Among other things: 1. The BROWSER variable is not interpreted properly. 2. The code is stupid about loading platform support it doesn't need. 3. It's not possible to specify lynx as a browser under Unix, because the computation of available browsers is split in two and partly done inside the CommandLineBrowser class. 3. The module code is excessively hard to read, obscuring these bugs. Our mistake was hurriedly merging the launcher code from IDLE with the browser-finder hack I wrote (the guts of CommandLineBrowser). The resulting code is a bad, overcomplicated architecture with a nasty seam in it. As co-designer/implementor I should have caught this sooner, but I was in a hurry to get a CML2 prototype out the door and didn't test anything but the case I needed. My apologies to all. I'm rewriting to fix these problems now. Documented semantics of entry points will be preserved. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The politician attempts to remedy the evil by increasing the very thing that caused the evil in the first place: legal plunder. -- Frederick Bastiat

7 18

Documentation patch for waiting method.
by Eric S. Raymond 25 Jan '01

25 Jan '01

Index: libstdtypes.tex =================================================================== RCS file: /cvsroot/python/python/dist/src/Doc/lib/libstdtypes.tex,v retrieving revision 1.50 diff -u -r1.50 libstdtypes.tex --- libstdtypes.tex 2001/01/17 01:18:00 1.50 +++ libstdtypes.tex 2001/01/25 16:46:40 @@ -1142,6 +1142,24 @@ \UNIX{} versions support this operation). \end{methoddesc} +\begin{methoddesc}[file]{waiting}{} + Return the number of bytes waiting to be read from this file object. + For regular files, this returns the size of the file in bytes minus + the current seek address, as would be returned by \method{tell()}; a + zero return can be used to detect EOF. For streams such as FIFOs, + sockets, Unix ttys, and other Unix character devices, this method + returns the number of bytes currently buffered up and waiting to be + read. Attempts to call this method on Unix block devices or + on directories will raise an error. + \footnote{The \method{waiting()} method uses + \cfunction{fstat(2)} and \cfunction{lseek(2)} on plain files; + these should be reliable on all of Unix, Windows, and MacOS. + It uses the FIONREAD ioctl(2) call to query FIFOs, sockets, + Unix ttys, and other POSIX character devices; FIFO and socket + behavior should be consistent across all three platforms, but + the results from querying other character devices may vary.} +\end{methoddesc} + \begin{methoddesc}[file]{write}{str} Write a string to the file. There is no return value. Note: Due to buffering, the string may not actually show up in the file until -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "To disarm the people... was the best and most effectual way to enslave them." -- George Mason, speech of June 14, 1788

1 0

Anonymous + varargs: possible serious breakage -- please confirm!
by Ka-Ping Yee 25 Jan '01

25 Jan '01

Hi -- after updating my CVS tree today with Python 2.1a1, i ran the tests and test_inspect failed. This revealed that the format of code.co_varnames has changed. At first i tried to update the inspect.py module to check the Python version number and track the change, but now i believe this is actually symptomatic of a real interpreter problem. Consider the function: def f(a, (b, c), *d): x = 1 print a, b, c, d, x Whereas in Python 1.5.2: f.func_code.co_argcount = 2 f.func_code.co_nlocals = 6 f.func_code.co_names = ('x', 'a', 'b', 'c', 'd') f.func_code.co_varnames = ('a', '.2', 'd', 'b', 'c', 'x') In Python 2.1a1: f.func_code.co_argcount = 2 f.func_code.co_nlocals = 6 f.func_code.co_names = ('b', 'c', 'x', 'a', 'd') f.func_code.co_varnames = ('a', '.2', 'b', 'c', 'd', 'x') Notice how the ordering of the variable names has changed. I went and looked at the CO_VARARGS clause in eval_code2 to see if it put the varargs and kwdict arguments in different slots, but it appears unchanged! It still puts varargs at locals[co_argcount] and kwdict at locals[co_argcount + 1]. Please try: >>> def f(a, (b, c), *d): ... x = 1 ... print a, b, c, d, x ... >>> f(1, (2, 3), 4) 1 2 3 Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 3, in f UnboundLocalError: local variable 'd' referenced before assignment >>> In Python 1.5.2, this prints "1 2 3 (4,)" as expected. I only have 1.5.2 and 2.1a1 to test. I hope this problem isn't present in 2.0... Note that test_inspect was the only test to fail! It might be the only test that checks anonymous and *varargs at the same time. (Yet another reason to put inspect in the core...) I did recently check in additions to test_extcall that made the test much beefier -- but that only tested combinations of regular, keyword, varargs, and kwdict arguments; it neglected to test anonymous (tuple) arguments as well. -- ?!ng

3 2

Intended to work? (lambda x,y:map(eval, ["x", "y"]))(2,3)
by Christian Tismer 25 Jan '01

25 Jan '01

In a function like this: def f(x): return eval("x") , eval uses the local function namespace, and the above works. This is according to chapter 2.3 of the Python library ref. Now on my problem: When eval() is used with map, the same mechanism takes place: def f(x): return map(eval,["x"]) It works the same as the above, because map is a builtin function that does not modify the frame chain, so eval finds the local namespace. Not so with Stackless Python (at the moment), since Stackless map assigns an own frame to map without passing the correct namespaces to it. (Reported by Bernd Rinn) Question: Is this by chance, or is eval() *meant* to function with the local namespace, even if it is executed in the context of a function like map() ? The description of map() does not state whether it has to pass its surrounding namespace to the mapped function, and if one simulates map() by writing one's own python implementation, it will fail exactly like Stackless does today. The same applies to apply(). I think I should fix Stackless here, anyway? ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com

2 1

Re: [Python-checkins] CVS: python/dist/src/Doc/lib libwinsound.tex,1.5,1.6
by Fredrik Lundh 25 Jan '01

25 Jan '01

tim accidentally wrote: > \versionadded{1.5.3} % XXX fix this version number when release is scheduled! 1.5.3? time for a 1.5.3 => 1.6 query replace? > fgrep 1.5.3 doc/*/*.tex doc/lib/libcmp.tex:\deprecated{1.5.3}{Use the \module{filecmp} module inste doc/lib/libcmpcache.tex:\deprecated{1.5.3}{Use the \module{filecmp} module ad.} doc/lib/libwinsound.tex: \versionadded{1.5.3} % XXX fix this version number or am I missing something? Cheers /F

2 1

Re: [Python-Dev] I think my set module is ready for prime time; comments?
by Greg Wilson 25 Jan '01

25 Jan '01

Greg Wilson: Meta-question: do people want to continue to discuss sets on the general python-dev list, or take it out-of-line (e.g. to an egroups list)? I'm finding all of the discussion very useful, but I realize that many readers might prefer to concentrate on the 2.1 release... > Jeremy Hylton <jeremy(a)alum.mit.edu>: > > The tests showed that dictionary-based sets were always faster. > > small tests (3 operations), the difference was about 10 percent. > > larger tests (88 operations), the difference ranged from > > 180 to almost 700 percent. > Eric Raymond <esr(a)thyrsus.com>: > Not surprising. 88 elements is getting pretty large. Greg Wilson: Really? I was testing my implementation with sets of email addresses grep'd out of old mail folders --- typical sizes were several thousand elements. > From: Christopher Petrilli <petrilli(a)amber.org> > Unfortunately, for me, a Python implementation of Sets is only > interesting academicaly. Any time I've needed to work with them at a > large scale, I've needed them *much* faster than Python could achieve > without a C extension. Greg Wilson: I had been expecting to implement this in C, not in pure Python, for performance. > From: Christopher Petrilli <petrilli(a)amber.org> > In the "scripting" problem domain, I would agree that Sets would > rarely reach large sizes, > and so a algorithm which performed in quadratic time might be fine, Greg Wilson: I strongly disagree (see the email address example above --- it was the first thing that occurred to me to try). I am still hoping to find a sub-quadratic (preferably sub-linear) implementation. I can do it in C++ with observer/observable (contained items notify containers of changes in value, sets store all equivalent items in the same bucket), but that doesn't really help... > From: Ka-Ping Yee <ping(a)lfw.org> > The only change that needs to be made to support sets of immutable > elements is to provide "in" on dictionaries... and: > From: Neil Schemenauer <nas(a)arctrix.com> > ...if sets are added to the core...we would > use the implementation of PyDict but drop the values. Unfortunately, if values are required to be immutable, then sets of sets aren't possible... :-( Thanks, everyone, Greg

2 1

I think my set module is ready for prime time; comments?
by Eric S. Raymond 25 Jan '01

25 Jan '01

\section{\module{set} --- Basic set algebra for Python} \declaremodule{standard}{set} \modulesynopsis{Basic set algebra operations on sequences.} \moduleauthor{Eric S. Raymond}{esr(a)thyrsus.com} \sectionauthor{Eric S. Raymond}{esr(a)thyrsus.com} The \module{set} module defines functions for treating lists and other sequences as mathematical sets, and defines a set class that uses these operations natively and overloads Python's standard operator set. The \module{set} functions work on any sequence type and return lists. The set methods can take a set or any sequence type as an argument. Set or sequence elements may be of any type and may be mutable. Comparisons and membership tests of elements against sequence objects are done using \keyword{in}, and so can be customized by supplying a suitable \method{__getattr__} method for the sequence type. The running time of these functions is O(n**2) in the worst case unless otherwise noted. For cases that can be short-circuited by cardinality comparisons, this has been done. \begin{funcdesc}{setify}{list1} Returns a list of the argument sequence's elements with duplicates removed. \end{funcdesc} \begin{funcdesc}{union}{list1, list2} Set union. All elements of both sets or sequences are returned. \end{funcdesc} \begin{funcdesc}{intersection}{list1, list2} Set intersection. All elements common to both sets or sequences are returned. \end{funcdesc} \begin{funcdesc}{difference}{list1, list2} Set difference. All elements of the first set or sequence not present in the second are returned. \end{funcdesc} \begin{funcdesc}{symmetric_difference}{list1, list2} Set symmetric difference. All elements present in one sequence or the other but not in both are returned. \end{funcdesc} \begin{funcdesc}{cartesian}{list1, list2} Returns a list of tuples consisting of all possible pairs of elements from the first and second sequences or sets. \end{funcdesc} \begin{funcdesc}{equality}{list1, list2} Set comparison. Return 1 if the two sets or sequences contain exactly the same elements, 0 or otherwise. \end{funcdesc} \begin{funcdesc}{subset}{list1, list2} Set subset test. Return 1 if all elements of the fiorst set or sequence are members of the second, 0 otherwise. \end{funcdesc} \begin{funcdesc}{proper_subset}{list1, list2} Set subset test, excluding equality. Return 1 if the arguments fail a set equality test, and all elements of the fiorst set or sequence are members of the second, 0 otherwise. \end{funcdesc} \begin{funcdesc}{powerset}{list1} Return the set of all subsets of the argument set or sequence. Warning: this produces huge results from small arguments and is O(2**n) in both running time and space requirements; you can readily run yourself out of memory using it. \end{funcdesc} \subsection{set Objects \label{set-objects}} A \class{set} instance uses the \module{set} module functions to implement set semantics on the list it contains, and to support a full set of Python list methods and operaors. Thus, the set methods can take a set or any sequence type as an argument. A set object contains a single data member: \begin{memberdesc}{elements} List containing the elements of the set. \end{memberdesc} Set objects can be treated as mutable sequences; they support the special methods \method{__len__}, \method{__getattr__}, \method{__setattr__}, and \method{__delattr__}. Through \method{__getattr__}, they support the memebership test via \keyword{in}. All the standard mutable-sequence methods \method{list}, \method{append}, \method{extend}, \method{count}, \method{index}, \method{insert} (the index argument is ignored), \method{pop}, \method{remove}, \method{reverse}, and \method{sort} are also supported. After method calls that add elements (\method{setattr}, \method{append}, \method{extend}, \method{insert}), the elements of the data member are re-setified, so it is not possible to introduce duplicates. Calling \function{repr()} on a set returns the result of calling \function{repr} on its element list. Calling \function{str()} returns a representation resembling mathematical notation for the set; an open set bracket, followed by a comma-separated list of \function{str()} representations of the elements, followed by a close set brackets. Set objects support the following Python operators: \begin {tableiii}{l|l|l}{code}{Operator}{Function}{Description} \lineiii{|,+}{union}{Union} \lineiii{&}{intersection}{Intersection} \lineiii{-}{difference}{Difference} \lineiii{^}{symmetric_difference}{Symmetric differe} \lineiii{*}{cartesian}{Cartesian product} \lineiii{==}{equality}{Equality test} \lineiii{!=,<>}{}{Inequality test} \lineiii{<}{proper_subset}{Proper-subset test} \lineiii{<=}{subset}{Subset test} \lineiii{>}{}{Proper superset test} \lineiii{>=}{}{Superset test} \end {tableiii} -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Government is actually the worst failure of civilized man. There has never been a really good one, and even those that are most tolerable are arbitrary, cruel, grasping and unintelligent. -- H. L. Mencken

6 15

Python 2.1 alpha 1 released!
by Guido van Rossum 25 Jan '01

25 Jan '01

Thanks to the PythonLabs developers and the many hard-working volunteers, I'm proud to release Python 2.1a1 -- the first alpha release of Python version 2.1. The release mechanics are different than for previous releases: we're only releasing through SourceForge for now. The official source tarball is already available from the download page: http://sourceforge.net/project/showfiles.php?group_id=5470 Additional files will be released soon: a Windows installer, Linux RPMs, and documentation. Please give it a good try! The only way Python 2.1 can become a rock-solid product is if people test the alpha releases. Especially if you are using Python for demanding applications or on extreme platforms we are interested in hearing your feedback. Are you embedding Python or using threads? Please test your application using Python 2.1a1! Please submit all bug reports through SourceForge: http://sourceforge.net/bugs/?group_id=5470 Here's the NEWS file: What's New in Python 2.1 alpha 1? ================================= Core language, builtins, and interpreter - There is a new Unicode companion to the PyObject_Str() API called PyObject_Unicode(). It behaves in the same way as the former, but assures that the returned value is an Unicode object (applying the usual coercion if necessary). - The comparison operators support "rich comparison overloading" (PEP 207). C extension types can provide a rich comparison function in the new tp_richcompare slot in the type object. The cmp() function and the C function PyObject_Compare() first try the new rich comparison operators before trying the old 3-way comparison. There is also a new C API PyObject_RichCompare() (which also falls back on the old 3-way comparison, but does not constrain the outcome of the rich comparison to a Boolean result). The rich comparison function takes two objects (at least one of which is guaranteed to have the type that provided the function) and an integer indicating the opcode, which can be Py_LT, Py_LE, Py_EQ, Py_NE, Py_GT, Py_GE (for <, <=, ==, !=, >, >=), and returns a Python object, which may be NotImplemented (in which case the tp_compare slot function is used as a fallback, if defined). Classes can overload individual comparison operators by defining one or more of the methods__lt__, __le__, __eq__, __ne__, __gt__, __ge__. There are no explicit "reflected argument" versions of these; instead, __lt__ and __gt__ are each other's reflection, likewise for__le__ and __ge__; __eq__ and __ne__ are their own reflection (similar at the C level). No other implications are made; in particular, Python does not assume that == is the Boolean inverse of !=, or that < is the Boolean inverse of >=. This makes it possible to define types with partial orderings. Classes or types that want to implement (in)equality tests but not the ordering operators (i.e. unordered types) should implement == and !=, and raise an error for the ordering operators. It is possible to define types whose rich comparison results are not Boolean; e.g. a matrix type might want to return a matrix of bits for A < B, giving elementwise comparisons. Such types should ensure that any interpretation of their value in a Boolean context raises an exception, e.g. by defining __nonzero__ (or the tp_nonzero slot at the C level) to always raise an exception. - Complex numbers use rich comparisons to define == and != but raise an exception for <, <=, > and >=. Unfortunately, this also means that cmp() of two complex numbers raises an exception when the two numbers differ. Since it is not mathematically meaningful to compare complex numbers except for equality, I hope that this doesn't break too much code. - Functions and methods now support getting and setting arbitrarily named attributes (PEP 232). Functions have a new __dict__ (a.k.a. func_dict) which hold the function attributes. Methods get and set attributes on their underlying im_func. It is a TypeError to set an attribute on a bound method. - The xrange() object implementation has been improved so that xrange(sys.maxint) can be used on 64-bit platforms. There's still a limitation that in this case len(xrange(sys.maxint)) can't be calculated, but the common idiom "for i in xrange(sys.maxint)" will work fine as long as the index i doesn't actually reach 2**31. (Python uses regular ints for sequence and string indices; fixing that is much more work.) - Two changes to from...import: 1) "from M import X" now works even if M is not a real module; it's basically a getattr() operation with AttributeError exceptions changed into ImportError. 2) "from M import *" now looks for M.__all__ to decide which names to import; if M.__all__ doesn't exist, it uses M.__dict__.keys() but filters out names starting with '_' as before. Whether or not __all__ exists, there's no restriction on the type of M. - File objects have a new method, xreadlines(). This is the fastest way to iterate over all lines in a file: for line in file.xreadlines(): ...do something to line... See the xreadlines module (mentioned below) for how to do this for other file-like objects. - Even if you don't use file.xreadlines(), you may expect a speedup on line-by-line input. The file.readline() method has been optimized quite a bit in platform-specific ways: on systems (like Linux) that support flockfile(), getc_unlocked(), and funlockfile(), those are used by default. On systems (like Windows) without getc_unlocked(), a complicated (but still thread-safe) method using fgets() is used by default. You can force use of the fgets() method by #define'ing USE_FGETS_IN_GETLINE at build time (it may be faster than getc_unlocked()). You can force fgets() not to be used by #define'ing DONT_USE_FGETS_IN_GETLINE (this is the first thing to try if std test test_bufio.py fails -- and let us know if it does!). - In addition, the fileinput module, while still slower than the other methods on most platforms, has been sped up too, by using file.readlines(sizehint). - Support for run-time warnings has been added, including a new command line option (-W) to specify the disposition of warnings. See the description of the warnings module below. - Extensive changes have been made to the coercion code. This mostly affects extension modules (which can now implement mixed-type numerical operators without having to use coercion), but occasionally, in boundary cases the coercion semantics have changed subtly. Since this was a terrible gray area of the language, this is considered an improvement. Also note that __rcmp__ is no longer supported -- instead of calling __rcmp__, __cmp__ is called with reflected arguments. - In connection with the coercion changes, a new built-in singleton object, NotImplemented is defined. This can be returned for operations that wish to indicate they are not implemented for a particular combination of arguments. From C, this is Py_NotImplemented. - The interpreter accepts now bytecode files on the command line even if they do not have a .pyc or .pyo extension. On Linux, after executing echo ':pyc:M::\x87\xc6\x0d\x0a::/usr/local/bin/python:' > /proc/sys/fs/binfmt_misc/register any byte code file can be used as an executable (i.e. as an argument to execve(2)). - %[xXo] formats of negative Python longs now produce a sign character. In 1.6 and earlier, they never produced a sign, and raised an error if the value of the long was too large to fit in a Python int. In 2.0, they produced a sign if and only if too large to fit in an int. This was inconsistent across platforms (because the size of an int varies across platforms), and inconsistent with hex() and oct(). Example: >>> "%x" % -0x42L '-42' # in 2.1 'ffffffbe' # in 2.0 and before, on 32-bit machines >>> hex(-0x42L) '-0x42L' # in all versions of Python The behavior of %d formats for negative Python longs remains the same as in 2.0 (although in 1.6 and before, they raised an error if the long didn't fit in a Python int). %u formats don't make sense for Python longs, but are allowed and treated the same as %d in 2.1. In 2.0, a negative long formatted via %u produced a sign if and only if too large to fit in an int. In 1.6 and earlier, a negative long formatted via %u raised an error if it was too big to fit in an int. - Dictionary objects have an odd new method, popitem(). This removes an arbitrary item from the dictionary and returns it (in the form of a (key, value) pair). This can be useful for algorithms that use a dictionary as a bag of "to do" items and repeatedly need to pick one item. Such algorithms normally end up running in quadratic time; using popitem() they can usually be made to run in linear time. Standard library - In the time module, the time argument to the functions strftime, localtime, gmtime, asctime and ctime is now optional, defaulting to the current time (in the local timezone). - The ftplib module now defaults to passive mode, which is deemed a more useful default given that clients are often inside firewalls these days. Note that this could break if ftplib is used to connect to a *server* that is inside a firewall, from outside; this is expected to be a very rare situation. To fix that, you can call ftp.set_pasv(0). - The module site now treats .pth files not only for path configuration, but also supports extensions to the initialization code: Lines starting with import are executed. - There's a new module, warnings, which implements a mechanism for issuing and filtering warnings. There are some new built-in exceptions that serve as warning categories, and a new command line option, -W, to control warnings (e.g. -Wi ignores all warnings, -We turns warnings into errors). warnings.warn(message[, category]) issues a warning message; this can also be called from C as PyErr_Warn(category, message). - A new module xreadlines was added. This exports a single factory function, xreadlines(). The intention is that this code is the absolutely fastest way to iterate over all lines in an open file(-like) object: import xreadlines for line in xreadlines.xreadlines(file): ...do something to line... This is equivalent to the previous the speed record holder using file.readlines(sizehint). Note that if file is a real file object (as opposed to a file-like object), this is equivalent: for line in file.xreadlines(): ...do something to line... - The bisect module has new functions bisect_left, insort_left, bisect_right and insort_right. The old names bisect and insort are now aliases for bisect_right and insort_right. XXX_right and XXX_left methods differ in what happens when the new element compares equal to one or more elements already in the list: the XXX_left methods insert to the left, the XXX_right methods to the right. Code that doesn't care where equal elements end up should continue to use the old, short names ("bisect" and "insort"). - The new curses.panel module wraps the panel library that forms part of SYSV curses and ncurses. Contributed by Thomas Gellekum. - The SocketServer module now sets the allow_reuse_address flag by default in the TCPServer class. - A new function, sys._getframe(), returns the stack frame pointer of the caller. This is intended only as a building block for higher-level mechanisms such as string interpolation. Build issues - For Unix (and Unix-compatible) builds, configuration and building of extension modules is now greatly automated. Rather than having to edit the Modules/Setup file to indicate which modules should be built and where their include files and libraries are, a distutils-based setup.py script now takes care of building most extension modules. All extension modules built this way are built as shared libraries. Only a few modules that must be linked statically are still listed in the Setup file; you won't need to edit their configuration. - Python should now build out of the box on Cygwin. If it doesn't, mail to Jason Tishler (jlt63 at users.sourceforge.net). - Python now always uses its own (renamed) implementation of getopt() -- there's too much variation among C library getopt() implementations. - C++ compilers are better supported; the CXX macro is always set to a C++ compiler if one is found. Windows changes - select module: By default under Windows, a select() call can specify no more than 64 sockets. Python now boosts this Microsoft default to 512. If you need even more than that, see the MS docs (you'll need to #define FD_SETSIZE and recompile Python from source). - Support for Windows 3.1, DOS and OS/2 is gone. The Lib/dos-8x3 subdirectory is no more! --Guido van Rossum (home page: http://www.python.org/~guido/)

3 2

Re: [Python-Dev] I think my set module is ready for prime time; comments?
by uche.ogbuji＠fourthought.com 24 Jan '01

24 Jan '01

> Guido van Rossum <guido(a)digicool.com>: > > There's already a PEP on a set object type, and everybody and their > > aunt has already implemented a set datatype. Tim mentioned that he had one, and he also claimed that every other dodder had a set class, but the only one listed in the vaults is kjBuckets, which I'm not sure is maintained any more. (Is Aaron Watters hereabouts?) > I've just read the PEP. Greg's proposal has a couple of problems. > The biggest one is that the interface design isn't very Pythonic -- > it's formally adequate, but doesn't exploit the extent to which sets > naturally have common semantics with existing Python sequence types. > This is bad; it means that a lot of code that could otherwise ignore > the difference between lists and sets would have to be specialized > one way or the other for no good reason. IMO, Eric's Set interface is close to perfect. PEP 218 is interesting, but I'm not sure it's worth slogging through the inevitable uproar over an entirely new syntactic construct (the "{}" notation) before getting something as useful as a set class into the standard library. > > If *your* set module is ready for prime time, why not publish it in > > the Vaults of Parnassus? > > I suppose that's what I'll do if you don't bless it for the standard > library. But here are the reasons I suggest you should do so: For what it's worth, I'm +1 on adding this to the standard library. I've seen so many set hacks with dictionaries (memory ouch) and list hacks (speed ouch) in Python code out there, that I'm convinced it would meet much more common usage than, say zlib, xdr, or even expat. On this hacker list everyone's aunt might whip up set extensions on boring weekends, but I doubt this describes the overall Python populace. -- Uche Ogbuji Principal Consultant uche.ogbuji(a)fourthought.com +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python

12 20

test___all__ failing; Windows
by Tim Peters 24 Jan '01

24 Jan '01

> python ../lib/test/regrtest.py test___all__ test___all__ test test___all__ crashed -- exceptions.AttributeError: 'locale' module has no attribute 'LC_MESSAGES' And indeed it does not: > python Python 2.1a1 (#9, Jan 24 2001, 04:40:55) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import locale >>> dir(locale) ['CHAR_MAX', 'Error', 'LC_ALL', 'LC_COLLATE', 'LC_CTYPE', 'LC_MONETARY', 'LC_NUMERIC', 'LC_TIME', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '_build_localename', '_group', '_parse_localename', '_print_locale', '_setlocale', '_test', 'atof', 'atoi', 'encoding_alias', 'format', 'getdefaultlocale', 'getlocale', 'locale_alias', 'localeconv', 'normalize', 'resetlocale', 'setlocale', 'str', 'strcoll', 'string', 'strxfrm', 'sys', 'windows_locale'] >>> Nor is LC_MESSAGES std C (the other LC_XXX guys are). I pin the blame on from _locale import * in locale.py -- who knows what that's supposed to export? Certainly not Skip <wink>.

6 11