Mailman 3 May 2002 - Python-Dev

Re: [Python-Dev] deprecating string module?
by Mats Wichmann 29 May '02

29 May '02

>Or maybe we could introduce a new warning category, >SilentDeprecationWarning, which is normally ignored (like >OverflowWarning already is). This could be turned on explicitly with >a -W option so someone wanting to check that their code is >future-proof would have an easy way to do so. > >I do not want to ignore all DeprecationWarning messages by default, as >it would defeat the main purpose of the warning. +1 I'm quite happy to leave deprecation warnings to an external tool, personally. I'm happy to use external tools for a lot of stuff, like "tell me about the likely version compatibility issues of this code".

1 0

Death of 1.5.2
by Aahz 29 May '02

29 May '02

On Wed, May 29, 2002, Skip Montanaro wrote: > > aahz> This is ridiculous. > > Perhaps you missed the smiley? No, I didn't, but after your comment about "whining", it appeared to me that regardless of the humor your underlying intent was quite serious. My point about ANSI C vs. K&R C goes to the heart of the discussion, I think: although Python development has overall been excellent at maintaining backward compatibility, the discussion about timescales for deprecation are overly aggressive, particularly in comparison with how long it takes to switch C versions. Here's a thought that just occurred to me: Python 2.0 was somewhat buggy and not GPL compatible. So I think it's fair in some respects to start the clock on the death of 1.5.2 sometime later, probably around the release of 2.1 or 2.0.1 -- that's only a year ago. I think there may be some serious underestimation about just how entrenched 1.5.2 has become. -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "In the end, outside of spy agencies, people are far too trusting and willing to help." --Ira Winkler

1 0

Russian Insects News (May) 2002
by Ilya Osipov 29 May '02

29 May '02

Dear Colleagues, Are you interested in insects? Then you should check out our site "Russian Butterflies" at "http://osipov.org/insects/" There are more than 3,000 insects listed in our price list: Lepidoptera, Coleoptera, Diptera, Hymenoptera, Hemiptera, Odonata and others from Europe, Russia, China, Pakistan, Taiwan, Thailand, Nepal, etc. There is also a huge online information, database of Russian butterflies. Many specimens photos are available. WEBMASTERS AND SITE OWNERS! I am glad to suggest to you new possibilities for advertising your site or homepage on "Russian butterflies" site. There are several ways to do that: 1. Add your message to "INSECTS FORUM" http://osipov.org/insects/forum (FREE) 2. Add your insect site to "TOP 100 INSECTS SITES" http://osipov.org/insects/top_list (FREE) 3. Add your link to http://osipov.org/insects/links.htm (FREE) To do that add our link to your site and reply to this message with URL of your site. 4. If you want your banner to be placed on each page of our site ("Russian<BR>butterflies" site has about 900 pages and about 1200 page views per day), please visit "http://osipov.org/insects/form.html" Sincerely yours, Ilya Osipov (Ph. D.) osipov(a)osipov.org http://www.osipov.org __________________________________________________________________________ Your email address was obtained from an opt-in list, Reference # 10023392. If you do not interested in insects, please resend this letter to your friends whom interesting in it. If you do not want to receive "RUSSIAN BUTTERFLIES NEWS" in future -send empty mail with Subject=UNSUBSCRIBE for i.osipov(a)mtu-net.ru

1 0

Out of date FAQ entries
by Neal Norwitz 29 May '02

29 May '02

I was looking over the FAQ and noticed a out-of-date entries. I fixed a few: 6.6. Why can't I derive a class from built-in types (e.g. lists or files)? ** Added note that this doesn't apply to 2.2+ 6.21. How do you specify and enforce an interface spec in Python? ** Added note that pychecker can find these problems. But there are some others, which I can't do a good job updating. The one's I did update could use some work too. :-) 6.5. Why does Python use methods for some functionality (e.g. list.index()) but functions for other (e.g. len(list))? Perhaps update comment about strings, numbers not having methods. 6.12. Why is there no more efficient way of iterating over a dictionary than first constructing the list of keys()? for k in d: # now works 6.13. Can Python be compiled to machine code, C or some other language? Should mention pysco? 6.24. Why no class methods or mutable class variables? Mention classmethod(), staticmethod()? I'm sure there's others that could use fixing. Neal

5 8

Re: [Python-Dev] Python 2.3 release schedule
by Michael Hudson 29 May '02

