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

[Nick Coghlan]

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 to the slots for
>> other magic methods.
> 
> Maybe it's because I'm just an old fart, but I can't make myself care
> about this. The code is broken. You get an error message. It even has
> the correct exception (TypeError). In this particular case the error
> message isn't that great -- well, the same is true in many other cases
> (like whenever the invocation is a method call from Python code).

I'm not particularly worried about the error message - as you say, it even has 
the right type. Or at least one of the two right types ;)

> That most built-in operations produce a different error message
> doesn't mean we have to make *all* built-in operations use the same
> approach. I fail to see the value of the consistency you're calling
> for.

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 right type, you're out of luck.

Sticking an __iter__ method on an instance doesn't turn an object into an 
iterator, but with the current semantics, doing the same thing with 
__context__ *will* give you a manageable context.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fredrik Lundh]

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.  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
> malloc/free, but that makes it hard to free the ast at the right time.
>  It would be fairly complex to convert the ast nodes to pyobjects.
> They're just simple discriminated unions right now.  If they were
> allocated from an arena, the entire arena could be freed when the
> compilation pass ends.

if you're using PyObject's for everything, you can use a list object as the
arena.  just append every "transient" value to the arena list, and a single
DECREF will get rid of it all.  if you want to copy something out from the
arena, just INCREF the object and it's yours.

(for performance reasons, it might be a good idea to add a _PyList_APPEND
helper that works like app1 but steals the value reference; e.g.

PyObject*
_PyList_APPEND(PyListObject *self, PyObject *v)
{
int n;
if (!v)
return v;
n = PyList_GET_SIZE(self);
if (n == INT_MAX) {
PyErr_SetString(PyExc_OverflowError,
"cannot add more objects to list");
return NULL;
}
if (list_resize(self, n+1) == -1)
return NULL;
PyList_SET_ITEM(self, n, v);
return v;
}

which can be called as

obj = _PyList_APPEND(c->arena, AST_Foobar_New(...));
if (!obj)
return NULL;





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 were almost the same. 
> However, Greg's version left in the memory leak, while Martin fixed it
> by letting the result fall through.  Martin added some helpful rules
> about dealing with the memory.  Martin also gets bonus points for
> talking about developing a checker. :-)
> 
> In both cases, their modified code is similar to the existing AST
> code, but all deallocation is done with Py_[X]DECREFs rather than a
> type specific deallocator.  Definitely nicer than the current
> situation.  It's also the same as the rest of the python code.

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 variant to call for ASDL sequences (it 
was worse when the variant I wanted didn't exist, since this was done with 
functions rather than preprocessor macros)
   3. Remembering to transpose free_* and *_free between freeing a single node 
and freeing a sequence.
   4. Remembering whether or not a given cleanup function could cope with 
NULL's or not
   5. The fact that there wasn't a consistent "goto error" exception-alike 
mechanism in use

(I had a Spanish Inquisition-esque experience writing that list ;)

Simply switching to PyObjects would solve the first four problems: everything 
becomes a Py_XDECREF.

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), and has nice properties if we handle AST 
nodes as borrowed references from a PyList used as the arena, as Fredrik 
suggested.

If the top level function refrains from putting the top level node in the 
arena, then it will all "just work" - any objects will be deleted only if both 
the PyList arena AND the top-level node object are DECREF'ed. The top-level 
function only has to obey two simple rules:
   1. Always DECREF the arena list
   2. On success, INCREF the top-level node BEFORE DECREF'ing the arena list 
(otherwise Step 1 kills everything. . .)

To make the code a little more self-documenting, Fredrik's _PyList_APPEND 
could be called "new_ast_node" and accept the compiling struct directly:

PyObject*
new_ast_node(struct compiling *c, PyObject *ast_node)
{
 int n;
 if (!ast_node)
 return ast_node;
 idx = PyList_GET_SIZE(c->arena);
 if (idx == INT_MAX) {
 PyErr_SetString(PyExc_OverflowError,
 "cannot add more objects to arena");
 return NULL;
 }
 if (list_resize(c->arena, idx+1) == -1)
 return NULL;
 PyList_SET_ITEM(c->arena, idx, ast_node);
 return ast_node;
}

We'd also need to modify the helper macro for identifiers:

#define NEW_IDENTIFER(c, n) \
   new_ast_node(c, PyString_InternFromString(STR(n)))

Then the function is only borrowing the arena's reference, and doesn't need to 
decref anything:

static PyObject*
ast_for_funcdef(struct compiling *c, const node *n)
{
  /* funcdef: [decorators] 'def' NAME parameters ':' suite */
  PyObject *name = NULL;
  PyObject *args = NULL;
  PyObject *body = NULL;
  PyObject *decorator_seq = NULL;
  int name_i;

  REQ(n, funcdef);

  if (NCH(n) == 6) { /* decorators are present */
decorator_seq = ast_for_decorators(c, CHILD(n, 0));
if (!decorator_seq)
return NULL;
name_i = 2;
  }
  else {
name_i = 1;
  }

  name = NEW_IDENTIFIER(c, CHILD(n, name_i));
  if (!name)
return NULL;
  else if (!strcmp(STR(CHILD(n, name_i)), "None")) {
ast_error(CHILD(n, name_i), "assignment to None");
 return NULL;
  }
  args = ast_for_arguments(c, CHILD(n, name_i + 1));
  if (!args)
 return NULL;
  body = ast_for_suite(c, CHILD(n, name_i + 3));
  if (!body)
 return NULL;

  return new_ast_node(\
FunctionDef(name, args, body, decorator_seq, LINENO(n)));
}

