Mailman 3 July 2005 - Python-Dev

Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
by Robert Brewer July 30, 2005

July 30, 2005

Brett Cannon wrote: > New Hierarchy > ============= > > Raisable (new; rename BaseException?) > +-- CriticalException (new) > +-- KeyboardInterrupt > +-- MemoryError > +-- SystemExit > +-- SystemError (subclass SystemExit?) I'd recommend not subclassing SystemExit--there are too many programs out there which expect the argument (e.g. sys.exit(3)) to mean something specific, but that expectation doesn't apply at all to SystemError. > +-- Exception (replaces StandardError) >... > +-- ControlFlowException (new) I'd definitely appreciate ControlFlowException--there are a number of exceptions in CherryPy which should subclass from that. Um, CherryPy 3.0, that is. ;) > +-- LookupError (better name?) SubscriptError, perhaps? But LookupError could become the "I didn't find obj X in the container you specified" superclass, in which case LookupError is perfect. > +-- TypeError > +-- AttributeError (subclassing new) "Since most attribute access errors can be attributed to an object not being the type that one expects, it makes sense for AttributeError to be considered a type error." Very hmmm. I would have thought it would be a LookupError instead, only because I favor the duck-typing parts of Python. Making AttributeError subclass from TypeError leans toward stronger typing models a bit too much, IMO. > +-- WeakReferenceError (rename for ReferenceError) This also has a LookupError feel to it. > It has been argued that Raisable is a bad name to use since it is not > an actual word [python-dev1]_. Perhaps, but compare http://www.onelook.com/?w=raisable to http://www.onelook.com/?w=raiseable. The only sources "raiseable" has going for it are Dictionary.com (which aggregates lots of questionable sources), Rhymezone, and LookWAYup. I think "raisable" is the clear winner. Robert Brewer System Architect Amor Ministries fumanchu(a)amor.org

7 8

Next PyPy sprint: Heidelberg (Germany), 22nd-29th of August
by Samuele Pedroni July 30, 2005

July 30, 2005

PyPy Sprint in Heidelberg 22nd - 29th August 2005 ================================================== The next PyPy sprint will take place at the Heidelberg University in Germany from 22nd August to 29th August (both days included). Its main focus is translation of the whole PyPy interpreter to a low level language and reaching 2.4.1 Python compliancy. To learn more about the new PyPy Python implementation look here: http://codespeak.net/pypy Goals and topics of the sprint ------------------------------ One of the main goals of the sprint is going to be a 0.7 release of PyPy. The 0.7 is meant to be the first self-contained PyPy version but still alpha with some C-extension modules missing and not meant for production use. Therefore the topics of the sprint will be: - translation efforts: it's not completely clear now what related task will be left at that time - work on 2.4.1 compliancy: there are some failing compliancy tests on which we plan to work - rewriting c-extension modules/integrating existing rewrites - all kinds of small release issues - possibly some more LLVM efforts Location & Accomodation ------------------------ The sprint will be held in a conference room of the Institute of Physics, University of Heidelberg. We have WLAN connection there and small kitchen to make tea and coffee. `See here`_ how to get there from the Heidelberg main station. There is a huge number of hotels_ in Heidelberg, all of which are unfortunately rather expensive. It should be no problem to reach the sprint venue from anywhere in Heidelberg. As an alternative you could also take a `hotel in Mannheim`_ which you can reach in 15 min from Heidelberg with the train. .. _`See here`: http://www.physi.uni-heidelberg.de/physi/front/anfahrt.en.php .. _hotels: http://www.cvb-heidelberg.de/index_eng.html .. _`hotel in Mannheim`: http://www.hotels.de/en/mannheim.htm Exact times ----------- The Pypy sprint is held Monday 22nd August - Monday 29th August 2005. Hours will be from 09:00 until people have had enough. It's a good idea to arrive a day before the sprint starts. Network, Food ------------- The Heidelberg Altstadt can be reached in approximately 10 min from the sprint venue. There you will find all kinds of restaurants and fast food places. You will probably need a wireless network card to access the network although we could set up a WLAN to cable bridge if necessary. Registration etc.pp. -------------------- Please subscribe to the `PyPy sprint mailing list`_, introduce yourself and post a note that you want to come. Feel free to ask any questions there! There also is a separate `Heidelberg people`_ page tracking who is already thought to come. If you have commit rights on codespeak then you can modify yourself a checkout of http://codespeak.net/svn/pypy/extradoc/sprintinfo/heidelberg-people.txt .. _`Heidelberg people`: http://codespeak.net/pypy/index.cgi?extradoc/sprintinfo/heidelberg-people.h… .. _`PyPy sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint -- Samuele Pedroni & the PyPy team

