In the course of getting distutils to behave on the Mac I came across
.pth files for the first time (all packages I ever tried until now
used the __init__.py method of advertising themselves) and it turns
out they don't work on the Mac.
There's some funny code in site.py that triggers on "os.sep ==
'/'". I've added an "elif os.sep == ':'" for the mac-specific location
where site-python is (sys.prefix + :lib:site-python), but checking for
os.sep in stead of simply checking that sys.platform==posix makes me
wonder whether something infinitely more deep than my understanding
allows me to grasp is going on.
Can someone enlighten me? Is my fix okay and should I check it in?
Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++
In socketmodule, socket.error is currently just a plain old error
(derived only from Exception). Looks to me like it should be an IOError.
Do you agree?
line 2379 of socketmodule.c:
�������d = PyModule_GetDict(m);
�������PySocket_Error = PyErr_NewException("socket.error", NULL, NULL);
�������if (PySocket_Error == NULL)
...just change that first NULL to PyExc_IOError.
"All models are wrong; some models are useful."
-- George Box
sorry to bother you again with this, but the current state
of Python's community elements is in such a bad shape, that
I'm getting more and more frustrated...
First, starship is taken off the net due to a mailing problem.
After a few days starship resurfaces: but apparently using
some really old backup which didn't even contain all files
-- at least the .ssh dirs seem to be lost causing RSA logins
using SSH to fail (don't know about normal logins -- my old
passwords don't work anymore either, but that could have been
caused by the harddisk crash earlier this year).
As consequence, I moved all my Python Pages to a new site
which should provide more stability. Next, I tried to get this
message across to the comp.lang.python.* crowd: I posted
messages to the python.org mailing lists which should have
been gatewayed to the newsgroups -- nothing happened. The
messages seem to be stuck somewhere half-way across the
The result: even though I tried to do some good, by moving my
site, noone will notice and I still get complaints about
my extensions not working with 2.0 -- the announcement about
the new versions *did* make it to comp.lang.python and the
announcement list: but it still had the starship URL on it,
so now people find the announcement and there's no way
to point them to the new URL (I can't login to starship to
post a notice there...).
Help someone, please.
Python Pages: http://www.lemburg.com/python/
imputil, which is now an official part of
python, changes the semantics of sys.path
as soon as importers are installed.
On the other hand, a quick and dirty search
finds at least these files in the standard library
where it is assumed that sys.path is a list of strings:
linecache.py, profile.py, pdb.py, pyclbr.py
Should imputil be fixed to install the ImportManager
in a different way (not installing the importers
into sys.path), or should the library be fixed?
It sounds like people are happy with Python. ;) Just thought I'd
pass this bit of praise araound, since it seems to apply to everyone's
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Digital Creations
I'm forwarding this message about PEP-228, but I haven't fully
understood it. In any case, since PEP-228 is apparently not
a 2.1 candidate, I've told Michael that his remarks will be considered,
but they are not relevant yet.
------- Forwarded Message
From: Michael McLay <mclay(a)nist.gov>
Date: Fri, 17 Nov 2000 04:20:45 -0500 (EST)
I've dropped off the Python mailing lists for the last couple years
because the volume is too high and I don't have time to contribute to
the discussion. I do read the summaries and PEP:228 was mentioned in
reference to the 2.1 release. I'd like to see this problem solve in
the 2.1 release and I have a few thoughts on the matter that may be of
use to this task. Is there a mailing list specific to PEP:228 or
would I have to join python-dev to participate in the discussion?
Please feel free to forward my message to the python-dev list or use
my comments in PEP:228.
Python's use in the XML community is growing and broad-based XML
support in Python may be key to widespread adoption of Python. There
is some support for XML Schema, the XML Schema Validation software is
written in Python, but there is no direct support in the core Python
XML library. One problem area for an XML Schema implementation is
related to the numerical types in Python. The ability to implement
XML Schema types could be improved if the requirements are considered
when creating the PEP:228 implementation.
And from the Python language perspective a review of the numerical
model used in XML Schema may be useful to the discussion of the
revised numerical model for Python. The authors of the XML Schema
specification put a good deal of effort into defining a modern,
portable numerical model and I think it might be a good fit with the
Python object model. I might also be possible that the XML Schema
type and entity definition mechanism would be helpful in the
discussion of defining type interfaces for Python.
A table of simple types built into XML Schema are defined in:
These are defined more fully in "XML Schema Part 2: DataTypes" at:
This includes a discussion of the difference between built-inprimitive
and built-inderived datatypes.
The derived types are defined in the XML Schema at:
In this document, for instance, an integer is derived from a decimal
type in XML Schema.
<scale value="0" fixed="true"/>
The use of XML Schema in conjunction with Python would be very helpful
to a soon to be large domain of applications. I am working with a
group that is currently defining 20 standards using XML Schema and
this is probably just the tip of the iceburg. I need to be able to
define constrained numerical types as defined in XML Schma. In Python
this might look like:
size = ConstrainedDecimal(initial=2, minInclusive=2,
for i in range(3000-2):
size += 1
The ConstrainedDecimal would define a restriction range on the value
------- End of Forwarded Message
Moshe Zadka <sig(a)zadka.site.co.il>
This is a signature anti-virus.
Please stop the spread of signature viruses!
(I would cc this to the Stackless list as well, except that starship
mail is still down it seems. I *am* posting to the python-coro list,
which seems to be appropriate here. Will Ware, are you listening?)
Inspired by Gordon McMillan's Stackless tutorial
(http://www.mcmillan-inc.com/stackless.html), I've been thinking more
about a coroutine API for Python.
I proposed one before (see the thread "uthread strawman" in
python-dev). I've been thinking a bit more and am now revising my
proposal a bit.
I'll first give an example. Tim Peters gave a standard example to
return the fringe of a list (checked in as Demo/threads/fcmp.py).
Using my proposed API this example could be rewritten a bit
cleaner, as follows:
from coro import coroutine, suspend, EarlyExit # Provisional module name
for x in L:
if type(x) is type(L):
c = coroutine(f, L)
x = [0, 1, [2, ], [4,5], [[]]]
printinorder(x) # prints "0 1 2 3 4 5 6"
This is about as simple as it gets. It supports both generators (like
the example here) and coroutines (like Tim's Demo/threads/squasher.py
Besides the APIs shown here (coroutine(), suspend(), and EarlyExit) I
propose a function current() which returns the current coroutine
object. There should also be a way to kill a coroutine (or at least
to send an exception). When a coroutine falls through at its end,
*some* other coroutine needs to be resumed.
I believe this can be implemented with a much simplified stackless
approach, that doesn't cater towards continuations (but still borrows
a lot of wisdom from Christian's Stackless). It can also be
implemented using threads, which should give some hope for getting the
same API supported in JPython, making it more attractive. I am hoping
to create an implementation on top of Stackless, just to experiment
with the idiom.
I'm much less clear about microthreads (uthreads). Last time, I
thought this was a fancy name for coroutines. It isn't! Microthreads
are "almost real" threads, with round-robin scheduling. What makes
them attractive to some is the fact that they don't use operating
system resources: there's no OS-level stack or kernel process table
entry associated with them. This also accounts for their biggest
weakness: when a microthread is suspended for I/O, *all* microthreads
are suspended. In limited contexts, such as a network server, this
can be solved by an approach similar to that in Gordon's
SelectDispatcher. (It would be a titanic effort to do this for every
potentially blocking I/O operation, and it probably wouldn't work well
with C extensions.)
I'm not sure what applications require the round-robin scheduling
property of uthreads -- certainly Gordon's application would seem to
be doing just fine without it (I'm not sure if it is being scheduled
round-robin or not).
Proper round-robin scheduling for uthreads requires explicit switching
code in the Python interpreter. Stackless provides this, at the same
place where in regular Python the global interpreter lock is released
and re-acquired to give other threads a chance to run. Is this
--Guido van Rossum (home page: http://www.python.org/~guido/)
I hurried to get notifications of outstanding patches and bugs last
night and botched both of them. Sorry about that. If you can a
message about patches, you can disregard it entirely. It was made from
an old snapshot of the SF database. The bug mail contains current
bugs, but the formatting of the mail headers was off. I've fixed that
for the future.
Title: Using Distutils to Build Python
Version: $Revision: $
Author: akuchlin(a)mems-exchange.org (A.M. Kuchling)
The Modules/Setup mechanism has some flaws:
* People have to remember to uncomment bits of Modules/Setup in
order to get all the possible modules.
* Moving Setup to a new version of Python is tedious; new modules
have been added, so you can't just copy the older
version, but have to reconcile the two versions.
* Users have to figure out where the needed libraries, such as
zlib, are installed.
Use the Distutils to build the modules that come with Python.
The changes can be broken up into several pieces:
1. The Distutils needs some Python modules to be able to build
modules. Currently I believe the minimal list is posix, _sre,
These modules will have to be built before the Distutils can be
used, so they'll simply be hardwired into Modules/Makefile and
be automatically built.
2. A top-level setup.py script will be written that checks the
libraries installed on the system and compiles
as many modules as possible.
3. Modules/Setup will be kept and settings in it will override
setup.py's usual behaviour, so you can disable a module known
to be buggy, or specify particular compilation or linker flags.
However, in the common case where setup.py works correctly,
everything in Setup will remain commented out. The other
Setup.* become unnecessary, since nothing will be generating
Do we need to make it possible to disable the 3 hard-wired modules
without manually hacking the Makefiles? If yes, perhaps a
configure switch is sufficient.
The Distutils always compile modules as shared libraries. How do
we support compiling them statically into the resulting Python
makesetup and the other contents of $(LIBPL)/config need to be
preserved for compatibility with existing modules; for how many
versions do we need to keep them around?
This document has been placed in the public domain.
I'd like to add a Demo/curses directory to the CVS tree. If anyone
has reasonably small programs that use the curses module, please let
Right now I have two programs: a Life game that I wrote, and Alexei
Gilchrist's cfm (http://cfm.sourceforge.net/), which is a little file
manager. I also want to write scripts to demonstrate reading the
mouse, and writing a threaded curses program.