I see that, as expected, windows python 2.4 was built with MSVC 7.1
rather then msvc 6.0.
It seems that I can build extensions with msvc 6.0 that work with the
python 2.4 windows
Is this safe?
I recall warning a while ago about mixing msvc 6.0 and msvc 7.1 runtime
DLL's. Is this
an issue with python 2.4?
I'm also surprised that the python 2.4 source kit only mentions MSVC
6.0 and not the
compiler that you actually built python 2.4 with.
On Dec 28, 2004, at 4:30 PM, jackjansen(a)users.sourceforge.net wrote:
> Update of /cvsroot/python/python/dist/src/Mac/OSX
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9229
> Modified Files:
> Log Message:
> Just passing -undefined dynamic_lookup isn't enough: we also need to
> the MACOSX_DEPLOYMENT_TARGET environment variable to 10.3 when calling
> loader. And we do this with "env" because distutils apparently doesn't
> understand environment variable assignments before command names.
This is the wrong fix. Distutils is dumber than you think. This patch
just breaks C++ compilation in a different way. The correct solution
is a patch to distutils of some kind.
if target_lang == "c++" and self.compiler_cxx:
linker = self.compiler_cxx
self.spawn(linker + ld_args)
"linker" is the variable expanded LDSHARED (or whatever comes out of
On 27 dec 2004, at 19:27, Chris Barker wrote:
> Robin has added versioning to the latest wxPython, and I. for one am
> ecstatic. It works great for me. I am generally using 2.5.3, but have
> 2.4.2 installed, and a number of my apps depend on it (on Linux
> anyway, it's pretty useless on OS-X)
> It's great to be able to put:
> import wxversion
> At the top of my apps, and know that they'll use the version of
> wxPython I tested against.
Would it be an idea to submit a PEP for extending the 'import' keyword?
I can imagine it to be like:
import spam version 1
import foo version 2, 4
import bar version 7, 1, 6
with version numbers consisting of some fixed maximum of parts and the
version number parts not given might be wildcards.
We could then have a per module version system like:
... [version 1.0.1 stuff in here]
... [version 1.5.7 stuff in here]
there should be nothing else in the module directory, except for a
mechanism to further support versioning.
Default behaviour of 'import spam' would be to select the most recent
version. We might want to override that by pointing to some other
version. This might be achieved using a symbolic link/alias/shortcut to
the directory of that version (spam/current -> spam/1.0.1).
More like the directory/module method would be to allow for a
__version__.py file in 'spam'. Content of this file is to be
determined, but I think it should at least something like __current__
or __version__ to act as the pointer to the current version.
Hi Python people,
The next sprint for PyPy, the Python-in-Python interpreter, will take
place in Leysin, in the lower mountains of Switzerland,
22nd - 29th January 2005 (travel days: 22nd and 29-30th)
The technical goals will be two-fold: we want to continue the hard work
started at the previous Vilnius sprint (a first generated C version of our
interpreter); but the upcoming sprint will also be a "learning PyPy"
sprint, covering all aspects of PyPy that are easier to start with.
Some examples are described below. For more information about PyPy, see
The "learning PyPy" focus comes from the fact that it will be our first
sprint as a European Union sponsored group, and not all members of this
EU/PyPy project are already familiar with PyPy. This is a good occasion
for newcomers that want to look at PyPy more closely too, in a "fun and
somewhat mind-altering" sprint event. Note that as part of our funding we
want to be able to support some of the travel and lodging costs for a
number of outside people as well, but although the corresponding money is
in the budgets, not all administrative issues have been solved yet. We
don't know yet if we will be able to do so for the January sprint.
However, if you would like to come to the sprint but can't afford
travel and accomodation costs then please contact us. Even if the
administrative issues have not been sorted out, we may be able to
help with private money. Just contact us or me personally for this
The place where the sprint will take place is located in the pre-Alps of
the french-speaking (west) region of Switzerland. Leysin is a village at
an altitude of 1200 to 1400m. It is a skiing station, and also the place
where I (Armin) lived for 20 years. There are 2000 people in summer and
10000 in winter :-) but the sprint will be just before the most crowded
periods of February. Of course one full day will be dedicated to winter
Both the sprint venue and the logding will be in a very spacious pair of
chalets built specifically for bed&breakfast: http://www.ermina.ch/. The
place has a baseline ADSL Internet connexion (600Kb); we need to arrange
between ourselves to bring a wireless hub. You can of course arrange your
own lodging anywhere (you cannot be more than a 15 minutes walk away from
the sprint venue), but I definitely recommend to lodge there too -- you
won't find better sights anywhere else (though you probably won't get much
worse ones easily, either :-)
Please subscribe at
and mention if you would like to participate in the group reservation, and
which size of room you would prefer (2 to 6 beds available). If you wish, you
can extend your stay for some days after the 29th of January -- please mention
it if you want to book with the group (but you cannot arrive there earier
than the 22nd: fully booked).
If you have any question don't hesitate to contact
pypy-sprint(a)codespeak.net or one of us personally.
Here are some goals that are quite reachable without in-depth prior
knowledge of PyPy:
* systematic testing: the interpreter and type implementations work
generally well, but there are quite some areas that need refactoring
and refinement. A good approach is to run as many of CPython's tests
as possible and fix stuff accordingly. This is a good way to learn
random parts of PyPy until you know them all!
* extension modules and extension types: some can be just rewritten as a
plain Python equivalent, but others need to be more integrated into
* the bytecode compiler: we don't have any compiler integrated with PyPy
so far, but there exists a complete set of Python code out there
(tokenizer, parser, st->ast, ast->bytecode) that could be used. We
could also discuss ideas like syntax extensions generating new
* tracing and other wrappers: e.g. how to write a fully debugging Object
Space that records the history of all changes to objects, etc.
* more bits and pieces: small things missing from our interpreter to be fully
compliant. Tracing/profiling hooks come to mind; more small things
are listed in http://codespeak.net/svn/pypy/trunk/src/pypy/TODO .
In addition to the above examples, there are a number of more involved tasks
that nevertheless don't require a complete grasp of PyPy -- whose parts are
relatively independent from each other. The "hard" work currently going on in
PyPy is on the translation part, which is needed to make PyPy run faster
and/or in other environments. This work is however mostly independent. For
people that prefer to focus on cross-language stuff rather than Python
internals we can discuss about tasks like writing the basics of an interpreter
for another language -- for example, it would be great to have a decent
Python-like or not. In parallel, there is always pending work to allow the
code generator to target other languages and platforms (currently there is C,
Lisp, Pyrex and Java) or generate code differently (Stackless-style,
I'm about to travel to a place where I don't expect to have internet
access for over a week, so this is my last message in 2004. I'll have
more time next year for Python that I had this year, so I'm looking
forward to working again with this great community. I wish everyone
happy celebrations of the dark season, and I hope to see many of you
at the upcoming PyCon conference. Cheers!
--Guido van Rossum (home page: http://www.python.org/~guido/)
I just spent 10 minutes hunting through the Python website for this link:
I knew it was there somewhere, I just couldn't find the darn thing.
It turns out the major mistake I made was to start from "docs.python.org"
instead of "www.python.org/doc".
Would it be possible for the "New-style classes" link to be added to the sidebar
menu for the individual version's documentation pages? Or else given its own
link on the Topic Guides page?
Nick Coghlan | ncoghlan(a)email.com | Brisbane, Australia
Dear Python User:
Following my last message, I am pleased to be able to
announce that you can register for PyCon DC 2005 on the
starting at 1700 EST today (December 23). Thanks to
George Belotsky of Open Light Software for assistance
in preparing the credit card processing software.
As always, further information about PyCon is available
in the usual places:
I look forward to meeting you at PyCON DC 2005. In the
meantime please let me offer my best wishes for a
happy and peaceful holiday season.
Chairman, PyCON DC 2005
PyCon DC 2005: The third Python Community Conference
The scoop on Python implementations and applications
per previous discussion,
I'd like to push a trivial little patch to sgmllib (#1087808) on you
gents, in exchange for my reviews & effort etc. on 10 other patches.
Without further ado:
1055159 -- a docstring+docs update to CGIHTTPServer describing already-
existing behavior. Recommend apply.
1037974 -- fix HTTP digest auth for broken servers, e.g. LiveJournal.
Trivial code fix, should break nothing. Recommend apply +
1028908 -- JJ Lee's updates to urllib2. Passes regr tests, by an
original author of much of the code (I think). Recommend apply.
901480 -- patch to urllib2.parse_http_list (bug 735248). Works.
Updated patch. Recommend apply + backport.
827559 -- SimpleHTTPServer redirects to 'dir/' when asked for 'dir'.
This behavior mimics common behavior online and fixes a problem
with relative URLs when clicking on files within 'dir'.
810023 -- fixes off-by-one bug in urllib reporthook. regr tests & all.
Good stuff. Recommend apply + backport.
893642 -- adds allow_none option to SimpleXMLRPCServer & associated
classes. Doesn't change default behavior. Recommend apply.
755670 -- modify HTMLParser to accept clearly broken HTML.
Slightly more complicated:
1067760 -- float-->long conversion on fileobj.seek calls, rather than
float-->int. Permits larger floats (2.0**62) to match large
int (2**62) arguments. rhettinger marked as "won't fix" in
the original bug report; this seems like a clean solution,
tho. Recommend apply.
755660 -- should HTMLParser fail on all bad input, or do best effort?
I'd recommend more sweeping changes where must-fail situations
are distinguished from fails-by-default situations.
Alternatively take a stand and say "nein!" once and for all.
(See my comment for more information.)
For no particularly good reason, all of these were tested against
the current CVS HEAD rather than 2.4. All of them should be trivial
to backport, although I think only a few are real problems worthy
of the effort.
I'm kind of curious to see how this goes, I must admit ;). Please CC
me on replies so I can listen in...
One comment to Martin: it clearly isn't worth the effort of reviewing 10
patches to push a patch the size of my sgmllib patch. On the other
hand, it's nice to have a guarantee & it's an educational experience,
that's for sure.
A 5:1 ratio might be more reasonable, since that in practice will
mean 1 serious patch, 2 or 3 updates, and 1 drop-dead easy patch.
Python runs on Nokia cell phones (the high-end ones, anyway) and has
support from Nokia!
Pretty cool all around.
--Guido van Rossum (home page: http://www.python.org/~guido/)
---------- Forwarded message ----------
From: Michele.Marchetti(a)nokia.com <Michele.Marchetti(a)nokia.com>
Date: Wed, 22 Dec 2004 11:59:55 +0200
Subject: python for Series 60 released
like promised during EuroPython I let you know about the fact that
Python for Symbian Series 60 is released.
You may find it in www.forum.nokia.com by choosing under "resources"
"Tools and SDK's" main page.
Have a nice Christmas time.