29 May '02

Neil Schemenauer <nas(a)python.ca> writes: > Michael Hudson wrote: > > I was under the impression that the 2.1 and 2.2 interfaces differed in > > ways that couldn't easily be papered over with macros. I'll check. > > It's not pretty. Look at pyexpat.c for an example. Perhaps something > like this would be good enough (untested): > > #if PY_VERSION_HEX < 0x020200B1 > #define PyObject_GC_New PyObject_New > #define PyObject_GC_NewVar PyObject_NewVar > #define PyObject_GC_Del PyObject_Del > #define PyObject_GC_Track(op) > #define PyObject_GC_UnTrack(op) > #endif > > People could then always use the 2.2 API but the objects would only be > collected in versions >= 2.2. Using the 2.1 API is a fair bit trickier > and you can't hide those differences using macros (although you could > make it easier for people who want to support 2.1 and >=2.2). Here's the latest effort: /* this idea of this file is that you bundle it with your extension, #include it, program to Python 2.3's memory API and have your extension build with any version of Python from 1.5.2 through to 2.3 (and hopefully beyond) */ #ifndef Py_PYMEMCOMPAT_H #define Py_PYMEMCOMPAT_H #include "Python.h" /* There are three "families" of memory API: the "raw memory", "object memory" and "object" families. (This is ignoring the matter of the cycle collector, about which more is said below). Raw Memory: PyMem_Malloc, PyMem_Realloc, PyMem_Free Object Memory: PyObject_Malloc, PyObject_Realloc, PyObject_Free Object: PyObject_New, PyObject_NewVar, PyObject_Del The raw memory and object memory allocators both mimic the malloc/realloc/free interface from ANSI C, but the object memory allocator can (and, since 2.3, does by default) use a different allocation strategy biased towards lots of lots of "small" allocations. The object family is used for allocating Python objects, and the initializers take care of some basic initialization (setting the refcount to 1 and filling out the ob_type field) as well as having a somewhat different interface. Do not mix the families! E.g. do not allocate memory with PyMem_Malloc and free it with PyObject_Free. You may get away with it quite a lot of the time, but there *are* scenarios where this will break. You Have Been Warned. Also, in many versions of Python there are an insane amount of memory interfaces to choose from. Use the ones described above. */ #if PY_VERSION_HEX < 0x01060000 /* raw memory interface already present */ /* there is no object memory interface in 1.5.2 */ #define PyObject_Malloc PyMem_Malloc #define PyObject_Realloc PyMem_Realloc #define PyObject_Free PyMem_Free /* the object interface is there, but the names have changed */ #define PyObject_New PyObject_NEW #define PyObject_NewVar PyObject_NEW_VAR #define PyObject_Del PyMem_Free #endif /* If your object is a container you probably want to support the cycle collector, which was new in Python 2.0. Unfortunately, the interface to the collector that was present in Python 2.0 and 2.1 proved to be tricky to use, and so changed in 2.2 -- in a way that can't easily be papered over with macros. This file contains macros that let you program to the 2.2 GC API. Your module will compile against any Python since version 1.5.2, but the type will only participate in the GC in versions 2.2 and up. Some work is still necessary on your part to only fill out the tp_traverse and tp_clear fields when they exist and set tp_flags appropriately. It is possible to support both the 2.0 and 2.2 GC APIs, but it's not pretty and this comment block is too narrow to contain a desciption of what's required... */ #if PY_VERSION_HEX < 0x020200B1 #define PyObject_GC_New PyObject_New #define PyObject_GC_NewVar PyObject_NewVar #define PyObject_GC_Del PyObject_Del #define PyObject_GC_Track(op) #define PyObject_GC_UnTrack(op) #endif #endif /* !Py_PYMEMCOMPAT_H */ Any final comments before I check it in? Particularly, I'd like Neil to read the comments about the cycle collector. Cheers, M. -- I'll write on my monitor fifty times 'I must not post self-indulgent wibble nobody is interested in to ucam.chat just because I'm bored and I can't find the bug I'm supposed to fix'. -- Steve Kitson, ucam.chat

1 0

_tkinter problem with Stackless
by Christian Tismer 28 May '02

28 May '02

