RE: [Python-Dev] Please help complete the AST branch

> Perhaps interested parties should take up the discussion on > the compiler-sig. This isn't listed in the 'currently active' SIGs list on - is it still active, or will it now be? If so, perhaps it should be added to the list? By 'discussion on', do you mean via the wi

Re: [Python-Dev] Please help complete the AST branch

On Mon, 03 Jan 2005 18:02:52 -0800, Brett C. <[EMAIL PROTECTED]> wrote: > Plus there is the running tradition of sprinting on the AST branch at PyCon. > I > was planning on shedding my bug fixing drive at PyCon this year and sprinting > with (hopefully) Jeremy, Neal, Tim, and Neil on the AST bran

Re: [Python-Dev] Please help complete the AST branch

On Mon, Jan 03, 2005 at 06:02:52PM -0800, Brett C. wrote: > Although if someone can start sooner than by all means, go for it! > And obviously help would be great since it isn't a puny codebase > (4,000 lines so far for the CST->AST and AST->bytecode code). And obviously knowing a little more abou

Re: [Python-Dev] Please help complete the AST branch

Guido van Rossum wrote: The AST branch has been "nearly complete" for several Python versions now. The last time a serious effort was made was in May I believe, but it wasn't enough to merge the code back into 2.4, alas. It would be a real shame if this code was abandoned. [SNIP] So, I'm pleading.

[Python-Dev] Please help complete the AST branch

The AST branch has been "nearly complete" for several Python versions now. The last time a serious effort was made was in May I believe, but it wasn't enough to merge the code back into 2.4, alas. It would be a real shame if this code was abandoned. If we're going to make progress with things like

Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

[Bob Ippolito] > ... > What about for list objects that are big at some point, then > progressively shrink, but happen to stick around for a while? An > "event queue" that got clogged for some reason and then became stable? It's less plausible that we''re going to see a lot of these simultaneousl

RE: [Python-Dev] Out-of-date FAQs

Aahz wrote: > Yes. Until last July, the company I work for was still using 1.5.2. > Our current version is 2.2. I think that the FAQ should be usable for > anyone with a "reasonably current" version of Python, say at least two > major versions. IOW, answers should continue to work with 2.2 duri

Re: [Python-Dev] Out-of-date FAQs

On Tue, Jan 04, 2005, Delaney, Timothy C (Timothy) wrote: > > As a general rule, when an idiom has changed, do we want to state both > the 2.4 idiom as well as the 2.3 idiom? In the case of list.sort(), that > would mean having both: > > for key in sorted(dict.iterkeys()): > ...do what

Re: [Python-Dev] Small fix for windows.tex

Irmen de Jong wrote: The current cvs docs failed to build for me, because of a small misspelling in the windows.tex file. Here is a patch: Thanks, fixed. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/pyth

Re: [Python-Dev] Zipfile needs?

Scott David Daniels wrote: What other wish list things do people around here have for zipfile? I thought I'd collect input here and make a PEP. I was working on a project based around modifying zip files, and found that python just doesn't implement that part. I'd like to see the ability to re

[Python-Dev] Small fix for windows.tex

The current cvs docs failed to build for me, because of a small misspelling in the windows.tex file. Here is a patch: Index: Doc/ext/windows.tex === RCS file: /cvsroot/python/python/dist/src/Doc/ext/windows.tex,v retrieving revision 1.

[Python-Dev] Out-of-date FAQs

While grabbing the link to the copyright restrictions FAQ (for someone on python-list) I noticed a few out-of-date FAQ entries - specifically, "most stable version" and "Why doesn't list.sort() return the sorted list?". Bug reports have been submitted (and acted on - Raymond, you work too fast ;)

Re: [Python-Dev] Re: Zipfile needs?

Scott David Daniels wrote: I believe there is an issue actually building in the encryption/decryption in terms of redistribution. Submitters should not worry about this too much. The issue primarily exists in the U.S., and there are now (U.S.) official procedures to deal with them, and the PSF can

Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

On Jan 3, 2005, at 4:49 PM, Tim Peters wrote: [Tim Peters] Ya, I understood that. My conclusion was that Darwin's realloc() implementation isn't production-quality. So it goes. [Bob Ippolito] Whatever that means. Well, it means what it said. The C standard says nothing about performance metrics

Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

On Mon, Jan 03, 2005 at 03:55:19PM -0500, Bob Ippolito wrote: > >Note that, with respect to http://python.org/sf/1092502, the author > >of the (original) program was using the documented interface to a > >file object. It's _fileobject.read() that decides to ask for huge > >numbers of bytes from re

Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

[Tim Peters] >> Ya, I understood that. My conclusion was that Darwin's realloc() >> implementation isn't production-quality. So it goes. [Bob Ippolito] > Whatever that means. Well, it means what it said. The C standard says nothing about performance metrics of any kind, and a production-qualit

Re: [Python-Dev] Re: Zipfile needs?

Scott David Daniels wrote: Brett C. wrote: Scott David Daniels wrote: I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary motivation is that Project Gutenberg seems to be starting to use BZIP2 compression for some of its zips. What other wish list things do people around here have

Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

On Jan 2, 2005, at 11:16 PM, Tim Peters wrote: [Bob Ippolito] However, it is our (in the "I know you use Windows but I am not the only one that uses Mac OS X sense) problem so long as Darwin is a supported platform, because it is highly unlikely that Apple will backport any "fix" to the allocato

Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

On Jan 3, 2005, at 3:23 PM, bacchusrx wrote: On Thu, Jan 01, 1970 at 12:00:00AM +, Tim Peters wrote: Is there any known case where Python performs poorly on this OS, for this reason, other than the "pass giant numbers to recv() and then shrink the string because we didn't get anywhere near that

Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

On Thu, Jan 01, 1970 at 12:00:00AM +, Tim Peters wrote: > Is there any known case where Python performs poorly on this OS, for > this reason, other than the "pass giant numbers to recv() and then > shrink the string because we didn't get anywhere near that many bytes" > case? > > [...] > > I

[Python-Dev] Re: Zipfile needs?

Brett C. wrote: Scott David Daniels wrote: I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary motivation is that Project Gutenberg seems to be starting to use BZIP2 compression for some of its zips. What other wish list things do people around here have for zipfile? I thought I'd

Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

On Jan 3, 2005, at 11:15 AM, Guido van Rossum wrote: Coming late to this thread. I don't see the point of lying awake at night worrying about potential memory losses unless you've heard someone complain about it. As Tim has been trying to explain, here are plenty of other things in Python that we *

Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

Coming late to this thread. I don't see the point of lying awake at night worrying about potential memory losses unless you've heard someone complain about it. As Tim has been trying to explain, here are plenty of other things in Python that we *could* speed up if there was a need; since every spe

Re: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

On Jan 3, 2005, at 2:16 AM, Tim Peters wrote: [Bob Ippolito] ... Your expectation is not correct for Darwin's memory allocation scheme. It seems that Darwin creates allocations of immutable size. The only way ANY part of an allocation will ever be used by ANYTHING else is if free() is called with