On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.3.5 (release candidate 1).
Python 2.3.5 is a bug-fix release. See the release notes at the website
(also available as Misc/NEWS in the source distribution) for details of
the bugs squished in this release.
Assuming no major problems crop up, a final release of Python 2.3.5 will
follow in about a week's time.
Python 2.3.5 is the last release in the Python 2.3 series, and is being
released for those people who still need to use Python 2.3. Python 2.4
is a newer release, and should be preferred if possible. From here,
bugfix releases are switching to the Python 2.4 branch - a 2.4.1 will
follow 2.3.5 final.
For more information on Python 2.3.5, including download links for
various platforms, release notes, and known issues, please see:
http://www.python.org/2.3.5
Highlights of this new release include:
- Bug fixes. According to the release notes, more than 50 bugs
have been fixed, including a couple of bugs that could cause
Python to crash.
Highlights of the previous major Python release (2.3) are available
from the Python 2.3 page, at
http://www.python.org/2.3/highlights.html
Enjoy the new release,
Anthony
Anthony Baxter
anthony(a)python.org
Python Release Manager
(on behalf of the entire python-dev team)
> It was also agreed that deleting deprecated modules was not needed; it breaks
> code and disk space is cheap.
> It seems that no longer listing documentation and adding a deprecation warning
> is what is needed to properly deprecate a module. By no longer listing
> documentation new programmers will not use the code since they won't know
> about it.[*] And adding the warning will let old users know that they should be
> using something else.
[* Unless they try to maintain old code. Hopefully, they know to find the
documentation at python.org.]
Would it make sense to add an attic (or even "deprecated") directory to the end
of sys.path, and move old modules there? This would make the search for
non-deprecated modules a bit faster, and would make it easier to
verify that new
code isn't depending (perhaps indirectly) on any deprecated features.
New programmers may just browse the list of files for names that look right.
They're more likely to take the first (possibly false) hit if the list
is long.
I'm not the only one who ended up using markupbase for that reason.
Also note that some shouldn't-be-used modules don't (yet?) raise a deprecation
warning. For instance, I'm pretty sure regex_syntax and and reconvert are both
fairly useless without deprecated regex, but they aren't deprecated on
their own --
so they show up as tempting choices in a list of library files.
(Though reconvert
does something other than I expected, based on the name.) I understand not
bothering to repeat the deprecation for someone who is using them correctly,
but it would be nice to move them to an attic.
Bastion and rexec should probably also raise Deprecation errors, if that becomes
the right way to mark them deprecated. (They import fine; they just
don't work --
which could be interpreted as merely an "XXX not done yet" comment.)
-jJ
I didn't see any replies to the last post, so I'll ask again with a
better subject line - as I said last time, as far as I'm aware, I'm
not aware of anyone having done a fix for the issue Tim identified
( http://www.python.org/sf/1069160 )
So, my question is: Is this important enough to delay a 2.4 final for?
My plan is currently to release it _this_ _Tuesday_, so I really need
an answer soon...
I've attached Tim's original message at the end here. At the moment,
I'm inclined to say "if it's not fixed, it won't kill us". But that's
admittedly my own biases - threading bugs annoy me <wink>
I'm happy to defer to more knowlegable types, though - is this so
bad that it merits delaying the release? I can't make time to look
at it before then - I'm still writing slides for a couple of talks at OSDC.
Anthony
From: Tim Peters <tim.peters(a)gmail.com>
To: Python Dev <python-dev(a)python.org>
Date: 2004-11-19 13:08
This one is a puzzler. See
http://www.python.org/sf/1069160
for details. The short course is that the PyThreadState_SetAsyncExc()
implementation fell into a common trap, and can cause segfaults under
rare conditions (like every other Python thread segfault bug we've
ever had).
This is easily repaired (although I've got no interest in doing the
coding, or even in contriving a test case -- this was an obvious "by
eyeball" bug).
The puzzle is how to treat this wrt 2.4. Since it's a critical bug, I
suppose it "should" force another release candidate. OTOH, this is a
C-only API (there's no exposure from Python) that's never used in the
core. We could add code to make it segfault every time <wink>, and
nothing in the distribution would notice.
OTOH, if we broke its intended behavior while fixing the bug, we'd
never know that either. "Never used in the core" means never -- the
function isn't tested.
On the third hand, it's a simple function with an obvious segfault
mode that has an obvious fix.
I'll leave it to the release manager <wink>.
Dear python-dev:
The current (as of even date) summary of my recent contributions to
Python -dev appears to be spam about PyCon.
Not being one to break habits, even not those of a lifetime sometimes, I
spam you yet again to show you what a beautiful summary ActiveState have
provided (I don't know whether this URL is cacheable or not):
<http://aspn.activestate.com/ASPN/Mail/Browse/ByAuthor/python-dev?author=c...>
If I remember Trent Lott (?) described at an IPC the SQL Server database
that drives this system, and it was a great example of open source
technology driving a proprietary (but I expect (?) relatively portable)
repository.
Since I have your attention (and if I haven't then it really doesn't
matter what I write hereafter, goodbye ...) I will also point out that
the current top hit on Google for
"Microsoft to Provide PyCon Opening Keynote"
is
[Python-Dev] Microsoft to Provide PyCon Opening Keynote
by Steve Holden (you can repeat the search to see whether this assertion
is true as you read this mail, and read the opening keynote announcement
[I hope...]).
Space at PyCon is again enlarged, but it certainly isn't infinite. I'd
love to see it filled in my third and last year as chair. The program
committee have worked incredibly hard to make sure we all have to choose
between far more technical content than a single individual can possibly
take in on their own. They [disclaimer: I was program chair, but this
should be kudos for the committee membership - without whom this
conference would have failed in many dimensions] they have succeeded so
well we all, I hope, have to agonize between two sumptuous but
equidistant technical bales of hay.
Only by providing such rich choice can we ensure that an even broader
community forms around Python, with free interchange between the
technical communities of the proprietary and open source worlds, and
equitable participation in the benefit.
Sorry I haven't made many CVS contributions lately. We really should be
showcasing more Python technologies via www.python.org.
targeted-marketing-to-talented-professionals-ly y'rs - steve
--
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
Holden Web LLC +1 703 861 4237 +1 800 494 3119
[Guido van Rossum]
#- > As a trivial example, here's how to skip the head of a
#- zero-numbered list:
#- >
#- > for i, item in enumerate("ABCDEF")[1:]:
#- > print i, item
#- >
#- > Is this idea a non-starter, or should I spend my holiday
#- on Wednesday finishing
#- > it off and writing the documentation and tests for it?
#-
#- Since we already have the islice iterator, what's the point? It seems
#- to me that introducing this notation would mostly lead to confuse
#- users, since in most other places a slice produces an independent
#- *copy* of the data.
I think that breaking the common idiom...
for e in something[:]:
something.remove(e)
is a no-no...
. Facundo
Bitácora De Vuelo: http://www.taniquetil.com.ar/plog
PyAr - Python Argentina: http://pyar.decode.com.ar/
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
ADVERTENCIA.
La información contenida en este mensaje y cualquier archivo anexo al mismo,
son para uso exclusivo del destinatario y pueden contener información
confidencial o propietaria, cuya divulgación es sancionada por la ley.
Si Ud. No es uno de los destinatarios consignados o la persona responsable
de hacer llegar este mensaje a los destinatarios consignados, no está
autorizado a divulgar, copiar, distribuir o retener información (o parte de
ella) contenida en este mensaje. Por favor notifíquenos respondiendo al
remitente, borre el mensaje original y borre las copias (impresas o grabadas
en cualquier medio magnético) que pueda haber realizado del mismo.
Todas las opiniones contenidas en este mail son propias del autor del
mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones
Personales S.A. o alguna empresa asociada.
Los mensajes electrónicos pueden ser alterados, motivo por el cual
Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación
cualquiera sea el resultante de este mensaje.
Muchas Gracias.
As those of you playing along at home with python-checkins would know, we're
going to be cutting a 2.3.5c1 shortly (in about 12 hours time).
Can people not in the set of the normal release team (you know the drill)
please hold off on checkins to the branch from about 0000 UTC, 26th January
(in about 12 hours time). After than, we'll have a one-week delay from release
candidate until the final 2.3.5 - until then, please be ultra-conservative
with checkins to the 2.3 branch (unless you're also volunteering to cut an
emergency 2.3.6 <wink>).
Assuming nothing horrible goes wrong, this will be the final release of Python
2.3.
The next bugfix release will be 2.4.1, in a couple of months.
(As usual - any questions, comments or whatever, let me know via email,
or #python-dev on irc.freenode.net)
Anthony
--
Anthony Baxter <anthony(a)interlink.com.au>
It's never too late to have a happy childhood.
I added a patch to SF: http://python.org/sf/1107887
I would like feedback on whether the approach is desirable.
The patch adds a new method type (flags) METH_ARGS that is used in
PyMethodDef. METH_ARGS means the min and max # of arguments are
specified in the PyMethodDef by adding 2 new fields. This information
can be used in ceval to
call the method. No tuple packing/unpacking is required since the C
stack is used.
The benefits are:
* faster function calls
* simplify function call machinery by removing METH_NOARGS, METH_O,
and possibly METH_VARARGS
* more introspection info for C functions (ie, min/max arg count)
(not implemented)
The drawbacks are:
* the defn of the MethodDef (# args) is separate from the function defn
* potentially more error prone to write C methods???
I've measured between 13-22% speed improvement (debug build on
Operton) when doing simple tests like:
./python ./Lib/timeit.py -v 'pow(3, 5)'
I think the difference tends to be fairly constant at about .3 usec per loop.
Here's a portion of the patch to show the difference between conventions:
-builtin_filter(PyObject *self, PyObject *args)
+builtin_filter(PyObject *self, PyObject *func, PyObject *seq)
{
- PyObject *func, *seq, *result, *it, *arg;
+ PyObject *result, *it, *arg;
int len; /* guess for result list size */
register int j;
- if (!PyArg_UnpackTuple(args, "filter", 2, 2, &func, &seq))
- return NULL;
-
# the are no other changes between METH_O and METH_ARGS
- {"abs", builtin_abs, METH_O, abs_doc},
+ {"abs", builtin_abs, METH_ARGS, abs_doc, 1, 1},
- {"filter", builtin_filter, METH_VARARGS, filter_doc},
+ {"filter", builtin_filter, METH_ARGS, filter_doc, 2, 2},
Neal
Dear Python Colleague:
The PyCon Program Committee is happy to announce that
the opening keynote speech, at 9:30 am on Wednesday
March 23 will be:
Python on the .NET Platform, by
Jim Hugunin, Microsoft Corporation
Jim Hugunin is well-known in the Python world for his
pioneering work on JPython (now Jython), and more
recently for the IronPython .NET implementation of
Python.
Jim joined Microsoft's Common Language Runtime team
in August last year to continue his work on Iron Python
and further improve the CLR's support for dynamic
languages like Python.
I look forward to hearing what Jim has to say, and
hope that you will join me and the rest of the Python
community at PyCon DC 2005, at George Washington
University from March 23-25, with a four-day sprint
starting on Saturday March 19.
Early bird registration rates are still available for
a few more days. Go to
http://www.python.org/moin/PyConDC2005/Schedule
for the current schedule, and register at
http://www.python.org/pycon/2005/
regards
Steve Holden
Chairman, PyCON DC 2005
--
PyCon DC 2005: The third Python Community Conference
http://www.pycon.org/http://www.python.org/pycon/
The scoop on Python implementations and applications
There is a discussion going on at the moment in postgresql-general about
plpythonu (which allows you write stored procedures in Python) and line
endings. The discussion starts here:
http://archives.postgresql.org/pgsql-general/2005-01/msg00792.php
The problem appears to be that things are working as documented in PEP-278:
There is no support for universal newlines in strings passed to
eval() or exec. It is envisioned that such strings always have the
standard \n line feed, if the strings come from a file that file can
be read with universal newlines.
So what happens is that if a Windows or Mac user tries to create a
Python stored procedure, it will go through to the server with Windows
line endings and the embedded Python interpreter will raise a syntax
error for everything except single line functions.
I don't think it is possible for plpythonu to fix this by simply
translating the line endings, as this would require significant
knowledge of Python syntax to do correctly (triple quoted strings and
character escaping I think).
The timing of this thread is very unfortunate, as PostgreSQL 8.0 is
being released this weekend and the (hopefully) last release of the 2.3
series next week :-(
--
Stuart Bishop <stuart(a)stuartbishop.net>
http://www.stuartbishop.net/