No need for a checker, because there isn't anything special to do at the call 
sites: each AST node can take care of putting *itself* in the arena.

And as the identifier example shows, this even works for the non-AST leaf 
nodes that are some other kind of PyObject.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/o

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

[Michael Chermside]

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 make myself care
> about this. The code is broken. You get an error message.

Nick writes:
> 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 right type, you're out of luck.
>
> Sticking an __iter__ method on an instance doesn't turn an object into an
> iterator, but with the current semantics, doing the same thing with
> __context__ *will* give you a manageable context.

If I'm understanding the situation here correctly, I'd like to chime in
on Nick's side. I'm unconcerned about the bit of code that uses or misuses
Context objects... I'm more concerned about the bit of the manual that
describes (in simple words that "fit your brain") how attribute/method
resolution works in Python.

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.
(I'd summarize the rules here, but they're just sufficiently complex that
I'm sure I'd make a mistake and wind up having people correct my mistake.
Suffice to say that the difference between normal and double-underbar
lookup has to do with checking (or not checking) the instance dictionary.)

With the current state of the code, we'd need to say that there's one
rule for all *normal* attributes and a slightly different rule for all
double-underbar methods except for __context__ which is just like a normal
attribute. That feels too big for my brain -- what on earth is so special
about __context__ that it has to be different from all other
double-underbar methods? If it were __init__ that had to be an exception,
I'd understand, but __context__?

-- Michael Chermside

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 right type, you're out of luck.

I'm not sure I buy that. Surely there are plenty of other places that
call PyObject_GetAttr(). Classic classes still let you put an __add__
attribute in the instance dict to make it addable (though admittedly
this is a weak argument since it'll go away in Py3k).

> Sticking an __iter__ method on an instance doesn't turn an object into an
> iterator, but with the current semantics, doing the same thing with
> __context__ *will* give you a manageable context.

This is all a very gray area. Before Python 2.2 most of the built-in
operations *did* call PyObject_GetAttr(). I added the slots mostly as
a speed-up, and the change in semantics was a side-effect of that.

And I'm still not sure why you care -- apart from the error case, it's
not going to affect anybody's code -- you should never use __xyzzy__
names except as documented since their undocumented use can change.
(So yes I'm keeping the door open for turning __context__ into a slot
later.)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 things like __doc__) get special treatment. The
rest don't. All I'm saying is that I don't care to give __context__
this special treatment.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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
> parse tree in between the scanner and the AST generator
> is an oddity which I hope will eventually disappear.

Have a look at http://python.org/sf/1337696 -- a reimplementation of
pgen in Python that I did for Elemental and am contributing to the
PSF. It customizes the tree generation callback so as to let you
produce an style of AST you like.

> > I know
> > Guido has said he doesn't like punishing the performance of small
> > scripts in the name of large-scale apps
>
> To me, that's an argument in favour of always generating
> a .pyc, even for scripts.

I'm not sure I follow the connection. But I wouldn't mind if someone
contributed code that did this. :)

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[David Goodger]

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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Neal Norwitz]

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 variant to call for ASDL sequences (it
> was worse when the variant I wanted didn't exist, since this was done with
> functions rather than preprocessor macros)
>3. Remembering to transpose free_* and *_free between freeing a single node
> and freeing a sequence.
>4. Remembering whether or not a given cleanup function could cope with
> NULL's or not
>5. The fact that there wasn't a consistent "goto error" exception-alike
> mechanism in use
>
> (I had a Spanish Inquisition-esque experience writing that list ;)

:-)  I agree all those are existing issues.  #3 could be easily fixed.
 #4 I think all cleanup functions can deal with NULLs now.  #5
probably ought to be fixed in favor of using gotos.

> Simply switching to PyObjects would solve the first four problems: everything
> becomes a Py_XDECREF.

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.  I'd like to hear what
Jeremy thinks about this.

Is anyone interested in creating a patch along these lines (even a
partial patch) to see the benefits?

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Neal Norwitz]

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 (correctly) that his version also fixes the
> leak: he assumed that FunctionDef would *consume* the references
> being passed (whether it is successful or not).

Ah right, I forgot about that.  Thanks for correcting me (sorry Greg).
 Jeremy and I had talked about this before.  I keep resisting this
solution, though I'm not sure why.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Edward Loper]

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 things like __doc__) get special treatment. The
> rest don't. All I'm saying is that I don't care to give __context__
> this special treatment.

