Mailman 3 August 2004 - Python-Dev

2.4a3 release is September 2, SF tracker keywords
by Anthony Baxter Aug. 24, 2004

Aug. 24, 2004

After consultations with the relevant folks, I want to get 2.4a3 out the door on September 2nd. I'll be following up to this email with a list of things that are still pending. This _should_ be the final alpha release. After that, the first beta. I'm wondering if there's a way I can mark bugs and patches that should be in before b1. It appears from SF's tracker that the only way I'm going to be able to do that is by putting keywords in the summary. I'm considering doing this. Rather than rip off the entirety of the mozilla's insane list of keywords, here's the ones I care about: - should be in before b1 (changes functionality) - should be in before final - regression since 2.3 Does anyone else have any others that they think are useful? I'd probably go with something like [beta], [final], [regr] in the summary. The other alternative is to make a bunch of new groups - this doesn't excite me at all, because a) I can't do it, and b) we can't get rid of them once they're in. -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

11 14

RE: [Python-Dev] Python icons
by Michael Chermside Aug. 24, 2004

Aug. 24, 2004

Kevin Gadd writes: > I'm not really worried about licensing... basically, I'd probably just want > to keep my copyright on the actual vector art. I'm not terribly concerned > about anything else, since they are based on the original python icons. I > don't know much about how licensing artwork for open source projects works, > so if you or someone else can let me know what steps would be necessary to > make it possible for these icons to be used, I'd be glad to help. While I can't speak authoritatively, I have an idea of what folks would want. My guess is that the PSF (Python Software Foundation) would want the right to use the icons any way they deem necessary for promoting Python. I'm sure they wouldn't mind your keeping the copyright, just so long as the PSF can authorize people to use them (eg: in the installer). A simple note to the PSF stating that you own the copyright and that you're willing to allow the use MIGHT be sufficient, unfortunately it would take a real lawyer to say for sure what's sufficient. In the past other Icons have come with a request by the artist that they be credited... and I'm sure no one would begrudge you a mention in Python's credits (see [1]). And let me add my own thanks! It's nice to have good artwork -- I'm sure there are a few other places you could help also. -- Michael Chermside (speaking only for myself, of course) [1] http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Misc/ACKS?view…

2 1

RE: [Python-Dev] Simple coroutines?
by Moore, Paul Aug. 24, 2004

Aug. 24, 2004

From: Greg Ewing > There will be a new statement: > > suspend > [...] > > do another_coop() > > would be equivalent to > > co = another_coop() > while co.run(): > suspend I'm not sure I see the difference between suspend/do and yield True/for _ in co: pass, other than possibly that co-operators and generators are intended to be mixed (which strikes me as implausible). I'm likely to be missing something here, but I don't follow the semantics you are suggesting. If there was a simple, realistic use case for this, it might help clarify the semantics. (For extra credit, mix co-operators and generators in your use case so that the semantics of interaction are shown as well :-)) Paul. __________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __________________________________________________________________________

1 0

RE: [Python-Dev] SF Priorities, 2.4 release
by Batista, Facundo Aug. 24, 2004

Aug. 24, 2004

[Anthony Baxter] #- Priority 9: #- - MUST be done before the next release (whether it's a3, b1, b2, #- or whatever) #- Priority 8: #- - MUST be done before b1. It's a functionality change, and it's #- needed for 2.4. If it's not done before b1, it will have to wait #- until 2.5, whenever that might be. #- Priority 7: #- - SHOULD be done before 2.4 final. +1 . Facundo

1 0

problem with pymalloc on the BeOS port.
by François Revol Aug. 24, 2004

Aug. 24, 2004

Hi there, I'm updating the BeOS port of python to include the latest version in Zeta, the next incarnation of BeOS. I'm having some problem when enabling pymalloc: case $MAKEFLAGS in \ *-s*) LIBRARY_PATH=/boot/home/Python-2.3.4:%A/lib:/boot/home/config/ lib:/boot/beos/system/lib CC='gcc' LDSHARED='./Modules/ld_so_beos libpython2.3.so' OPT='-O' ./python -E ./setup.py -q build;; \ *) LIBRARY_PATH=/boot/home/Python-2.3.4:%A/lib:/boot/home/config/lib:/ boot/beos/system/lib CC='gcc' LDSHARED='./Modules/ld_so_beos libpython2.3.so' OPT='-O' ./python -E ./setup.py build;; \ esac running build running build_ext building 'struct' extension gcc -O -fno-strict-aliasing -I. -I/boot/home/Python-2.3.4/./Include -I/ boot/home/config/include -I/boot/home/Python-2.3.4/Include -I/boot/home /Python-2.3.4 -c /boot/home/Python-2.3.4/Modules/structmodule.c -o build/temp.beos-5.1-BePC-2.3/structmodule.o Debug memory block at address p=0x80010fb8: 0 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x80010fb8 are not all FORBIDDENBYTE (0xfb): at tail+0: 0xdb *** OUCH at tail+1: 0xdb *** OUCH at tail+2: 0xdb *** OUCH at tail+3: 0xdb *** OUCH The block was made by call #3688627195 to debug malloc/realloc. Fatal Python error: bad trailing pad byte indeed, there seem to be 4 deadblock marks between the forbidden ones, while the len is supposed to be null: python:dm 0x80010fb8-8 32 80010fb0 00000000 fbfbfbfb dbdbdbdb fbfbdbdb ................ 80010fc0 0100fbfb 507686ef 04000000 fbfbfbfb ......vP........ 80010fd0 8013cbc8 fbfbfbfb 44ee0100 ffed0100 ...........D.... Any clue ? François.

