I just responded to a question on c.l.py a user had about feeding empty
strings to input(). While he didn't say why he called input(), I suspect he
thought the semantics were more like raw_input().
In these days of widespread Internet nastiness, shouldn't input() be
Skip Montanaro (skip(a)pobox.com - http://www.mojam.com/)
[ Background note for cc: to python-dev:
pyobjc.so builds under both python2.1.2 and python2.2.
It works under 2.1.2, but under 2.2, it gives a
'Failure linking new module' error. ]
Added a call to NSLinkEditError to get back more info from
the error (I'll submit this as a patch to SF after I clean
it up a bit.):
>>> import pyobjc
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: dyld: /usr/local/src/Python-2.2/python.exe Undefined symbols:
Failure linking new module
grepping for this in 2.1.2 finds nothing.
In 2.2, there seems to be one occurance:
grep PyObject_DelItemString */*.[ch]
Include/abstract.h:#define PyMapping_DelItemString(O,K) PyObject_DelItemString((O),(K))
Searching for PyMapping_DelItemString, it looks like this changed from
PyDict_DelItemString() in 2.1.2 to PyObject_DelItemString() in 2.2:
dm7g% grep PyMapping_DelItemString Python-2.*/*/*.[ch]
Python-2.1.2/Include/abstract.h: int PyMapping_DelItemString(PyObject *o, char *key);
Python-2.1.2/Include/abstract.h:#define PyMapping_DelItemString(O,K) PyDict_DelItemString((O),(K))
Python-2.2/Include/abstract.h: int PyMapping_DelItemString(PyObject *o, char *key);
Python-2.2/Include/abstract.h:#define PyMapping_DelItemString(O,K) PyObject_DelItemString((O),(K))
Is this change of name an inadvertant bug, or is it something that
was intentionally changed, but incompletely?
Now that 2.2 is history (well, kind of ;-), would it be the time to
think about this again?
----- Forwarded message from Gustavo Niemeyer <niemeyer(a)conectiva.com> -----
Date: Wed, 14 Nov 2001 20:07:03 -0200
From: Gustavo Niemeyer <niemeyer(a)conectiva.com>
Subject: Re: [Python-Dev] Python's footprint
> > It means that about 10% of python's executable is documentation.
> Anyways, that sounds like a useful idea. It would probably be a big
> patch that touches lots of files, so it's unlikely to get into Python
> 2.2. You might consider whipping up a patch now to get it under
> consideration early in 2.3's life-cycle.
Ok. The patch is ready (attached). It's very simple. Just introducing
two new macros: Py_DOCSTR() to be used in usual doc strings, and
WITH_DOC_STRINGS, for more complex ones (sys module's doc string
comes into my mind).
I'd just like to know the moment when it is going to be applied, so I
can change every documentation string accordingly and submit the patch.
I could do this right now, for sure. But if it's going to be applied
just for 2.3, the patch will certainly be broken at that time.
[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
--- Python-2.2.orig/pyconfig.h.in Wed Nov 14 17:54:31 2001
+++ Python-2.2/pyconfig.h.in Wed Nov 14 19:08:08 2001
@@ -765,3 +765,13 @@
#define STRICT_SYSV_CURSES /* Don't use ncurses extensions */
+/* Define if you want to have inline documentation. */
+/* Define macro for inline documentation. */
+#define Py_DOCSTR(x) x
+#define Py_DOCSTR(x) ""
--- Python-2.2.orig/configure.in Wed Nov 14 17:54:31 2001
+++ Python-2.2/configure.in Wed Nov 14 19:20:07 2001
@@ -1305,6 +1305,20 @@
+# Check for --with-doc-strings
+[ --with(out)-doc-strings disable/enable documentation strings])
+if test -z "$with_doc_strings"
+if test "$with_doc_strings" != "no"
# Check for Python-specific malloc support
----- End forwarded message -----
[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
The end of an era has come:
Stackless Python, in the form provided upto Python 2.0, is DEAD.
I am abandoning the whole implementation.
A new era has begun:
A completely new implementation is in development for
Python 2.2 and up which gives you the following features:
- There are no restrictions any longer for uthread/coroutine
switching. Switching is possible at *any* time, in *any*
- There are no significant changes to the Python core any
longer. The new patches are of minimum size, and they
will probably survive unchanged until Python 3.0 .
- Maintenance work for Stackless Python is reduced to the
bare minimum. There is no longer a need to incorporate
Stackless into the standard, since there is no work to
- Stackless breaks its major axiom now. It is no longer
platform independent, since it *does* modify the C stack.
I will support all Intel platforms by myself. For other
platforms, I'm asking for volunteers.
* The basic elements of Stackless are now switchable chains
of frames. We have to define an interface that turns these
chains into microthreads and coroutines.
Everybody is invited to come to the Stackless mailing
list and discuss the layout of this new design.
Especially we need to decide about (*).
see you there - chris
Christian Tismer :^) <mailto:email@example.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/
> Yes, but what if the program containing calls to input() get shipped to
> someone else's computer? It just seems to me that a) input is almost never
> what you want to call and that b) it would seem to a naive programmer to be
> the correct way to ask the user for a line of input.
Since most arbitrary lines of input generate syntax errors,
wouldn't the naive programmer quickly figure out that input
isn't the "read a line" function? (Unless you're trying to
input numbers, I suppose.)
Has anyone tried the evaluation version of the Intel C/C++ compiler
for Linux 32-bit platforms? They distributed a CD in the most recent
version of Linux Magazine, and it appears to be available for download
I had trouble getting it going; the evaluation license file they sent
me didn't work out of the box with the license manager that got
installed. If anyone has gotten it to work, please send instructions
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation
In preparing a set of patches intended to bring the OS/2 EMX port into
CVS, I have a dilemma as to how best to integrate some changes to standard
As background to this request I note that EMX and Cygwin have similar
philosophies and attributes, being Posix/Unixish runtime environments on
OSes with PC-DOS ancestry. Both rely on the GNU toolchain for software
As a result of feedback on the previous set of patches, I am pruning
cosmetic changes and attempting to minimise the footprint of the necessary
The particular changes I am looking for guidance on (or BDFL
pronouncement on, as the case may be) involve os.py and the functionality
The approach used in the port as released in binary form was to create a
module called os2path.py (probably should really be called os2emxpath.py),
which replicates the functionality of ntpath.py with OS2/EMX specific
Most of the changes have to do with using different path separator
characters, with a few other changes reflecting slightly different
behavour under EMX. EMX promotes the use of '/' as the path separator
rather than '\', though it works with the latter. I don't know if Cygwin
promotes the same convention.
If I were to merge os2path.py into ntpath.py (which I incline towards
instinctively) I believe that using references to os.sep and os.altsep
rather than explicit '\\' and '/' strings would significantly reduce the
extent of conditionalisation required, but in the process introduce
significant source changes into ntpath.py (although the logical changes
would be much less significant).
If rationalising the use of separator characters (by moving away from
hard-coded strings) in ntpath.py is unattractive, then I think I'd prefer
to keep os2path.py (renamed to os2emxpath.py) as is, rather than revert
to the DOS standard path separators.
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac(a)bullseye.apana.org.au | Snail: PO Box 370
andymac(a)pcug.org.au | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
I'm writing thread routines for the Plan 9 port of Python.
Is it correct that:
PyThread_acquire_lock returns 1 on success, 0 on failure.
PyThread_down_sema returns 0 on success, -1 on failure.
It appears that way, but the inconsistency bothers me.
I've released the final version of Python 2.1.2 - a bugfix release for
Python 2.1. I recommend everyone who is using Python 2.1 or
2.1.1 to upgrade to 2.1.2 -- this release fixes a few crashes.
Read about it and download it here:
My special thanks go out to Anthony Baxter, the relentless 2.1.2
releasemeister (and for the use of his timezone so I can call this a
January 16 release without having to stay up until after midnight :-).
--Guido van Rossum (home page: http://www.python.org/~guido/)