Mailman 3 May 2004 - Python-Dev

Re:import.c
by Wiktor Sadowski 29 May '04

29 May '04

Circular import cases could be detected by adding an int "state" field (initialized to 0 in PyModule_New) to the module object and PyModule_GetState/PyModule_SetState api functions to access the field. Then: in load_module (import.c) set the state to 1 ,when a module is completly loaded: /*just before return*/ if(m) PyModule_SetState(m,1) return m; ---------------------------------------------------------------------------- -------- in import_from (ceval.c): if (x == NULL && PyErr_ExceptionMatches(PyExc_AttributeError)) { if(!PyModule_GetState(v)) /*raise the error and warn against circular import*/ else /*default error*/ ---------------------------------------------------------------------------- -------- the same in PyGeneric_GetAttr (object.c): /* before raising an error*/ if(PyModule_Check(obj) && !PyModule_GetState(obj)) /*add a circular import warning to the error string*/ else /*default error*/ ---------------------------------------------------------------------------- -------- Probably there are some other places where modules state should be changed or checked but the solution I am proposing would help to localize most of them; A module's dict could be used to mark it's state but in my opinion an additional field is much safer (the same applays to PyModule_GetState/PyModule_SetState vs a new member def) Also: the soluton would enable checking for partially-loaded/broken modules in system.modules dict. Regards, Wiktor Sadowski

2 1

cPickle bug (was: Saving recursive objects to disc. cPickle wan't work)
by Christian Tismer 29 May '04

29 May '04

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? >> >>alex > > > 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 > python. > > 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:tismer@stackless.com> 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/

1 0

Re: Hello
by Bwarsaw 28 May '04

28 May '04

6 6

import.c
by Tim Peters 28 May '04

28 May '04

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>.

3 2

Encrypted document
by Bwarsaw 28 May '04

28 May '04

1 0

FW: [Python-Dev] Standard Library Tour Part II
by Raymond Hettinger 27 May '04

27 May '04

Fred, The current library tour in the tutorial is stored at: http://docs.python.org/tut/node12.html 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. Raymond [Aahz] > I hope that this next round of updates doesn't break links > to the floating point appendix the way the last one did.

2 1

RE: [Python-Dev] Re: Hello
by Samuele Pedroni 27 May '04

27 May '04

At 11:27 27.05.2004 -0400, Tim Peters wrote: >[Barry] > > 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 >Extension). > >I traced one claiming to come from you to an ISP in Kenya. At least that >was creative! 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.

2 1

RE: [Python-Dev] pre-announcing 2.4
by Chermside, Michael 27 May '04

27 May '04

> 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.

2 1

RELEASED Python 2.3.4 (final)
by Anthony Baxter 27 May '04

27 May '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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: ~ http://www.python.org/2.3.4 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 ~ 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) - -- 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 iD8DBQFAtcm4Dt3F8mpFyBYRAmgmAJ41U7s98dnQjOOD5XAqqPBJEXvRZwCcCm6x HQQ0vky/iPxSagROZk9Uk8M= =W9rA -----END PGP SIGNATURE-----

1 0

pre-announcing 2.4
by Anthony Baxter 27 May '04

27 May '04

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 """ -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0