Re: [Python-Dev] ast-objects branch created

On 11/30/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I created > > http://svn.python.org/projects/python/branches/ast-objects/ > > You can convert your repository to that branch with > > svn switch svn+ssh://[EMAIL PROTECTED]/python/branches/ast-objects > If you would rather do a separate c

Re: [Python-Dev] ast-objects branch created

On 11/30/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > The bigger chunk of necessary changes is in using these, starting > with ast.c. I got a few more files to compile. The following files (all under Python/) need some loving care and are looking for a kind soul to adopt them: ast.c, c

Re: [Python-Dev] Memory management in the AST parser & compiler

Sure. If they're immutable sharing is fine, but you end up making a copy anyway if you want to make changes, right? Jeremy On 11/30/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > Jeremy Hylton wrote: > > > I still think passing copies is better than sharing live > > objects between Python and C, >

Re: [Python-Dev] Memory management in the AST parser & compiler

Jeremy Hylton wrote: > I still think passing copies is better than sharing live > objects between Python and C, Even if the objects are immutable? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a

Re: [Python-Dev] Memory management in the AST parser & compiler

On 11/30/05, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On 11/30/05, Thomas Lee <[EMAIL PROTECTED]> wrote: > > > > Quick semi-related question: where are the marshal_* functions called? > > They're all static in Python-ast.c and don't seem to be actually called > > anywhere. Can we ditch them? > > I

Re: [Python-Dev] Memory management in the AST parser & compiler

Nick Coghlan wrote: > The ast C structs are already auto-generated by a Python script (asdl_c.py, to > be precise). The trick is to make that script generate full PyObjects rather > than the simple C structures that it generates now. See the ast-object branch. > The second step is to then m

[Python-Dev] ast-objects branch created

I created http://svn.python.org/projects/python/branches/ast-objects/ You can convert your repository to that branch with svn switch svn+ssh://[EMAIL PROTECTED]/python/branches/ast-objects in the toplevel directory. In particular, this features http://svn.python.org/projects/python/branches/as

[Python-Dev] Python bug day this Sunday

Let's have a Python bug day this Sunday. One goal might be to assess bugs and patches, and make a list of ones we can work on at the Python core sprint at PyCon . Meeting on IRC: #python-dev on irc.freenode.net Date: Sunday, December 4t

[Python-Dev] Standalone email package in the sandbox

Unless there are any objections, I'd like to create a space in the sandbox for the standalone email package miscellany. This currently lives in the mimelib project's hidden CVS on SF, but that seems pretty silly. Basically I'm just going to add the test script, setup.py, generated html docs and

Re: [Python-Dev] Memory management in the AST parser & compiler

Neal Norwitz <[EMAIL PROTECTED]> wrote: > If everything is a PyObject, wouldn't [the marshal functions] be > redundant? You could be right. Spending time to kept them working is probably wasted effort. Neil ___ Python-Dev mailing list Python-Dev@pyt

Re: [Python-Dev] Short-circuiting iterators

On Wed, 2005-11-30 at 14:36 -0500, Edward Loper wrote: > There's no need to change the iterator protocol for your example use > case; you could just define a simple iterator-wrapper: Good point. Perhaps it would be a useful addition to the itertools module then? itertools.interruptable(

Re: [Python-Dev] something is wrong with test___all__

Guido van Rossum wrote: > 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. I've created a tracker item at www.python.org/sf/1370322. Reinhold -- Mail address is perfectly valid!

Re: [Python-Dev] Short-circuiting iterators

> I had an idea this morning for a simple extension to Python's iterator > protocol that would allow the user to force an iterator to raise > StopIteration on the next call to next(). My thought was to add a new > method to iterators called stop(). There's no need to change the iterator protocol

Re: [Python-Dev] Short-circuiting iterators

On Wed, 2005-11-30 at 10:57 -0800, Alex Martelli wrote: > PEP 342, already accepted and found at > http://python.org/peps/pep-0342.html , covers related functionality > (as well as many other points). Thanks Alex, I'll take another look at that PEP. The first time I tried to read it my brain star

