Neal Norwitz wrote:
> For those watching, Greg's and Martin's version were almost the same.
> However, Greg's version left in the memory leak, while Martin fixed it
> by letting the result fall through.
Actually, Greg said (correctly) that his version also fixes the
leak: he assumed that Function
On 11/28/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
> > Hope this helps explain a bit. Please speak up with how this can be
> > improved. Gotta run.
>
> I would rewrite it as
[code snipped]
For those watching, Greg's and Martin's version were almost the same.
Howeve
장혜식 wrote:
> There's a hacky trick to remove them:
> put rm -rf $CVSROOT/src into CVSROOT/loginfo
> and remove the line then and commit again. :)
Sure :-) SF makes a big fuss as to how good a service
this is: open source will never go away. I tend to
agree, somewhat. For historical reasons, it i
Brett Cannon wrote:
> Is there a specific reason you are leaving out the AST, Greg, or do
> you count that as part of the bytecode compiler
No, I consider it part of the parser. My mental model
of parsing & compiling in the presence of a parse tree
is like this:
[source] -> scanner -> [tokens
On Monday 28 November 2005 20:14, 장혜식 wrote:
> There's a hacky trick to remove them:
> put rm -rf $CVSROOT/src into CVSROOT/loginfo
> and remove the line then and commit again. :)
Wow, that is tricky! Glad it wasn't me who thought of this one. :-)
-Fred
--
Fred L. Drake, Jr.
__
On 11/28/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I guess I don't understand the AST compiler code enough to participate
> in this discussion.
I hope everyone while chime in here. This is important to improve and
learn from others.
Let me try to describe the current situation with a s
On 11/27/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I tried removing the CVS repository from SF; it turns
> out that this operation is not supported. Instead, it
> is only possible to remove it from the project page;
> pserver and ssh access remain indefinitely, as does
> viewcvs.
There's
On 11/28/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Here's a somewhat radical idea:
>
> Why not write the parser and bytecode compiler in Python?
>
> A .pyc could be bootstrapped from it and frozen into
> the executable.
>
Is there a specific reason you are leaving out the AST, Greg, or do
you co
Neal Norwitz wrote:
> Hope this helps explain a bit. Please speak up with how this can be
> improved. Gotta run.
I would rewrite it as
static PyObject*
ast_for_funcdef(struct compiling *c, const node *n)
{
/* funcdef: [decorators] 'def' NAME parameters ':' suite */
PyObject *name = NU
Here's a somewhat radical idea:
Why not write the parser and bytecode compiler in Python?
A .pyc could be bootstrapped from it and frozen into
the executable.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZeal
Neal Norwitz wrote:
> This is an entire function from Python/ast.c.
> Sequences do not know what type they hold, so there needs to be
> different dealloc functions to free them properly (asdl_*_seq_free()).
Well, that's one complication that would go away if
the nodes were PyObjects.
> The memo
Jeremy Hylton wrote:
> Almost every line of
> code can lead to an error exit. The code becomes quite cluttered when
> it uses reference counting.
I don't see why very many more error exits should become
possible just by introducing refcounting. Errors are possible
whenever you allocate something
Neal Norwitz wrote:
> On 11/25/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Can you move the call to codecs.register_error() out of test_callbacks()
>> and retry?
>
> It then leaks 3 refs on each call to test_callbacks().
This should be fixed now in r41555 and r41556.
Bye,
Walter Dörwal
On 11/28/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [Guido]
> > > Then I don't understand why there was discussion of alloca() earlier
> > > on -- surely the lifetime of a node should not be limited by the stack
> > > frame that allocated it?
>
> [Jeremy]
> > Actually this is a pretty good l
[Guido]
> > Then I don't understand why there was discussion of alloca() earlier
> > on -- surely the lifetime of a node should not be limited by the stack
> > frame that allocated it?
[Jeremy]
> Actually this is a pretty good limit, because all these data
> structures are temporaries used by the
On Mon, Nov 28, 2005 at 03:47:07PM -0500, Jeremy Hylton wrote:
> The reason this thread started was the complaint that reference
> counting in the compiler is really difficult.
I don't think that's exactly right. The problem is that the AST
compiler mixes its own memory management strategy with r
Jeremy Hylton wrote:
> The reason this thread started was the complaint that reference
> counting in the compiler is really difficult. Almost every line of
> code can lead to an error exit. The code becomes quite cluttered when
> it uses reference counting. Right now, the AST is created with
On 11/28/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > The code becomes quite cluttered when
> > it uses reference counting. Right now, the AST is created with
> > malloc/free, but that makes it hard to free the ast at the right time.
>
> Would fixing the code to add free() calls in all the
On 11/28/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 11/28/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 11/18/05, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> > > Perhaps we should use the memory management technique that the rest
> > > of Python uses: reference counting. I don't
On 11/28/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Perhaps the following compromise can be made: the PSF accepts patches
> > from reputable platform maintainers. (Of course, like all
> > contributions, they must be of high quality and not break anything,
> > etc
Guido van Rossum wrote:
> I don't recall why DOS support was removed (PEP 11 doesn't say)
The PEP was actually created after the removal, so you added (or
asked me to add) this entry:
Name: MS-DOS, MS-Windows 3.x
Unsupported in: Python 2.0
Code removed in: Python 2.
On 11/28/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/18/05, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> > Perhaps we should use the memory management technique that the rest
> > of Python uses: reference counting. I don't see why the AST
> > structures couldn't be PyObjects.
>
> Me n
Has this been handled yet? If not, perhaps showing the good and bad
bytecode here would help trigger someone's brain into understanding
the problem.
On 11/22/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Hi,
>
> on my machine, "make test" hangs at test_colorsys.
>
> Careful investigation sh
On 11/18/05, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Perhaps we should use the memory management technique that the rest
> of Python uses: reference counting. I don't see why the AST
> structures couldn't be PyObjects.
Me neither. Adding yet another memory allocation scheme to Python's
alre
On 11/22/05, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> On numerous occasions, requests have been made for the ability to easily add
> user-defined data to logging events. For example, a multi-threaded server
> application may want to output specific information to a particular server
> thread (e.g.
Is anyone interested in joining a Python bug day this Sunday?
A useful task might be to prepare for the python-core sprint at PyCon
by going through the bug and patch managers, and listing bugs/patches
that would be good candidates for working on at PyCon.
We'd meet in the usual location: #python
Guido van Rossum wrote:
> Perhaps the following compromise can be made: the PSF accepts patches
> from reputable platform maintainers. (Of course, like all
> contributions, they must be of high quality and not break anything,
> etc., before they are accepted.) If such patches cause problems with
>
On Monday 28 November, Guido van Rossum wrote:
> On 11/24/05, Duncan Grisby <[EMAIL PROTECTED]> wrote:
> > I have encountered a problem with the re module. I have a
> > multi-threaded program that does lots of regular expression searching,
> > with some relatively complex regular expressions. Occ
On 11/20/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > The local python community here in Sydney indicated that python.org is
> > only upset when groups port the source to 'obscure' systems and *don't*
> > submit patches... It is possible that I was misinformed.
>
On 11/24/05, Duncan Grisby <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I posted this to comp.lang.python, but got no response, so I thought I
> would consult the wise people here...
>
> I have encountered a problem with the re module. I have a
> multi-threaded program that does lots of regular expression
On 11/28/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Given the current semantics of PEP 343 and the following class:
>
>class null_context(object):
> def __context__(self):
> return self
> def __enter__(self):
> return self
> def __exit__(self, *exc_info):
>
OK, you've convinced me. But for backwards compatibility (until Python
3000), a new API should be designed. We can't change the old API in an
incompatible way. Please submit complete code + docs to SF. (If you
think this requires much design work, a PEP may be in order but I
think that given the ne
Given the current semantics of PEP 343 and the following class:
class null_context(object):
def __context__(self):
return self
def __enter__(self):
return self
def __exit__(self, *exc_info):
pass
Mistakenly writing:
with null_context:
# Oo
33 matches
Mail list logo