Hi friends, I was trying to test my bdb.py patch with Idle and saw weird behavior under Stackless: When I close a window, Python crashes. After a while I recognized that this is due to my moving-the-stack-away at every 8th recursion level. As a quick hack, I changed the threshold to 16 and everything works just fine, but anyway: I believe that there must be a global data structure for Tcl/Tk living on the C stack, between a couple of Python interpreter incarnations, that is used somehow. This is unsane IMHO. Nothing on the C stack should be used as a globally accessible variable. Instead I'd like to stuff this into a structure on the heap, which is safe. Can anybody please give me a hint where in _tkinter or tkappinit this might be? I really don't understand the code, but I'd like to provide a patch. many thanks in advance - chris -- Christian Tismer :^) <mailto:tismer@tismer.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 pager +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/

7 23

Re: [Python-Dev] Allowing Unicode literals even without Unicode support?
by Michael Hudson 28 May '02

28 May '02

Guido van Rossum <guido(a)python.org> writes: > Many test modules fail because they use Unicode literals. It's easy > enough to skip Unicode-related tests (just test for the existence of > 'unicode'), but it's hard to avoid having Unicode literals in the text > at all. Should we perhaps silently interpret Unicode literals as > regular string literals when compiling without Unicode support? Hmm. It would be nice to have less tests fail in --disable-unicode builds (there were real bugs hiding in there!). But I'm not sure that accepting u'' literals is wise, generally speaking, just because of the confusion it might cause. Perhaps a commandline flag? Anyway, I've been meaning to post here about --disable-unicode builds for a while, so here's some issues that currently exist. 1) In --disable-unicode builds, it seems that much of the codec machinery just doesn't exist. While this was fine once, we now have, e.g. >>> "sheesh".encode("rot-13") 'furrfu' But in a disable unicode build: >>> "sheesh".encode("rot-13") Traceback (most recent call last): File "<stdin>", line 1, in ? File "/home/mwh/src/python/dist/src/Lib/encodings/rot_13.py", line 18, in encode return codecs.charmap_encode(input,errors,encoding_map) AttributeError: 'module' object has no attribute 'charmap_encode' This is why test_string still fails. I'm not sure what to do about this. 2) Some library modules just don't seem to function without unicode. Current bad boys seem to include gettext, urllib (well, this just got fixed I think), minidom, pyexpat and the email package. I could imagine the xml modules and the email package just plain not being supported w/o unicode. gettext, too, I guess. In which case: 3) regrtest should probably be taught not to run test_unicode + close friends in --disable-unicode builds. Anyone feel like digging into any of the above? Cheers, M. -- You're posting to a Scheme group. Around here, arguing that Java is better than C++ is like arguing that grasshoppers taste better than tree bark. -- Thant Tessman, comp.lang.scheme

6 11

Fatal Python error: GC object already in linked list
by Guido van Rossum 28 May '02

28 May '02

