Mailman 3 October 2001 - Python-Dev

status of OS/2 ports of Python
by Andrew MacIntyre Oct. 29, 2001

Oct. 29, 2001

Unfortunately I haven't had the bandwidth to vigorously pursue completing integration of my previously submitted patches, and at this time don't expect to be able to do much until about the time 2.2b2 is scheduled to hit the streets :-(. So I don't expect that 2.2 will have OS/2+EMX build support in the sourceball... At this stage, my plan is to finalise a binary release of 2.2 before submitting a new set of patches, taking into account Martin von Loewis' comments and suggestions (much appreciated thank you!) among others. I also plan to try and coordinate my patches with those of Michael Muller (473749, 474169 & 474500 so far) for the VAC++ build of Python for OS/2. I will try and review Michael's patches with a view to getting them into 2.2, as the VAC++ build has been part of the sourceball for a few versions. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac(a)bullseye.apana.org.au | Snail: PO Box 370 andymac(a)pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia

3 5

Re: [Python-Dev] Idle speed freak looking for trouble?
by Fredrik Lundh Oct. 27, 2001

Oct. 27, 2001

I wrote: > python 1.5: 1.02 seconds > python 2.0: 1.95 seconds > python 2.1: 1.85 seconds > python 2.2: 1.90 seconds doh. forgot to disable GC for 2.0 and later. with GC switched off, the difference is a bit smaller. python 1.5: 1.02 seconds python 2.0: 1.30 seconds python 2.1: 1.20 seconds python 2.2: 1.05 seconds now replace [None, None, None] with [item, item, item]: python 1.5: 0.58 seconds python 2.0: 0.85 seconds python 2.1: 0.69 seconds python 2.2: 0.71 seconds playing with other dosomething bodies (and with GC switched off), I've noticed that the following things has gotten slower from 1.5.2 to 2.2: - concatenating strings (item+item+item is 20% slower) - calling the float builtin using global lookup (20% slower) - list and tuple forming using locals (10-20% slower) </F>

1 0

dict comps
by Jeremy Hylton Oct. 27, 2001

Oct. 27, 2001

We agreed yesterday that the dictionary() constructor would accept a a list of two-tuples (strictly speaking an iterable object of iterable objects of length 2). That plus list comprehensions pretty much covers the territory of dict comprehensions: >>> print dictionary([(i, chr(65 + i)) for i in range(4)]) {0: 'A', 1: 'B', 2: 'C', 3: 'D'} Jeremy

4 5

Idle speed freak looking for trouble?
by Tim Peters Oct. 27, 2001

Oct. 27, 2001

SF bug 474992 contains a simple benchmark claimed to show dramatic slowdown from 1.5.2 to 2.0, and again but less so from 2.0 to 2.1. Also major slowdown from enabling gc. I *believe* Frederic ran it on Tru64. no-time-here-ly y'rs - tim

3 2

iterator support for SRE?
by Fredrik Lundh Oct. 27, 2001

Oct. 27, 2001

a common wish for SRE is a variant of findall that returns all match objects, instead of the strings. recently, I realized that the internal scanner type (originally added to speed up Python versions of findall/sub/split) can be wrapped in an iterator, allowing the user to loop over all matches. >>> import re >>> p = re.compile(somepattern) >>> for match in iter(p.scanner(somestring).search, None): >>> print match.groups() how about adding a "finditer" method, which takes care of the low-level setup: >>> for match in p.finditer(somestring): >>> print match.groups() or should we just make the scanner factory an official part of the SRE interface? </F>

4 5

Re: [Python-Dev] innocent question ;-)
by Jack Jansen Oct. 26, 2001

Oct. 26, 2001

> > Is the list of subtypable types now complete (for 2.2), > > or do you indend to do more? > > I just found a few extension modules that define their own types, like > SocketType. I'd like to see those converted. I don't know if I have > time. At what point can we consider the API stable? All this inheriting and subtyping seems like it would be absolutely brilliant for the Mac toolbox APIs (and I suspect also for the PythonWin API's, Mark?) but I've refrained from even looking at it (well, I did have a quick peek:-), because (a) I have no time, (b) I don't want to chase a changing API and (c) there's some methodchain-based poor-mans-inheritance in there already that will undoubtedly break. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

2 1

Which one of our FREE website enhancements would you like?
by Gary M. Gordon Oct. 26, 2001

Oct. 26, 2001

1 0

innocent question ;-)
by Thomas Heller Oct. 26, 2001