1 0

math.fabs redundant?
by skip＠pobox.com July 29, 2005

July 29, 2005

Why does math have an fabs function? Both it and the abs builtin function wind up calling fabs() for floats. abs() is faster to boot. Skip

2 1

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
by Tony Meyer July 29, 2005

July 29, 2005

[...] > Publish the Repositories > ======================== [...] > As an option, websvn (available > e.g. from the Debian websvn package) could be provided. Is there any reason that this should be an option, and not just done? For occasional source (particularly C source) lookups, I've found webcvs really useful (especially when on a machine without cvs or ssh). I presume that I'm not alone here. If there are issues with it (stability, security, whatever), then I could understand making it optional, but otherwise I think it would be great if the PEP just included it. =Tony.Meyer

2 1

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser July 29, 2005

July 29, 2005

Patch / Bug Summary ___________________ Patches : 357 open ( +7) / 2885 closed ( +3) / 3242 total (+10) Bugs : 898 open ( +9) / 5144 closed ( +3) / 6042 total (+12) RFE : 191 open ( +2) / 178 closed ( +0) / 369 total ( +2) New / Reopened Patches ______________________ shutil.copytree() quits too soon after an error. (2005-07-21) http://python.org/sf/1242454 opened by Dale Wilson bltinmodule.c whitespace normalization (2005-07-21) http://python.org/sf/1242579 opened by Ruslan Spivak repair typos (2005-07-22) CLOSED http://python.org/sf/1243081 opened by George Yoshida Faster output if message already has a boundary (2005-07-23) http://python.org/sf/1243654 opened by L. Peter Deutsch httplib gzip support (2005-07-23) http://python.org/sf/1243678 opened by Moonz Big speedup in email message parsing (2005-07-23) http://python.org/sf/1243730 opened by L. Peter Deutsch Patch for (Doc) #1243553 (2005-07-24) http://python.org/sf/1243910 opened by Peter van Kampen expat binding for XML_ParserReset (Bug #1208730) (2005-07-24) http://python.org/sf/1244208 opened by John Eikenberry Enable os.startfile and webbrowser.WindowsDefault on Cygwin (2005-07-25) http://python.org/sf/1244861 opened by Michael Hoffman hide tests from TestProgram (2005-07-25) http://python.org/sf/1244929 opened by Eric Huss Encoding alias "unicode-1-1-utf-7" (2005-07-26) http://python.org/sf/1245379 opened by Oren Tirosh weaklist (2001-11-30) http://python.org/sf/487738 reopened by fdrake Patches Closed ______________ optparse documentation bug fixes (2005-05-18) http://python.org/sf/1204347 closed by gward repair typos (2005-07-22) http://python.org/sf/1243081 closed by birkenfeld fileinput.py fixed clobbering behavior and added encodings (2004-10-15) http://python.org/sf/1048075 closed by cconnett Allow use of embedded Tcl without requiring Tk (2004-01-02) http://python.org/sf/869468 closed by gvanrossum New / Reopened Bugs ___________________ list(obj) can swallow KeyboardInterrupt (2005-07-22) http://python.org/sf/1242657 opened by Steve Alexander Incorrect documentation of re.UNICODE (2005-07-22) http://python.org/sf/1243192 opened by nhaldimann Misuse of "it's" (2005-07-22) CLOSED http://python.org/sf/1243288 opened by Joanne Bogart pydoc on cgi.escape lacks info that are in www docs (2005-07-23) http://python.org/sf/1243553 opened by Nikos Kouremenos Python function/method/constant names as HTML-tag IDs (2005-07-24) http://python.org/sf/1243945 opened by Chad Miller 2.4.1 build fails on OpenBSD 3.7 (2005-07-25) http://python.org/sf/1244610 opened by L. Peter Deutsch logging module needs to that it changed in 2.4 (2005-07-25) http://python.org/sf/1244683 opened by Alan Segfault in Python interpreter 2.3.5 (2005-07-25) http://python.org/sf/1244864 opened by Evil Mr Henry Time module is missing inverse of gmtime() (2005-07-26) http://python.org/sf/1245224 opened by Jeremy Fincher log() on a big number fails on powerpc64 (2005-07-26) http://python.org/sf/1245381 opened by Jiri Dluhos Segmentation fault when importing expat from xml.parser (2005-07-28) http://python.org/sf/1246405 opened by Jean-Pierre line numbers off by 1 (2005-07-27) http://python.org/sf/1246473 opened by Brett Cannon failure to build RPM on rhel 3 (2005-07-28) http://python.org/sf/1246900 opened by Patrick Wagstrom Bugs Closed ___________ Misuse of "it's" (2005-07-22) http://python.org/sf/1243288 closed by birkenfeld ioctl has problem with -ive request codes (2005-07-01) http://python.org/sf/1231069 closed by mwh ioctl has problems on 64 bit machines (2005-01-31) http://python.org/sf/1112949 closed by birkenfeld

