[Python-Dev] Bug tracker reviews

As promised, here are five bug reviews with recommendations. If they help [ 1112812 ] Patch for Lib/bsddb/__init__.py to work with modulefinder get reviewed, then that'd be great. Otherwise I'll just

Re: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

> I had hoped for the core of p3k to be built for scratch [...] Stop right there. I used to think that was a good idea too, and was hoping to do exactly that (after retirement :). However, the more I think about it, the more I believe it would be throwing away too much valuable work. Please read

RE: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

Raymond> I had hoped for the core of p3k to be built for scratch ... Then we should just create a new CVS module for it (or go whole hog and try a new revision control system altogether - svn, darcs, arch, whatever). Skip ___ Python-Dev mailing lis

RE: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

Neal Norwitz > I thought about making a p3k branch in CVS I had hoped for the core of p3k to be built for scratch so that even the most pervasive and fundamental implementation choices would be open for discussion: * Possibly write in C++. * Possibly replace bytecode with Forth style threaded co

Re: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

Neal Norwitz wrote: On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote: [SNIP] Any ideas how we could start to realize some benefits of Py3.0 before it arrives? I'm not sure if this is worth it, if it's premature, or if there are other ways to acheive the goal of easin

Re: [Python-Dev] Should Python's library modules be written to help the freeze tools?

On Jan 30, 2005, at 5:50 PM, Martin v. Löwis wrote: Tony Meyer wrote: The main question (to steal Thomas's words) is whether the library modules should be written to help the freeze tools - if the answer is 'yes', then I'll submit the above as a patch for 2.5. The answer to this question certa

RE: [Python-Dev] Should Python's library modules be written to help the freeze tools?

[Tony Meyer] > The main question (to steal Thomas's words) is whether the > library modules should be written to help the freeze tools > - if the answer is 'yes', then I'll submit the above as a > patch for 2.5. [Martin v. Löwis] > The answer to this question certainly is "yes, if possible". In t

Re: [Python-Dev] Should Python's library modules be written to help the freeze tools?

Tony Meyer wrote: The main question (to steal Thomas's words) is whether the library modules should be written to help the freeze tools - if the answer is 'yes', then I'll submit the above as a patch for 2.5. The answer to this question certainly is "yes, if possible". In this specific case, I wond

[Python-Dev] Should Python's library modules be written to help the freeze tools?

The Python 2.4 Lib/bsddb/__init__.py contains this: """ # for backwards compatibility with python versions older than 2.3, the # iterator interface is dynamically defined and added using a mixin # class. old python can't tokenize it due to the yield keyword. if sys.version >= '2.3': exec """

Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > This is what I mean about the patch taking on a life of its own. It's > an optimization patch that slows down METH_O and METH_NOARGS. It's a > incremental change that throws away backwards compatibility. It's a

Re: [Python-Dev] Speed up function calls

On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > I agree that METH_O and METH_NOARGS are near > > optimal wrt to performance. But if we could have one METH_UNPACKED > > instead of 3 METH_*, I think that would be a win. > . . . > > Sorry, I meant eliminated w/3.

Re: [Python-Dev] Improving the Python Memory Allocator

Evan Jones wrote: Sure. This should be done even for patches which should absolutely not be committed? Difficult question. I think the answer goes like this: "Patches that should absolutely not be committed should not be published at all". There are different shades of gray, of course - but people