Mailman 3 October 2000 - Python-Dev

Re: [Python-checkins] SourceForge problems
by Fredrik Lundh 28 Oct '00

28 Oct '00

fred wrote: > At any rate, there has been activity in the source tree; you just > might want to do a CVS update to see what's changed. There have been > a number of bug fixes, a fair number of documentation updates, and > many of the modules in the standard library have been passed through > Tim Peter's reindent.py script (look in Tools/scripts/). now that this has been done, emacs users might want to add something like the following to their local configuration (based on code by jwz, so it should work...) ::: (defun python-mode-untabify () (save-excursion (goto-char (point-min)) (while (re-search-forward "[ \t]+$" nil t) (delete-region (match-beginning 0) (match-end 0))) (goto-char (point-min)) (if (search-forward "\t" nil t) (untabify (1- (point)) (point-max)))) nil) (add-hook 'python-mode-hook '(lambda () (make-local-variable 'write-contents-hooks) (add-hook 'write-contents-hooks 'python-mode-untabify))) </F>

1 0

Re: PythonLabs Team Moves to Digital Creations
by Jim Fulton 27 Oct '00

27 Oct '00

Guido van Rossum wrote: > (snip) > I am proud to have found a new home for my entire team: starting > today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself > are working for Digital Creations. We will be spending part of our > time on core Python development (including Jython and Mailman) and > part of our time on Python infrastructure improvements that also > benefit Zope. Needless to say (but I'll say it anyway), Digital Creations is proud and thrilled that the this team has joined us. These are indeed exciting times! Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org

1 0

PythonLabs Team Moves to Digital Creations
by Guido van Rossum 27 Oct '00

27 Oct '00

To all Python users and developers: Less than half a year ago, I moved with my team to BeOpen.com, in the hope of finding a new permanent home for Python development. At BeOpen, we've done several good things for Python, such as moving the Python and Jython development process to SourceForge, and the successful release of Python 2.0. Unfortunately, BeOpen.com's original plans for PythonLabs didn't work out as hoped, and we weren't able to reach mutual agreement on workable alternative plans -- despite trying for months. I am proud to have found a new home for my entire team: starting today, Tim Peters, Barry Warsaw, Jeremy Hylton, Fred Drake and myself are working for Digital Creations. We will be spending part of our time on core Python development (including Jython and Mailman) and part of our time on Python infrastructure improvements that also benefit Zope. Python will remain Open Source; Digital Creations has no desire to monetize or brand the Python language or specific Python distributions. All future work we do on Python as Digital Creations employees will be owned by a non-profit organization yet to be created. We think of this new organization as the Python Software Foundation. In the meantime (while the PSF is under construction) I will own such copyrights personally. We're excited to be working for Digital Creations: they are one of the oldest companies active in the Python community, one of the companies most committed to Python, and they have a great product! Plus, we know they have deep financial backing. We trust that Digital Creations will provide a stable home for Python for many years. Digital Creations has also offered to take over hosting of the python.org and starship sites. On behalf of the Python community, we're grateful for this support of the two prime community sites for Python, and we expect to be implementing the transitions shortly. These are exciting times for the PythonLabs team -- and also for Python and its community. Mainstream successes for Python are showing up everywhere, and we're proud to be a part of such a smart and friendly community. A great year lies ahead! --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Miscellaneous comments on Tkinter and related matters
by Cameron Laird 27 Oct '00

27 Oct '00

I can rarely afford to dip into Python-Dev. My head is exploding too much of the time as it is. Maybe I can help with the recent Tkinter discussions, though. 1. Tcl's going to be around for a long time. Here's the insider scoop on what the Ajuba Solutions announcement means: insiders don't know. That is, *nobody* is sure how Tcl will develop. It'll survive, though, for quite a while. Do NOT worry that it'll suddenly dry up and blow away. I'm working on a more detailed explanation of Tcl processes. It'll probably take a few weeks, though. In the meantime, just ignore the mess, and understand that the Tcl Core Team includes bright people who'll land on their feet somehow. 2. I agree that MacOS is the thorny problem for the standard Pysolution. I'd be happy to discuss the possibilities (Tkinter? wxWindows? Qt?!? GTK+?!!?!? ...) with a smaller group, and, of course, Fredrik, Robin, Guido, ... all are quite knowledgeable about these matters. There are a few things you should know about the Tcl side. The bad is that Tk is barely maintained for MacOS. It's really rather miserable. On the other hand, Jim Ingham is now an Apple employee, and things could change in a hurry, at any time. The good is that Tk starts far ahead of any competitor. It has already solved most of the hard problems. All it needs is a little maintenance. 3. Is there a way to have Tk without contamination by Tcl? More than ever. This is what makes me most cheerful about Tkinter's prospects. The Tcl Core Team has largely given up its hangups about co-operating with foreigners (or its hangups that barbarians have hangups about co- operating with Tcl). This is a *very* good time for someone like Fredrik to establish a working relationship, and get CVS access. I really think Tk can be maintained by a different group than Tcl. Perl, Ruby, ... folks are also receptive to the idea (I've talked with them). For pointers to some of what's happening in this area, see <URL:http://starbase.neosoft.com/~claird/comp.lang.misc/core_enhancement.html> Also, you should know that my favorite enhancement to Tk is a remodularization called TkGS. This should improve performance under Win*, make it more portable to BeOS, improve access by Python, and so on. 4. Greg's right that some publishers are dumping Tcl. Not all, though. If it matters, we can go into details. 5. Pango is indeed cool, but it's different from [text]. The world is probably moving to Pango and similar implementations. The world will be missing much of what [text] offers. 6. ANYONE with an urge to get out a Python-related idea should pursue it. *DDJ*'s a great outlet. It's far from the only one. If people have ideas about articles, but are held back by lack of time/ fluency/contacts/..., *please* get in touch with me. I'll find a way at least to give articles a fair chance at being published. Cameron Laird <claird(a)NeoSoft.com> +1 281 996 8546 FAX http://starbase.neosoft.com/~claird/misc.writing/publications.html

5 6

Starship is still down...
by M.-A. Lemburg 27 Oct '00

27 Oct '00

It's been over a week since I posted my last gripe about our community server starship being unreachable. Nothing has happened so far... is there any chance on getting the server up and running again ? I am a bit concerned about the lack of support here: starship should be considered a very important part in the Python universe (after all, many Python extension packages and goodies are available from that site). With the frequent downtimes we recently had, I think people will get a wrong picture about the Python community support. Here's a traceroute from Germany to starship: traceroute to starship.python.net (208.185.174.112), 30 hops max, 40 byte packets 1 193.158.137.129 (193.158.137.129) 24 ms 23 ms 23 ms 2 193.158.137.130 (193.158.137.130) 24 ms 35 ms 25 ms 3 D-gw13.D.net.DTAG.DE (212.185.10.22) 67 ms 24 ms 35 ms 4 K-gw13.K.net.DTAG.DE (194.25.124.137) 26 ms 25 ms 25 ms 5 F-gw13.F.net.DTAG.DE (194.25.121.101) 32 ms 33 ms 33 ms 6 TysonsC-gw12.USA.net.DTAG.DE (194.25.6.98) 113 ms 127 ms 131 ms 7 TysonsC-gw1.USA.net.DTAG.DE (194.25.6.113) 115 ms 117 ms 134 ms 8 mae-east-switch0.maee.above.net (208.184.210.9) 134 ms 114 ms 123 ms 9 core1-mae-east-oc3-1.iad.above.net (209.133.31.225) 122 ms 116 ms 115 ms 10 sjc2-iad-oc48.sjc2.above.net (216.200.127.26) 184 ms 186 ms 185 ms 11 core5-core3-oc48.sjc2.above.net (208.185.156.66) 183 ms 184 ms 186 ms 12 sjc2-gige-main1.colo6.sjc2.above.net (208.185.156.37) 299 ms 183 ms !H 188 ms !H 13 * * * 14 * * * ... It looks as if ABOVE.NET is having some serious routing problems. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

3 2

RE: [Python-Dev] What to choose to replace Tkinter?
by Charles G Waldman 27 Oct '00

27 Oct '00

Mark Hammond writes: > > > Agreed. However, XPFE works fine here IMO. > > > cgw> "Here" means on MS-Win, right? Maybe that's why our perceptions are > cgw> so different. > > Correct. Although I have run it under Linux a few times, I wouldnt really > know LAF issues if I tripped over them there ;-) > > Mark. It's certainly true that the lack of a consistent look and feel for Linux apps has been somewhat of a problem historically. However, with the emergence of Gnome, it seems that there is finally some convergence. (Althought people in the KDE/Qt camp will certainly not agree!) Gnome is gathering momentum, especially now that Sun has joined the Gnome Foundation. With outfits like Eazel, Helix Code, etc, turning out high-quality products, things are moving fast in the Gnome/Gtk+ world and it seems clear to me that this will be the major desktop platform for Unix machines in the upcoming decade. Back in my former life, when I was still worrying about Windows, the company I worked for bought into a commerical x-platform GUI toolkit called Galaxy (I mentioned this earlier). Galaxy re-implemented all the native widgets, kind of like XPFE does. One issue with this was that MS seemed to change something about the widgets in every release - e.g. the Galaxy filechooser looked like Windows 3.1, then Win95 came out and Galaxy had to play catch-up. Once Galaxy had the Win95 LAF, Win98 came out. Now I hear there's something called Windows ME. Have they changed the look-and-feel again? Seems to me like all the widget-reimplementors are doomed to playing eternal catch-up. OK, enough off-topic rambling (for now), -C

20 40

A possible bit for a README or FAQ?
by Skip Montanaro 26 Oct '00

26 Oct '00

Just came across this error while running configure: checking for gcc... gcc checking whether the C compiler (gcc ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. The problem was that /tmp was full - sort of. The system says there's no space: % cat /etc/termcap > /tmp/termcap bash: /tmp/termcap: No space left on device but df disagrees: % df /tmp Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda5 153667 88796 56935 61% / Short term workaround is to run configure with TMPDIR set somewhere else. Perhaps this is something to put in a gcc-specific or Unix-specific section of the README file. I didn't see anything, and the message emitted by configure gave no hint at the cause of the problem. I realized what it was because I've been scratching my head about this problem for a couple weeks. If this is deemed useful I'll modify README and check it in. If not, no big deal. (I have no idea why the system thinks /tmp is full... sigh ...) Skip

5 7

Gradual migration PEP
by Paul Prescod 26 Oct '00

26 Oct '00

PEP: XXX Title: Guidelines for introducing backwards incompatibilities Version: $Revision: 1.0 $ Author: Paul Prescod <paul@prescod.net,paulp@activestate.com> Status: Draft Type: Standards Track Python-Version: All Created: 25-Oct-2000 Abstract In the natural evolution of programming languages it is sometimes necessary to make changes that modify the behaviour of older programs. This PEP proposes a policy for implementing these changes in a manner respectful of the installed base of Python users. Implementation Details Implementation of this PEP requires the addition of a formal warning and deprecation facility that will be described in another proposal. Scope These guidelines apply to future versions of Python that introduce backward-incompatible behaviour. Backward incompatible behaviour is a major deviation in Python interpretation from an earlier behaviour described in the standard Python documentation. Removal of a feature also constitutes a change of behaviour. This PEP does not replace or preclude other compatibility strategies such as dynamic loading of backwards-compatible parsers. On the other hand, if execution of "old code" requires a special switch or pragma then that is indeed a change of behavior from the point of view of the user and that change should be implemented according to these guidelines. In general, common sense must prevail in the implementation of these guidelines. For instance changing "sys.copyright" does not constitute a backwards-incompatible change of behavior! Steps For Introducting Backwards-Incompatible Features 1. Propose backwards-incompatible behavior in a PEP. The PEP must include a section on backwards compatibility that describes in detail a plan to complete the remainder of these steps. 2. Once the PEP is accepted as a productive direction, implement an alternate way to accomplish the task previously provided by the feature that is being removed or changed. For instance if the addition operator were scheduled for removal, a new version of Python could implement an "add()" built-in function. 3. Formally deprecate the obsolete construct in the Python documentation. 4. Add an an optional warning mode to the parser that will inform users when the deprecated construct is used. In other words, all programs that will behave differently in the future must trigger warnings in this mode. Compile-time warnings are preferable to runtime warnings. The warning messages should steer people from the deprecated construct to the alternative construct. 5. There must be at least a one-year transition period between the release of the transitional version of Python and the release of the backwards incompatible version. Users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one. Local Variables: mode: indented-text indent-tabs-mode: nil End:

2 1

Setup changes are checked in
by Fred L. Drake, Jr. 26 Oct '00

26 Oct '00

I've checked in the changes to the handling of the Modules/Setup file as we've discussed here. - Setup.in is now Setup.dist - Setup is created by configure - README and other instructions, comments, and documentation has been updated to reflect these changes -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs Team Member

1 0

Re: [Bug #117070] README instructions for configuring Setup are not helpful
by Fred L. Drake, Jr. 26 Oct '00

26 Oct '00

[Moved over from a discussion in the bugs list; this relates to bug: http://sourceforge.net/bugs/?func=detailbug&bug_id=117070&group_id=5470 Please be sure to CC: Jon on all replies.] Jon Ribbens writes: > Why the Setup.in/Setup thing at all? Just copying Setup.in to Setup without > changes is unexpected enough to warrant mentioning in a paragraph of its > own, completely explicitly. The '.in' suffix is usually used for files which > autoconf is going to use to create a new file from - you cannot usually > simply copy the file yourself. An experienced admin installing Python is > more likely to believe the README is wrong than what it tells them to do > is correct. Why does the Setup.in file exist in the first place? Surely it > should be named 'Setup.dist' (and an identical file 'Setup' exist right from > the start). Ok, here's the plan: Change Setup.in to Setup.dist, and provide a copy as Setup. Since this doesn't help if the source and build directories differ, configure.in can be modified to create Setup if (and only if!) it doesn't exist, by copying it from $srcdir/Modules/. I have the changes to configure.in, configure, Setup*, and Modules/Makefile.pre.in ready, but I still need to update the instructions in the README & possibly elsewhere. Does this sound agreeable? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs Team Member

4 6