3 3

Python icons
by Kevin Gadd Aug. 24, 2004

Aug. 24, 2004

I was bored the other day so I played around with an image editor and redid most of the windows python icons. Image of most of the icons (I bet this is going to murder my bandwidth): http://luminance.org/py/screenshot.png I did the basic one in vector. Let me know what you guys think, I figure since they came out pretty decent that somebody might be able to make something of 'em! And, just to get in a bit of sucking up, thanks to all you devs for the great work you've done on the language. Keep it up! -- Kevin Gadd E-Mail <mailto:kevin@luminance.org> | Website <http://www.luminance.org/>

4 5

Missing peice of PEP 237 (int unification)
by Tim Peters Aug. 24, 2004

Aug. 24, 2004

We're still generating OverflowWarnings in CVS: >>> import warnings >>> warnings.filterwarnings("error", "", OverflowWarning) >>> import sys >>> sys.maxint + 1 Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: integer addition >>> The PEP says OverflowWarning was for "transition phase A": Here are the rules that guide warnings generated in situations that currently raise OverflowError. This applies to transition phase A. Phase A was done in 2.2. Phase B0 was done in 2.3, and 2.4 is supposed to be phase B1. The OverflowWarnings are still there, but should have gone away in 2.3 already. It would be a lot of fun to rip out the bletcherous code raising OverflowWarning, and finding the infinite loop that will then occur in the test suite (you think I'm kidding -- heh). One question the PEP doesn't answer: does PyExc_OverflowWarning vanish from the C API at the same time? Does OverflowWarning vanish from Python too? Or do we need to add a PendingDeprecationWarning for OverflowWarning in 2.4, a DeprecationWarning for OverflowWarning in 2.5, and finally nuke the silly bastard tin 2.6?

2 1

RE: [Python-Dev] Weekly Python Bug/Patch Summary
by Michael Chermside Aug. 24, 2004

Aug. 24, 2004

amk writes: > I disagree. I think there's a pool of volunteer labour in the Python > community that we aren't tapping yet. For example [...] Well, if there's ANY decent chance that you're right, then it's worth sending the email. So I'll enthustiastically back the idea of sending the bug/patch summary to c.l.py. -- Michael Chermside

2 1

RE: [Python-Dev] Weekly Python Bug/Patch Summary
by Michael Chermside Aug. 24, 2004

Aug. 24, 2004

Skip writes: > Any thoughts about posting this to c.l.py as well as python-dev? Maybe it > would encourage some more participation... I don't want to exercise a veto here or anything, but I don't think it would be helpful. The barrier to more participation isn't that people don't know there's work to be done. I suspect that anyone who was going to consider helping with development would either be scratching their own itch (ie, contributing a patch and wouldn't care about this report), or would already be reading python-dev (after all, it's not hard to qualify to receive it!). I worry that posting this to c.l.py would be unlikely to generate anything other than occasional bellyaching about how slow we are about addressing bug reports. What might be more helpful would be a call for volunteers. We could form a "patch reviewers" group that would review patches on SF. Or something. Actually, figuring out how to recruit volunteers is a difficult problem. But I'm not sure the weekly bug/patch summary is the solution. -- Michael Chermside

6 5

Re: [Python-Dev] #ifdeffery
by Ilya Sandler Aug. 23, 2004

Aug. 23, 2004

On Fri, 13 Aug 2004, Michael Hudson wrote: > "Raymond Hettinger" <python(a)rcn.com> writes: > > > P.S. Side rant: Also, in the last few months, the #ifdefs have > > multiplied. While I understand that some things like time stamping are > > worthwhile, the code is getting harder to read and maintain because of > > all this b.s. > > Is it really getting worse? > > I think there are two qualitatively different sorts of #ifdef mess: > feature ones, like the WITH_TSC I've recently been fiddling with > recently and portability ones. Actually, I have a suggestion regarding #ifdef WITH_TSC blocks in ceval.c Most of these blocks look like this: #ifdef WITH_TSC rdtscll(inst0); #endif where rdtscll() is defined in the beginning of ceval.c as follows #ifdef WITH_TSC ... #define rdtscll(var) ppc_getcounter(&var) ... #else /* this section is for linux/x86 */ ... #endif so why not to add a dummy rtdscll() macro to the else section of the above ifdef: #else /* this section is for linux/x86 */ #define rdtscll(var) #endif Then one can simply omit ifdef brackets for rdtscll invocations, removing about 20 ifdefs.... there are probably other places in the code where this trick could be used Does this make sense or am I missing something here? Ilya > The feature #ifdefs aren't (or shouldn't be) that much of a big deal. > Ideally, they are documented in Misc/SpecialBuilds.txt and depending > on whether they are defined or not, bits and pieces of code are or are > not included. > >

4 3