1 0

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
by Tony Meyer July 28, 2005

July 28, 2005

> Do we also want to split off nondist and encodings? IWBNI > the Python source code proper weren't buried too deep in the > directory structure. +1 =Tony.Meyer

1 0

python-dev summary for 2005-07-01 to 2005-07-15 [draft]
by Steven Bethard July 28, 2005

July 28, 2005

Here's the draft for the first half of July. Please look especially close at the "GCC/G++ Issues on Linux" thread; I'm not sure I got all the details right. ============= Announcements ============= ------------------------------ QOTF (Quotes of the Fortnight) ------------------------------ Marc-Andre Lemburg provides perhaps the best summary to date of `how strings and Unicode should be used`_ in Python: To untie this Gordian Knot, we should use strings and Unicode like they are supposed to be used (in the context of text data): * strings are fine for text data that is encoded using the default encoding * Unicode should be used for all text data that is not or cannot be encoded in the default encoding Later on in Py3k, all text data should be stored in Unicode and all binary data in some new binary type. On a more entertaining note, Anthony Baxter describes the general outlook outlook on handling `threads vs signals`_: threads vs signals is a platform-dependant trail of misery, despair, horror and madness .. _how strings and Unicode should be used: http://mail.python.org/pipermail/python-dev/2005-July/054854.html .. _threads vs signals: http://mail.python.org/pipermail/python-dev/2005-July/054832.html ========= Summaries ========= --------------------------------------- PEP 343 Documentation: Context Managers --------------------------------------- Raymond Hettinger started a thread discussing how objects with __enter__ and __exit__ methods should be referred to in the official Python documentation. A few terms were thrown around, with "resource manager" being one of the early favorites. However, because the __enter__/__exit__ protocol handles a much more general construct that just the acquisition and release of a resource, this term steadily lost ground. Things like "locking objects are resource managed" and "decimal.Context() is a resource manager" sounded awkward and hard to explain. Phillip J. Eby suggested that objects with __enter__ and __exit__ methods could be called "context managers", and people seemed generally happy with this term. Nick Coghlan took this term, and some example use cases for "context managers", and put together a `draft documentation`_ for the section in the Python Library Reference. People liked Nick's wording, and after a few minor revisions (mainly to add more examples), it looked pretty complete. Nick promised to add a bit to the Python tutorial after he got a chance to play with the PEP 342_/343_ implementations. There was also a brief followup thread that discussed which objects in the stdlib should gain __enter__ and __exit__ methods in Python 2.5. It looks like decimal.Context objects will almost certainly become context managers, and there is some chance that a sys.redirected_stdout context manager might appear. .. _draft documentation: http://www.python.org/sf/1234057 .. _342: http://www.python.org/sf/1223381 .. _343: http://python.org/sf/1235943 Contributing threads: - `Terminology for PEP 343 <http://mail.python.org/pipermail/python-dev/2005-June/054525.html>`__ - `Terminology for PEP 343 <http://mail.python.org/pipermail/python-dev/2005-July/054530.html>`__ - `'With' context documentation draft (was Re: Terminology for PEP 343 <http://mail.python.org/pipermail/python-dev/2005-July/054658.html>`__ - `PEP 343 documentation on Sourceforge Patch tracker <http://mail.python.org/pipermail/python-dev/2005-July/054688.html>`__ - `Possible context managers in stdlib <http://mail.python.org/pipermail/python-dev/2005-July/054762.html>`__ [SJB] ----------------------- GCC/G++ Issues on Linux ----------------------- While in the past Python and Python extension modules could be compiled on Linux with different GCC versions as long as the 'C' ABIs were compatible, David Abrahams reported that Python extensions on Linux now crash if they are not compiled with exactly the same version of GCC as the Python they're loaded into. This is apparently due to the fact that on these systems Python is being linked with CXX when it should be linked with CC. The solution turned out to be to pass --without-cxx to configure; if it is not specified, configure runs a linking test that (improperly) determines that linking with CXX is necessary. When the --without-cxx flag is specified, configure does not perform this linking test, so Python is linked with CC. In the same discussion, Christoph Ludwig pointed out another problem in the above linking test. The current test compiles a single TU program using CXX and sees if linking it using CC fails. For GCC 3.x, it does, but because GCC 4.0 does a better job of eliminating unreachable code, with GCC 4.0 it does not. Thus make fails using GCC 4.0. Christoph showed that compiling a program with two TUs, one of which calls an 'extern "C"' function in the other, restores the original behavior. He provided the corresponding patch_ to configure.in. While Christoph's patch stops make from failing on Linux with ELF shared binaries and GCC 4.x, it did not address David Abrahams original concern -- that on Linux with ELF shared binaries and GCC 3.x or 4.x, configure should determine that Python can be compiled *without* CXX. Christoph promised to work on a more comprehensive patch to address this problem for Python 2.5. .. _patch: http://www.python.org/sf/1239112 Contributing threads: - `GCC version compatibility <http://mail.python.org/pipermail/python-dev/2005-July/054686.html>`__ - `Linux Python linking with G++? <http://mail.python.org/pipermail/python-dev/2005-July/054693.html>`__ - `[C++-sig] GCC version compatibility <http://mail.python.org/pipermail/python-dev/2005-July/054794.html>`__ [SJB] -------------------------------------------------------- Behavior of Sourceforge when replying to python-checkins -------------------------------------------------------- At the moment, replying to a message in the check-ins list defaults to directing the reply to python-dev. After this lead to some confusion, Guido questioned whether this was a good idea or not; the two main problems are that it is more difficult than necessary to send notes to the committer, and difficult to follow such threads (the past is in the check-in message, and future messages might be on python-dev or the check-ins list). Only one person replied to Guido's suggestion (agreeing) - nothing appears to have changed so far, so it seems that perhaps the status quo rules. Contributing thread: - `floatobject.c 2.136 <http://mail.python.org/pipermail/python-dev/2005-July/054617.html>`__ [TAM] ---------------------------------------- Removing else clauses from while and for ---------------------------------------- Thomas Lotze suggested that an 'eltry' keyword be introduced, to be the counterpart of 'elif' for try statements; this idea was quickly shot down by Guido (the use case is rare, using both "else" and "try" is fine, a loop solution often works well). As a result, however, Guido wondered whether else clauses on for/while were a good idea, even though he dislikes flag variables. He was joined by various people, some of whom did not know (or had forgotten) that the clauses even existed - some people wondered whether they made the language harder to learn. These people were outnumbered, though, but people who felt that these loop else clauses were an elegant part of the language and should definitely stay. Interestingly, Guido noted that he wonders whether "elif" was a mistake, and should have been "else if" (although there was no indication that he felt that this should be changed in Python 3000). Contributing thread: - `Chaining try statements: eltry? <http://mail.python.org/pipermail/python-dev/2005-July/054667.html>`__ [TAM] --------------------------------------------------------- Adding Syntactic Support for Instance Variable Assignment --------------------------------------------------------- Ralf W. Grosse-Kunstleve asked for syntactic support for the common idiom:: def __init__(self, x, y, z): self.x = x self.y = y self.z = z using the syntax:: def __init__(self, .x, .y, .z): pass People pointed out that with a properly-defined initialize() function you could use existing Python syntax and only need a single function call in __init__:: def __init__(self, x, y, z): initialize(self, locals()) The thread_ was moved to comp.lang.python before it had a chance to turn into a decorator-syntax-like discussion. ;) .. _thread: http://mail.python.org/pipermail/python-list/2005-July/288292.html Contributing thread: - `reducing self.x=x; self.y=y; self.z=z boilerplate code <http://mail.python.org/pipermail/python-dev/2005-July/054568.html>`__ [SJB] ------------------------------------- Changing Triple-quoted String Parsing ------------------------------------- Andrew Durdin suggested a change in the way that triple-quoted strings are parsed. Strings like:: myverylongvariablename = """\ This line is indented, But this line is not. Note the trailing newline: """ would have the initial indents on all lines but the first ignored when they were parsed. People seemed generally to dislike the proposal, for a number of reasons: - "It smells too much of DWIM, which is very unpythonic" -- Guido - it is backwards incompatible in a number of ways - textwrap.dedent covers pretty much all of the use cases Andrew Durdin said he would write the PEP anway so that at least if the idea was rejected, there would be some official documentation of the rejection. Contributing thread: - `Triple-quoted strings and indentation <http://mail.python.org/pipermail/python-dev/2005-July/054649.html>`__ [SJB] ----------------------- path module and Unicode ----------------------- Continuing last month's discussion on including the path module in the standard library, Neil Hodgson pointed out that path makes it easier to handle Unicode directory paths on Windows-based platforms; currently, this requires user code. Further replies pointed out similar Unicode handling problems in sys.argv and os.listdir, leading Guido to comment, "Face it. Unicode stinks (from the programmer's POV). But we'll have to live with it." Neil boiled this down to four high-level strategies for dealing with attributes that can Unicode: always returning Unicode, returning Unicode only when a value can't be represented in ASCII, returning Unicode only when a value can't be represented in the current code page, or creating "separate-but-equal" APIs (like sys.argvu and os.environu). Marc-Andre Lemburg and Guido both expressed strong preferences for the second option, with Marc-Andre formulating the rule as presented in this issue's QotF. Contributing threads: - `Adding the 'path' module (was Re: Some RFE for review) <http://mail.python.org/pipermail/python-dev/2005-July/054535.html>`__ - `Adding the 'path' module (was Re: Some RFE for review) <http://mail.python.org/pipermail/python-dev/2005-July/054796.html>`__ - `Adding the 'path' module (was Re: Some RFE for review) <http://mail.python.org/pipermail/python-dev/2005-July/054857.html>`__ [TDL] -------------------------------------- Improving decimal module documentation -------------------------------------- Facundo Batista noticed that documentation of the new-in-2.4 decimal module was fairly limited, particularly in terms of the rounding methods (although `PEP 327`_ covers them thoroughly). Raymond Hettinger volunteered to fix this up. .. _PEP 327: http://www.python.org/peps/pep-0327.html Contributing threads: - `Decimal rounding doc <http://mail.python.org/pipermail/python-dev/2005-July/054543.html>`__ - `Missing docs (was Decimal rounding doc) <http://mail.python.org/pipermail/python-dev/2005-July/054553.html>`__ [TAM] ---------------- getch() behavior ---------------- Darryl Dixon pointed out that the getpass() function in the getpass module does not accept extended characters on Windows, where the msvcrt module is used to capture one character at a time from stdin via the _getch() function defined in conio.h. Windows supports `capturing extended characters`_ via _getch, but it requires making a second call to getch() if one of the 'magic' returns is encountered in the first call (0x00 or 0xE0). Darryl asked whether a patch for the msvcrt module that added support for capturing extended characters would be considered. However, no support was received (although it was suggested that a patch submitted through sourceforge, possibly implemented via a new function, would be considered), as the thinness of the msvcrt wrapper is intentional, and it was not clear that this was a problem (i.e., that two calls could not be made). .. _capturing extended characters: http://support.microsoft.com/default.aspx?scid=kb;en-us;57888 Contributing threads: - `getch() in msvcrt does not accept extended characters. <http://mail.python.org/pipermail/python-dev/2005-June/054506.html>`__ - `getch() in msvcrt does not accept extended characters. <http://mail.python.org/pipermail/python-dev/2005-July/054539.html>`__ [TAM] ------------------- Threads and signals ------------------- Florent Pillet noticed that when using Python 2.3 on Max OS X, calling tmpfile() from a C extension had the side-effect of disabling Control-C keyboard interruption (SIGINT). Further digging revealed that on both Darwin and FreeBSD platforms, tmpfile() does play with the signal handling, but appears to change it back. Michael Hudson noted that Florent's code also involved threads, and that mixing threads and signal handling involved "enormously subtle" issues. Anthony Baxter also replied that Python 2.4 should be less subject to harmful effects from these bugs, but as a rule, mixing threads and signals is a recipe for "misery, despair, horror, and madness." Contributing threads: - `C bindings calling tmpfile() blocks interrupt signal <http://mail.python.org/pipermail/python-dev/2005-July/054690.html>`__ [TDL] -------- List API -------- Nicolas Fleury proposed adding copy() and clear() functions to lists, to be more consistent with dict and set. It was pointed out that the copy module (copy.copy()) can be used for generic copying, or a copy constructor and that clearing can be done with slicing (l[:] = []) or the del keyword (del l[:]). Advocates of the clear method argued that a clear method would be easy to find in documentation, and wouldn't require understanding slicing to use it, but none of the developers seemed swayed, so it seems unlikely that anything more will come of this at this time. Contributing threads: - `List copy and clear (was Re: Inconsistent API for sets.Set and build-in set) <http://mail.python.org/pipermail/python-dev/2005-June/054522.html>`__ - `List copy and clear (was Re: Inconsistent API for sets.Set and build-in set) <http://mail.python.org/pipermail/python-dev/2005-July/054527.html>`__ [TAM] ------------ Money Module ------------ Facundo Batista announced that the `Money module`_ is taking form quickly, a "pre-PEP", and unit tests have been written. Raymond Hettinger and Aahz noted that a "pre-PEP" is really a misnomer: PEPs describe enhancements to the Python core and standard library, while Money is still rather experimental and unlikely to see inclusion anytime soon. Facundo invited any interested parties to join the discussion in the pymoney-general list on SourceForge. .. _Money module: http://sourceforge.net/projects/pymoney Contributing threads: - `Money module <http://mail.python.org/pipermail/python-dev/2005-July/054558.html>`__ [TDL] ------------------------ Bug-reporting Checklists ------------------------ Brett Cannon posted a draft of a checklist to help users report bugs. Several minor improvements were suggested, but Raymond Hettinger expressed mild dislike for the idea, describing it as "administrivia" that might actually prevent people from filing bugs. Terry Reedy suggested, along with the checklists, some minor changes to the structure of the python.org site (to define bugs, help determine whether a bug has already been reported, etc.) would help even more. Contributing threads: - `checklist for filing a bug <http://mail.python.org/pipermail/python-dev/2005-July/054737.html>`__ [TDL] =============== Skipped Threads =============== - `how to create single exe dos file <http://mail.python.org/pipermail/python-dev/2005-July/054536.html>`__ - `cephes module missing <http://mail.python.org/pipermail/python-dev/2005-July/054537.html>`__ - `Inconsistent API for sets.Set and build-in set <http://mail.python.org/pipermail/python-dev/2005-July/054560.html>`__ - `python-dev Summary for 2005-06-16 through 2005-06-30 [draft] <http://mail.python.org/pipermail/python-dev/2005-July/054624.html>`__ - `using pyhon from the MSYS shell <http://mail.python.org/pipermail/python-dev/2005-July/054636.html>`__ - `Possible C API problem? <http://mail.python.org/pipermail/python-dev/2005-July/054638.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2005-July/054648.html>`__ - `Expanding max chunk size to 4GB. <http://mail.python.org/pipermail/python-dev/2005-July/054671.html>`__ - `Request to add developer <http://mail.python.org/pipermail/python-dev/2005-July/054674.html>`__ - `C bindings calling tmpfileblocks interrupt signal <http://mail.python.org/pipermail/python-dev/2005-July/054690.html>`__ - `Another SoC student for CVS access <http://mail.python.org/pipermail/python-dev/2005-July/054718.html>`__ - `__autoinit__ <http://mail.python.org/pipermail/python-dev/2005-July/054788.html>`__ - `SF patch #1214889 - file.encoding support <http://mail.python.org/pipermail/python-dev/2005-July/054870.html>`__ - `e-mail addresses <http://mail.python.org/pipermail/python-dev/2005-July/054874.html>`__ - `[Python-checkins] python/dist/src/Miscdevelopers.txt, 1.15, 1.16 <http://mail.python.org/pipermail/python-dev/2005-July/054876.html>`__ - `Is PEP 237 final -- Unifying Long Integers and Integers <http://mail.python.org/pipermail/python-dev/2005-July/054879.html>`__ - `Python on PyPI <http://mail.python.org/pipermail/python-dev/2005-July/054880.html>`__

