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

On 11/29/05, Vinay Sajip <[EMAIL PROTECTED]> wrote: > But thinking about "Errors should never pass silently", I propose that an > exception (KeyError seems most appropriate, though here it would be because a > key was present rather than absent) be thrown if one of the above attribute > names is su

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

Vinay> I couldn't think of a good reason why it should be possible to Vinay> overwrite these values with values from a user-supplied Vinay> dictionary, other than to spoof log entries in some way. If the user doesn't need those values and can provide cheap substitutes, perhaps their

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

Guido van Rossum python.org> writes: > This looks like a good clean solution to me. I agree with Paul Moore's > suggestion that if extra_info is not None you should just go ahead and > use it as a dict and let the errors propagate. OK. > What's the rationale for not letting it override existing

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

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-generated by a fairly simple scrip

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

Neal Norwitz wrote: > On 11/28/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > he assumed that FunctionDef would *consume* the references > > being passed (whether it is successful or not). > > I keep resisting this solution, though I'm not sure why. One reason for not liking it is that i

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

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 scripts that didn't have a .pyc (or at least that's w

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

Nick Coghlan wrote: > Declaring that none of the AST node creation methods steal references would > be > consistent with most of the existing C API (e.g. PySequence_SetItem, > PySequence_Tuple, PySequence_List), Agreed, although the rest of your proposal (while admirably cunning) requires that

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

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. I addressed the memory leak by stipulating that FunctionDef should steal references to its ar

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

On 11/29/05, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On 11/29/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > > > When working on the CST->AST parser, there were only a few things I found to > > be seriously painful about the memory management: > > > >1. Remembering which free_* variant to ca

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

On 11/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 11/28/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > > [...] My mental model > > of parsing & compiling in the presence of a parse tree > > is like this: > > > >[source] -> scanner -> [tokens] > > -> parser -> [AST] -> code_generat

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

Michael Chermside wrote: >> Right now, we say that there's one rule for all *normal* attributes >> and >> methods, and a slightly different rule for all double-underbar >> methods. Guido responded: > But it's not normal vs. __xyzzy__. A specific set of slots (including > next, but excluding thin

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

On 11/28/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > 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 (corre

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

On 11/29/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > When working on the CST->AST parser, there were only a few things I found to > be seriously painful about the memory management: > >1. Remembering which free_* variant to call for AST nodes >2. Remembering which asdl_seq_*_free varian

Re: [Python-Dev] CVS repository mostly closed now

You can also remove CVS write privileges from project members. It's a good way to prevent accidental checkins. -- David Goodger signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@pyt

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

On 11/28/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > [...] My mental model > of parsing & compiling in the presence of a parse tree > is like this: > >[source] -> scanner -> [tokens] > -> parser -> [AST] -> code_generator -> [code] > > The fact that there still seems to be another kind of

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

On 11/29/05, Michael Chermside <[EMAIL PROTECTED]> wrote: > Right now, we say that there's one rule for all *normal* attributes and > methods, and a slightly different rule for all double-underbar methods. But it's not normal vs. __xyzzy__. A specific set of slots (including next, but excluding th

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

On 11/29/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > The bit that more concerns me is the behavioural discrepancy that comes from > having a piece of syntax that looks in the instance dictionary. No other > Python syntax is affected by the instance attributes - if the object doesn't > have the ri

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

Nick writes: > I think we need to fix the proposed semantics so that they access the slots > via the type, rather than directly through the instance. Otherwise the slots > for the with statement will behave strangely when compared to the slots for > other magic methods. Guido writes: > I can't mak

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

Neal Norwitz wrote: > 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

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

Jeremy Hylton wrote: > > Me neither. Adding yet another memory allocation scheme to Python's > > already staggering number of memory allocation strategies sounds like > > a bad idea. > > The reason this thread started was the complaint that reference > counting in the compiler is really difficult.

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

Guido van Rossum wrote: > On 11/28/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> I think we need to fix the proposed semantics so that they access the slots >> via the type, rather than directly through the instance. Otherwise the slots >> for the with statement will behave strangely when compared