Perhaps we should officially document that the effect on special 
methods of overriding a class attribute with an instance attribute is 
undefined, for some given set of attributes?  (I would say all 
double-underbar methods, but it sounds like the list needs to also 
include next().)

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 behavior anyway, but 
at least they'll have been warned. :)

-Edward

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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_generator -> [code]
> >
> > The fact that there still seems to be another kind of
> > parse tree in between the scanner and the AST generator
> > is an oddity which I hope will eventually disappear.
>
> Have a look at http://python.org/sf/1337696 -- a reimplementation of
> pgen in Python that I did for Elemental and am contributing to the
> PSF. It customizes the tree generation callback so as to let you
> produce an style of AST you like.
>
> > > I know
> > > Guido has said he doesn't like punishing the performance of small
> > > scripts in the name of large-scale apps
> >
> > To me, that's an argument in favour of always generating
> > a .pyc, even for scripts.
>
> I'm not sure I follow the connection.

Greg was proposing having parser, AST, and bytecode compilation all be
written in Python and frozen into the executable instead of it being
all C code.  I said that would be slower and would punish single file
scripts that don't get a .pyc generated for them because they would
need to have the file compiled every execution.  Greg said that is
just a good argument for  having *any* file, imported or passed in on
the command line, to have a .pyc generated when possible.

> But I wouldn't mind if someone
> contributed code that did this. :)
>

=)  Shouldn't be that complicated (but I don't have time for it right
now so it isn't dead simple either  =).

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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 call for AST nodes
> >2. Remembering which asdl_seq_*_free variant to call for ASDL sequences 
> > (it
> > was worse when the variant I wanted didn't exist, since this was done with
> > functions rather than preprocessor macros)
> >3. Remembering to transpose free_* and *_free between freeing a single 
> > node
> > and freeing a sequence.
> >4. Remembering whether or not a given cleanup function could cope with
> > NULL's or not
> >5. The fact that there wasn't a consistent "goto error" exception-alike
> > mechanism in use
> >
> > (I had a Spanish Inquisition-esque experience writing that list ;)
>
> :-)  I agree all those are existing issues.  #3 could be easily fixed.
>  #4 I think all cleanup functions can deal with NULLs now.  #5
> probably ought to be fixed in favor of using gotos.
>
> > Simply switching to PyObjects would solve the first four problems: 
> > everything
> > becomes a Py_XDECREF.
>
> 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.  I'd like to hear what
> Jeremy thinks about this.
>
> Is anyone interested in creating a patch along these lines (even a
> partial patch) to see the benefits?
>

Or should perhaps a branch be made since Subversion makes it so cheap
and this allows multiple people to work on it?

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Greg Ewing]

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 arguments (whether it
succeeds or not).

However, while that trick works in this particular case, it
wouldn't be so helpful in more complicated situations, so
Martin's version is probably a better model to follow.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Greg Ewing]

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 ast-building functions
effectively return borrowed references, which is not
usual

Thats' not to say it shouldn't be done, but it does
differ from the usual conventions, and that would need
to be kept in mind.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Greg Ewing]

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 what I thought
you were saying). If a .pyc were always generated,
this problem would not arise.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Greg Ewing]

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 it only works well
when you only call one such function from a given function.
If there are two, you have to worry about not reaching the
second one due to the first one failing, in which case
you need to decref the second one's args yourself.

In the long run it's probably best to stick to the
conventional conventions, which are there for a reason --
they work!

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Greg Ewing]

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 script?

(I'm being very careful not to suggest using Pyrex
for this, as I can appreciate the desire not to make
such a fundamental part of the core dependent on it!)

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Vinay Sajip]

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 fields?
> (There may be a good one, I just don't see it without turning on my
> thinking cap, which would cost extra.

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, ERROR, CRITICAL)
levelname   Text logging level for the message ("DEBUG", "INFO",
"WARNING", "ERROR", "CRITICAL")
msg The message passed in the logging call
argsThe additional args passed in the logging call
exc_infoException information (from sys.exc_info())
exc_textException text (cached for use by multiple handlers)
pathnameFull pathname of the source file where the logging call
was issued (if available)
filenameFilename portion of pathname
module  Module (name portion of filename)
lineno  Source line number where the logging call was issued
(if available)
created Time when the LogRecord was created (time.time()
return value)
msecs   Millisecond portion of the creation time
relativeCreated Time in milliseconds when the LogRecord was created,
relative to the time the logging module was loaded
(typically at application startup time)
thread  Thread ID (if available)
process Process ID (if available)
message The result of record.getMessage(), computed just as
the record is emitted

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.

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 supplied as a key in the user-supplied dict.

> Perhaps it makes sense to call it 'extra' instead of 'extra_info'?

Fine - 'extra' it will be.

> As a new feature it should definitely not go into 2.4; but I don't see
> how it could break existing code.
>

OK - thanks for the feedback.

Regards,

Vinay Sajip


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[skip]

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 computation can be avoided.  I did that recently by inlining
only the parts of logging.LogRecord.__init__ in a subclass and avoided
calling logging.LogRecord.__init__ altogether.  It generated lots of
instance variables we never use and just slowed things down.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 supplied as a key in the user-supplied dict.

+1

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com