Re: [Python-Dev] Short-circuiting iterators

On 11/30/05, Matthew F. Barnes <[EMAIL PROTECTED]> wrote: ... > I'm curious if anything like this has been proposed in the past. If so, > could someone kindly point me to any relevant mailing list threads? PEP 342, already accepted and found at http://python.org/peps/pep-0342.html , covers rel

Re: [Python-Dev] Memory management in the AST parser & compiler

On 11/30/05, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > Thomas Lee <[EMAIL PROTECTED]> wrote: > > Quick semi-related question: where are the marshal_* functions called? > > They're all static in Python-ast.c and don't seem to be actually called > > anywhere. Can we ditch them? > > They are inten

[Python-Dev] Short-circuiting iterators

Hello, I've not had much luck in searching for a discussion on this in the Python-Dev archives, so bear with me. I had an idea this morning for a simple extension to Python's iterator protocol that would allow the user to force an iterator to raise StopIteration on the next call to next(). My th

Re: [Python-Dev] Memory management in the AST parser & compiler

Thomas Lee <[EMAIL PROTECTED]> wrote: > Quick semi-related question: where are the marshal_* functions called? > They're all static in Python-ast.c and don't seem to be actually called > anywhere. Can we ditch them? They are intended to be used to make the AST available to Python code. It would

Re: [Python-Dev] Memory management in the AST parser & compiler

On 11/30/05, Thomas Lee <[EMAIL PROTECTED]> wrote: > > Quick semi-related question: where are the marshal_* functions called? > They're all static in Python-ast.c and don't seem to be actually called > anywhere. Can we ditch them? I *think* they are not necessary. My guess is that they were there

[Python-Dev] Proposed additional keyword argument in logging calls

> I couldn't think of a good reason why it should be possible to overwrite these > values with values from a user-supplied dictionary, other than to spoof log > entries in some way. The intention is to stop a user accidentally overwriting > one of the above attributes. This makes sense, but is it

Re: [Python-Dev] Proposed additional keyword argument in lo gging calls

Vinay Sajip <[EMAIL PROTECTED]> writes: > The existing fields which could be overwritten are ones which have been > computed > by the logging package itself: > > nameName of the logger > levelno Numeric logging level for the message (DEBUG, INFO, > WARNING, ERR

Re: [Python-Dev] Memory management in the AST parser & compiler

On Wed, Nov 30, 2005 at 07:42:20PM +1000, Nick Coghlan wrote: > The second step is to then modify ast.c to use the new structures. A branch > probably wouldn't help much with initial development (this is a "break the > world, check in when stuff compiles again" kind of change, which is hard to >

Re: [Python-Dev] Memory management in the AST parser & compiler

Nick Coghlan wrote: >Greg Ewing wrote: > > >>Neal Norwitz wrote: >> >> >> >>>I'm mostly convinced that using PyObjects would be a good thing. >>>However, making the change isn't free as all the types need to be >>>created and this is likely quite a bit of code. >>> >>> >>Since they're

Re: [Python-Dev] Memory management in the AST parser & compiler

Greg Ewing <[EMAIL PROTECTED]> writes: > Guido van Rossum wrote: > >>>To me, that's an argument in favour of always generating >>>a .pyc, even for scripts. >> >> I'm not sure I follow the connection. > > You were saying that if the parser and compiler were > slow, it would slow down single-file s

Re: [Python-Dev] Metaclass problem in the "with" statement semantics in PEP 343

Edward Loper wrote: > Otherwise, it seems like people might write code that relies on the > current behavior, which will then break if we eg turn __context__ into > a slot. (It sounds like you want to reserve the right to change this.) > Well, of course, people may rely on the current behavio

Re: [Python-Dev] Memory management in the AST parser & compiler

Greg Ewing wrote: > Neal Norwitz wrote: > >> I'm mostly convinced that using PyObjects would be a good thing. >> However, making the change isn't free as all the types need to be >> created and this is likely quite a bit of code. > > Since they're all so similar, perhaps they could be > auto-gen