I'm forwarding this report to python-dev since it's unlikely that anyone on the zope3 list will be able to provide insight. (I'm not *much* more optimistic about python-dev, but it is a possibility. :-) Please keep Steve cc'ed as he's not a python-dev subscriber. --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Tue, 28 May 2002 14:14:10 +0100 From: Steve Alexander <steve(a)cat-box.net> To: "'Zope 3 Mailing List'" <Zope3-dev(a)zope.org> Subject: [Zope3-dev] Fatal Python error: GC object already in linked list While working on Annotations their interaction with ContextWrappers / Security Proxies, I got this error: Fatal Python error: GC object already in linked list Aborted No other details, no traceback. I was left with the Data.fs locked by three other Python processes that required a kill -9 to get rid of. I haven't been able to reproduce the error since. Python 2.2.1, compiled from source on a Pentuim 4, RedHat 7.3 box. - -- Steve Alexander _______________________________________________ Zope3-dev mailing list Zope3-dev(a)zope.org http://lists.zope.org/mailman/listinfo/zope3-dev ------- End of Forwarded Message

2 2

Re: [Python-Dev] Python 2.3 release schedule
by Michael Hudson 27 May '02

27 May '02

Tim Peters <tim.one(a)comcast.net> writes: > [Michael Hudson] > > Writing a pymemcompat.h that people can bundle with their extensions > > and then use the 2.3 memory interface with all Pythons in the range > > 1.5.2 to 2.3. I said I'd do this once the interface is settled, so > > I'll try to get to it in the next week or so. It shouldn't be *that* > > hard... > > I think that's a great idea! Feel free to commandeer as much time from MAL > and /F as you want, since they'll whine if it isn't done <wink>. Surprise of the day: this: #if PY_VERSION_HEX < 0x01060000 /* raw memory interface already present */ /* there is no object memory interface in 1.5.2 */ #define PyObject_Malloc(size) PyMem_Malloc((size)) #define PyObject_Realloc(p, size) PyMem_Realloc((p), (size)) #define PyObject_Free(p) PyMem_Free((p)) /* the object interface is there, but the names have changed */ #define PyObject_New(type, typeobj) \ PyObject_NEW((type), (typeobj)) #define PyObject_NewVar(type, typeobj, n) \ PyObject_NEW_VAR((type), (typeobj), (n)) #define PyObject_Del(ob) \ PyMem_Del((ob)) #endif is all that's required! Here's the full header I propose checking in to Misc/pymemcompat.h (although the verbiage seems a bit excessive now). /* this idea of this file is that you bundle it with your extension, #include it, program to Python 2.3's memory API and have your extension build with any version of Python from 1.5.2 through to 2.3 (and hopefully beyond) */ #ifndef Py_PYMEMCOMPAT_H #define Py_PYMEMCOMPAT_H #include "Python.h" /* There are three "families" of memory API: the "raw memory", "object memory" and "object" families. Raw Memory: PyMem_Malloc, PyMem_Realloc, PyMem_Free Object Memory: PyObject_Malloc, PyObject_Realloc, PyObject_Free Object: PyObject_New, PyObject_NewVar, PyObject_Del The raw memory and object memory allocators both mimic the malloc/realloc/free interface from ANSI C, but the object memory allocator can (and, since 2.3, does by default) use a different allocation strategy biased towards lots of lots of "small" allocations. The object family is used for allocating Python objects, and the initializers take care of some basic initialization (setting the refcount to 1 and filling out the ob_type field) as well as having a somewhat different interface. Do not mix the families! I.e. do not allocate memory with PyMem_Malloc and free it with PyObject_Free. You may get away with it quite a lot of the time, but there *are* scenarios where this will break. You Have Been Warned. Also, in many versions of Python there are an insane amount of memory interfaces to choose from. Use the ones described above.*/ #if PY_VERSION_HEX < 0x01060000 /* raw memory interface already present */ /* there is no object memory interface in 1.5.2 */ #define PyObject_Malloc(size) PyMem_Malloc((size)) #define PyObject_Realloc(p, size) PyMem_Realloc((p), (size)) #define PyObject_Free(p) PyMem_Free((p)) /* the object interface is there, but the names have changed */ #define PyObject_New(type, typeobj) \ PyObject_NEW((type), (typeobj)) #define PyObject_NewVar(type, typeobj, n) \ PyObject_NEW_VAR((type), (typeobj), (n)) #define PyObject_Del(ob) \ PyMem_Del((ob)) #endif #endif /* !Py_PYMEMCOMPAT_H */ Comments, flames, etc appreciated. Cheers, M. -- But since I'm not trying to impress anybody in The Software Big Top, I'd rather walk the wire using a big pole, a safety harness, a net, and with the wire not more than 3 feet off the ground. -- Grant Griffin, comp.lang.python

3 2

Re: [Python-Dev] Python 2.3 release schedule
by Michael Hudson 27 May '02

27 May '02

Bernhard Herzog <bh(a)intevation.de> writes: > Michael Hudson <mwh(a)python.net> writes: > > > > [Michael Hudson] > > > > Writing a pymemcompat.h that people can bundle with their extensions > > > > and then use the 2.3 memory interface with all Pythons in the range > > > > 1.5.2 to 2.3. > [...] > > Surprise of the day: this: > > > > #if PY_VERSION_HEX < 0x01060000 > [...] > > #define PyObject_Del(ob) \ > > PyMem_Del((ob)) > > > > #endif > > Have you actually tried it? Well, obviously not: > There is no PyMem_Del in Python 1.5.2. You're right of course. Thanks for the heads up. I've changed it to PyMem_Free now. See any other problems? Cheers, M. -- Reading Slashdot can [...] often be worse than useless, especially to young and budding programmers: it can give you exactly the wrong idea about the technical issues it raises. -- http://www.cs.washington.edu/homes/klee/misc/slashdot.html#reasons

1 0