Alex Polite wrote:
> On ons, maj 26, 2004 at 02:22:21 +0000, Alex Polite wrote:
>>I need to put recursive data structures on disc and found out that cPickle
>>doesn't like recursion.
>>What are my options?
> Christian Tismer had the kindness to look at my code and point out
> that I might want to use pickle instead of cPickle, at least if I
> wanted to benefit from using stackless. Chaning from cPickle to pickle
> allowed to run the code under stackless as well as under standard
> thanks Christian.
Although I'm happy that things work even without Stackless,
this implies that there is an incompatibility between
pickle and cPickle.
If objects are treated identically by both, that normal Python
must use even more stack space for recursive objects that
cPickle, so I'd expect it crashes earlier.
But it doesn't crash. cPickle must have a bug.
ciao - chris
Christian Tismer :^) <mailto:firstname.lastname@example.org>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
Does anyone living understand import.c in all its gory glory now?
There are two things about it I'd like to address (or see addressed):
1. The business wherein a failing import leaves behind a (at least
one) damaged (incomplete) module object in sys.modules has caused
me debugging nightmares for years. These are especially acute
when "clever" code suppresses the errors. Then sys.modules
can claim to have modules that aren't actually usable, but
would-be importers have no way to know which are damaged, or
how badly damaged they may be.
2. Zope3 in particular is having horrid problems with circular
imports. These are also a bitch to track down. I'm not sure
it was any better in Zope2, but Zope3 has been undergoing
frequent and massive refactorings (and a new round of unintended
circular imports creates subtle problems each time).
If someone wants to fix these over the weekend, that would be great <wink>.
The current library tour in the tutorial is stored at:
Each of the chapters is consecutively numbered, so if a new chapter is
inserted, hard links to a section of the documentation will break.
Is there away to have the nodes named rather than numbered. Aahz likes
to point directly at the floating point Appendix and is mess up his day
when I add to the tutorial.
> I hope that this next round of updates doesn't break links
> to the floating point appendix the way the last one did.
At 11:27 27.05.2004 -0400, Tim Peters wrote:
> > Crap. We're probably seeing the leading edge of a spam technique we've
> > long suspected could happen. I'll be signing my posts from now on....
>I mentioned this morning that I've been getting a lot of this stuff directly
>(visibly addressed only to me), claiming to come from people on python-dev
>(past and present, from Vladimir Marangozov to Guido -- and even some
>claiming to come from me!). None have been spam so far, they've all been
>lame Windows viruses, mostly hiding in .cpl files (Windows Control Panel
>I traced one claiming to come from you to an ISP in Kenya. At least that
well one no fun part is that you can get failure delivery messages from the
ultimate destination (either because of an invalid address, or some
antivirus/spam software that believes that the From is the relevant source)
to the forged from.
> Fixes will be accepted
> all through the release process - although once we get to the
> first beta, bugs that change behaviour will have a harder path.
I'd propose one change. Weaken the above statement. People will
take that to mean that THEIR fix will be accepted ANYWHERE in
the release process (including the day before the release). I'd
suggest something more like this:
Fixes are welcomed up through the alpha release, but as we
get closer to the release date we will be less and less
likely to accept patches that change behavior.
Maybe that's too harsh, but I think your original wording is
inviting complaints later on.
-- Michael Chermside
This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.
-----BEGIN PGP SIGNED MESSAGE-----
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.3.4 (final).
Python 2.3.4 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.
For more information on Python 2.3.4, including download links for
various platforms, release notes, and known issues, please see:
Highlights of this new release include:
~ - Bug fixes. According to the release notes, more than 20 bugs
~ have been fixed, including a couple of bugs that could cause
~ Python to crash. These were discovered by Zope3.
Highlights of the previous major Python release (2.3) are available
from the Python 2.3 page, at
Enjoy the new release,
Python Release Manager
(on behalf of the entire python-dev team)
Anthony Baxter <anthony(a)python.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
So this is the email that I'm planning to send to python-announce
and python-list/c.l.py shortly. Anyone have any changes/additions
they'd like to see? This will become a standard part of the release
process for future releases...
This is a pre-announcement that the first alpha of Python 2.4
is about a month away. The purpose of this notice is to give
people a heads up - if you have a bug that you want to see
fixed for 2.4, start looking at it now. Fixes will be accepted
all through the release process - although once we get to the
first beta, bugs that change behaviour will have a harder path.
So, if you have a bug you want to see fixed, what should you do?
If it's not logged on SF, log it.
If it's logged, consider adding a patch that fixes the problem,
or at least a simple test case that demonstrates the bug.
If someone else has supplied a fix, see if this fix works for
you, and post your results to the bug.
If there's a working fix, feel free to add a note asking for
the fix to go into CVS. The SF bug tracker for Python has a
_lot_ of bugs in it, and it's easy for bugs to be overlooked.
On behalf of the python-dev team, thanks!
Anthony Baxter <anthony(a)interlink.com.au>
It's never too late to have a happy childhood.