2 1

installation of python on a Zaurus
by Chuck Robey July 26, 2005

July 26, 2005

I'm trying to get Python installed on a Zaurus, running OpenBSD. There are several problems with the basic install, some of which I've fixed, more I haven't. I need a particulare question solved here, so I'm going to ffer in recompense what I'ver learned so far: The configure script seems to know (from internal comments) that _XOPEN_SOURCES must be turned off, but it's not efectively turned off, and the configure script needs to ber edited, else you can't even get the basic build to even begin. I don't know enough abou tocnfigure to offer a correct fix, but this is true (I hand-edited the configure script to turn xopen_sources to "no". What I'm after is the reason why it keeps on telling me (during the build, not during configure) that it can't find my just installed tcl85 and tk85 libs. I have soft-linked them to a more common naming (libtcl.so.1.0 and libtk.so.1.0, which is the same index, just dropping the "85" from the naming, and doing the ldconfig'ing ok) but this doesn't seem to fix it. There is a configure-time thing about UCS-tcl, and I don't know what this is. It IS in configure, I can't even locate the source of the complaint about not finding the tcl libs, it's not in the top level directory anywhere. Appreciate the help.

2 2

zlib 1.2.3 is just out
by Scott David Daniels July 26, 2005

July 26, 2005

Note zlib 1.2.3 is just out -- the zlib compression/decompression http://www.zlib.net/ From the page: Version 1.2.3 eliminates potential security vulnerabilities in zlib 1.2.1 and 1.2.2, so all users of those versions should upgrade immediately. The following important fixes are provided in zlib 1.2.3 over 1.2.1 and 1.2.2: * Eliminate a potential security vulnerability when decoding invalid compressed data * Eliminate a potential security vulnerability when decoding specially crafted compressed data * Fix a bug when decompressing dynamic blocks with no distance codes * Fix crc check bug in gzread() after gzungetc() * Do not return an error when using gzread() on an empty file I'd guess this belongs in 2.5, with a possible retrofit for 2.4. --Scott David Daniels Scott.Daniels(a)Acm.Org

6 7

C api for built-in type set?
by Edward C. Jones July 25, 2005

July 25, 2005

Is there a C API for the built-in type set? if not, why not?

3 2