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
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
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):
>
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/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 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
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
>
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
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.
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
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/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
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, "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
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, 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
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 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
[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 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
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
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:
> 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
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:
> 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
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
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, 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 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.
__
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
장혜식 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
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
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
33 matches
Mail list logo
