Mailman 3 October 2001 - Python-Dev

Re: [Python-Dev] Fixing send()
by Anthony Baxter 25 Oct '01

25 Oct '01

>>> Guido van Rossum wrote > I think Anthony is going to add this to the 2.1.2 bugfix release as > well -- with the same argument for breaking the feature freeze. That's correct. I think it's the appropriate way forward. I'm pretty sure the "goals for patch selection" had an implicit "except where footnote 1 applies" in there :) I'd be curious to know if anyone disagrees violently with this... Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

2 1

weird gdb/python/gtk/pango interaction?
by Martin v. Loewis 25 Oct '01

25 Oct '01

> Any idea what's going on? When you see that a program behaves differently in gdb than it does on the shell, the most likely cause is that gdb starts another shell when running the program, I believe essentially through system("$SHELL -c command") (see gdb documentation and source for details). For example, some of the $HOME/.something files may set PYTHONPATH to some interesting value. If you see that a Python program behaves differently from an "equivalent" C code, well, the most likely cause is that the programs are not equivalent. One obvious (to me) difference is that one calls set_title, when the other doesn't. Regards, Martin

1 0

Re: [Python-Dev] Fixing send()
by Anthony Baxter 25 Oct '01

25 Oct '01

>>> Guido van Rossum wrote > Instead, we decided to fix the standard library to always check the > return value of send(). Can you help? (If you check in a fix to the > 2.1 maintenance branch, you can mark it as "propagate to trunk please".) Will do - I plan to check in a bunch of fixes tomorrow morning. (continuing gdb hell today). One to consider is the status of 'socket.py' - patched, or not patched...? -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

4 5

[development doc updates]
by Fred L. Drake 25 Oct '01

25 Oct '01

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Experimental stylesheet changes -- code is now presented using proportional fonts (mostly since Guido really dislikes Courier). Please send comments on this change to me at python-docs(a)python.org.

1 0

suggestion for PEP 101
by Sjoerd Mullender 25 Oct '01

25 Oct '01

I noticed that the first step in creating a release is ___ Do a CVS update with the -A flag, e.g. % cvs update -A I would suggest adding the -d and -P flags to this command (so cvs update -APd). The -d flag says to create directories that are in the repository but not in the checked-out version (handy for new directories), and the -P flag says to delete (prune) empty directories from the checked-out version (handy for directories that have become empty because all files were deleted). -- Sjoerd Mullender <sjoerd.mullender(a)oratrix.com>

2 1

Re: [Python-Dev] Fixing send()
by Guido van Rossum 25 Oct '01

25 Oct '01

[Jeremy] > Can you offer a brief explanation of why we're doing this after all? > I thought we concluded yesterday that we would fix this library. > (That's what the last message before this one said.) Fixing the library would mean adding a loop like this to each application that uses send and currently doesn't check the return value: < sock.send(data) --- > while data: > n = sock.send(data) > data = data[n:] I find this more attractive: < sock.send(data) --- > sock.sendall(data) --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Python-Dev] Fixing send()
by Anthony Baxter 24 Oct '01

24 Oct '01

>>> Guido van Rossum wrote > I've got a possible patch for the send() problem. I'd like review of > the patch and the related issues before I apply it. I'd also like > more guidance regarding the suitability of this patch for the 2.1.2 > bugfix release. (It fixes a real bug, but can sometime lead to > different behavior, and adds a new interpretation of the absence of an > optional argument, which can be considered a feature.) It's a tough decision, because this really _is_ the cleaner solution, but it does stand a slight chance of breaking code, and it's also something that can be worked around in the std library. At the moment I'm planning to just fix the std library modules instead - as these are definitely broken. The added functionality of python's send() is very useful, but it's a feature, not a bug :) Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

2 1

Re: patchlevel.h
by Martin v. Loewis 24 Oct '01

24 Oct '01

> Maybe I should start using the release branch for Mac releases after you are > done with it for the Unix/Windows release. As there is an r22b1 tag to point > to the exact revision used for the release there should be no adverse > consequences. What do you think? As before, I think there should be only a single 2.2b1 release. If you need to provide binaries, use what was released in the 2.2b1 source distribution (which is *not* the Unix release, it is the source distribution). What do your users lose if they have to get 2.2b1 as-is (ie. without further patches)? It may have bugs, sure - but so does the 2.2b1 release for everybody else. There will be a 2.2b2 release, so whatever you commit now will appear in 2.2b2. I think these release schedules are there for a purpose. Regards, Martin

1 0

Re: patchlevel.h
by Jack Jansen 24 Oct '01

24 Oct '01

> Jack, you can't do this on the trunk. If you *have* to have a > different patch level, please use a branch! Well, apparently I _can_, I just did. Maybe I _shouldn't_.... :-) I undid it this morning, this mod wasn't supposed to escape from my machine. Maybe I should start using the release branch for Mac releases after you are done with it for the Unix/Windows release. As there is an r22b1 tag to point to the exact revision used for the release there should be no adverse consequences. What do you think? -- 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

4 5

"Leaving Sourceforge" article on Advogato
by akuchlin＠mems-exchange.org 24 Oct '01

24 Oct '01

There's a discussion of SourceForge alternatives at http://www.advogato.org/article/357.html, and in a comment someone mentions that there's an XML export of the data in the tracker. Unfortunately I can't get it to work following his instructions, but perhaps someone else can experiment with it more than I can. --amk

6 5