Oct. 26, 2001

... about my beloved buffer object: Would a patch to make the buffer object subclassable be still accepted for 2.2, or does this fall under the feature freeze? Another question: It is my understanding that makeing an object subclassable also exposes its constructor to Python. What is the signature of this constructor? Is the three argument version xxx(name, bases, dict) always used to return a new type object (Don Beaudry hook), and can other signatures freely be used to creates objects/instances of this type/class? Thomas

2 3

weird gdb/python/gtk/pango interaction?
by Skip Montanaro Oct. 26, 2001

Oct. 26, 2001

Folks, I'm no longer able to run PyGtk scripts from gdb under some circumstances. I am using the CVS HEAD of glib, atk, pango, gtk+ and pygtk. The following simple Python script works fine when run from gdb: #!/usr/bin/env python import gtk w = gtk.Window() w.connect("destroy", gtk.mainquit) #lbl = gtk.Label("hi") #w.add(lbl) w.show_all() gtk.mainloop() with the following output: (gdb) r basic.py Starting program: /usr/local/bin/python basic.py [New Thread 1024 (LWP 19044)] Gtk-Message: YOU ARE USING THE DEVEL BRANCH 1.3.x OF GTK+ WHICH IS CURRENTLY UNDER HEAVY DEVELOPMENT AND FREQUENTLY INTRODUCES INSTABILITIES. if you don't know why you are getting this, you probably want to use the stable branch which can be retrieved from ftp://ftp.gtk.org/pub/gtk/v1.2/ or via CVS with cvs checkout -r glib-1-2 glib; cvs checkout -r gtk-1-2 gtk+ Program exited normally. If I uncomment the two lines involving lbl, however, I get this mess: (gdb) r basic.py Starting program: /usr/local/bin/python basic.py [New Thread 1024 (LWP 19127)] Gtk-Message: YOU ARE USING THE DEVEL BRANCH 1.3.x OF GTK+ WHICH IS CURRENTLY UNDER HEAVY DEVELOPMENT AND FREQUENTLY INTRODUCES INSTABILITIES. if you don't know why you are getting this, you probably want to use the stable branch which can be retrieved from ftp://ftp.gtk.org/pub/gtk/v1.2/ or via CVS with cvs checkout -r glib-1-2 glib; cvs checkout -r gtk-1-2 gtk+ basic.py (pid:19127): GRuntime-CRITICAL **: file gparamspecs.c: line 1687 (g_param_spec_float): assertion `default_value >= minimum && default_value <= maximum' failed basic.py (pid:19127): GRuntime-CRITICAL **: file gobject.c: line 270 (g_object_class_install_property): assertion `G_IS_PARAM_SPEC (pspec)' failed basic.py (pid:19127): ** WARNING **: Couldn't load font "Sans -2.09715e+06" falling back to "Sans -2.09715e+06" basic.py (pid:19127): ** WARNING **: Couldn't load font "Sans -2.09715e+06" falling back to "Sans -2.09715e+06" basic.py (pid:19127): ** WARNING **: All font failbacks failed!!!! Program exited with code 01. If I change the Label to an EventBox, everything works, presumably because no font rendering is involved. Also when I run the script from the bash prompt it works as expected (no Gtk warnings). The equivalent C program: #include <gtk/gtk.h> int main( int argc, char *argv[] ) { GtkWidget *window; GtkWidget *label; gtk_init(&argc, &argv); window = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_signal_connect (GTK_OBJECT (window), "destroy", GTK_SIGNAL_FUNC(gtk_main_quit), NULL); gtk_window_set_title (GTK_WINDOW (window), ""); label = gtk_label_new("hi"); gtk_container_add(GTK_CONTAINER(window), label); gtk_widget_show_all (GTK_WIDGET(window)); gtk_main(); return(0); } works as expected, both from the command line and if run from the gdb prompt. This wouldn't be such a big deal, except in a more complex script I get segfaults in some circumstances, and this makes debugging that problem a bit difficult. Any idea what's going on? -- Skip Montanaro (skip(a)pobox.com) http://www.mojam.com/ http://www.musi-cal.com/

2 1

[development doc updates]
by Fred L. Drake Oct. 26, 2001

Oct. 26, 2001

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Yet another experimental change to the presentation -- ditch the proportional font for code since some displays (especially interactive sessions and tabular displays) get messed up with proportional fonts. We do try to use monospaced fonts that are less ugly than Courier. As before, feedback on the fonts is welcome at python-docs(a)python.org.

1 0