Re: [Python-Dev] AST manipulation and source code generation

[Gareth McCaughan]

> ?!ng: Well, i should refine that a bit to say that the Lisp macro system
> is a little more specific.  Whereas AST transformations in Python
> are open-ended (you could generate any result you want), the key
> interesting property of Lisp macros is that they are constrained
> to be "safe", in the sense that the bindings of variable names are
> always preserved.

I'm not quite sure what ?!ng means by "the bindings of
variable names are always preserved", but I conjecture
that he is thinking of the "hygienic macros" in Scheme
rather than the macros in Common Lisp which permit
arbitrary code transformations.

-- 
g

___
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] Closing old bugs

[Michael Chermside]

Raymond writes:
> Is there anyone else on python-dev who thinks it's a bad idea to automatically
> close reports without checking whether the issue is real?

Raymond:

I'm speaking up with some trepidation here, since I am NOT one of those
who frequently closes bugs. But I think that at least sometimes there
IS an advantage to closing old bugs.

I can envision a world in which there would be only 5-10 open bug reports
at any given time, with enough developer volunteers available to respond
to new reports as they come in. And I realize that we are nowhere near
such a world and we're not going to be getting there anytime soon.

But it is still the case that MOST people are intimidated by the enormous
stack of open bugs. Perhaps "intimidated" is the wrong word... what I want
to convey is that most people have no idea what's important or where to
start -- it's just too big a pile. Perhaps all of the people who would
actually work to close Python bugs are perfectly happy with the existing
system. Or perhaps we scare off some potential volunteers because they
have no idea where to start.

I've seen some systems that solve this problem by allowing users to "vote"
for favorite bugs... then you can tell the "important" bugs because they
are more likely to have lots of votes. As I see it, Facundo is using a
variant of that system. He is asking whether there is *ONE PERSON* out
there who cares enough about a bug to subscribe to it and then to respond
to his inquiry. If there's not even one such person, then he's closing
the bug (but if one such person comes along later, they can re-report it).

Sure, we may be throwing away some useful information by closing a bug
report without proper investigation. But we're not in a situation where
we are short of information... we've got plenty of information (bug
reports), what we lack is developer time. If throwing away information
helps to better focus the developer time we have, then it may be a
useful process!

And someday when nirvana arrives and there are only 5-10 open bugs, we
can send intrepid volunteers digging through the archives to examine
bugs that got closed without proper investigation. I'm not holding my
breath.

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

[Python-Dev] Vestigial code in threadmodule?

[A.M. Kuchling]

Looking at bug #1209880, the following function from threadmodule.c is
referenced.  I think the args==NULL case, which can return None
instead of a Boolean value, can never be reached because
PyArg_ParseTuple() will fail if args==NULL.

Before ripping the args==NULL code out, I wanted to be sure my
analysis is correct; is there some subtlety here I'm missing that
makes args==NULL possible?

--amk

static PyObject *
lock_PyThread_acquire_lock(lockobject *self, PyObject *args)
{
   int i = 1;

   if (!PyArg_ParseTuple(args, "|i:acquire", &i))
  return NULL;

   Py_BEGIN_ALLOW_THREADS
   i = PyThread_acquire_lock(self->lock_lock, i);
   Py_END_ALLOW_THREADS

   if (args == NULL) {
  Py_INCREF(Py_None);
  return Py_None;
   }
   else
  return PyBool_FromLong((long)i);
}
___
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] Closing old bugs

[Raymond Hettinger]

> I've seen some systems that solve this problem by allowing users to
"vote"
> for favorite bugs... then you can tell the "important" bugs because
they
> are more likely to have lots of votes. As I see it, Facundo is using a
> variant of that system. He is asking whether there is *ONE PERSON* out
> there who cares enough about a bug to subscribe to it and then to
respond
> to his inquiry.  If there's not even one such person, then he's
closing
> the bug (but if one such person comes along later, they can re-report
it).

-1  This is both silly and harmful.  It in no way resembles a
professional approach to bug resolution.  It throws away valuable
information based on some vague theory of developer marketing (i.e.
threatening to close a bug will cause a qualified, interested developer
to suddenly have both the time and inclination to address it properly).

If the real goal is to "kick some life" into bug resolution, then do
something that directly fulfills that goal.  Host a bug day.  Make a
newsgroup posting requesting thoughts on your favorite ten bugs.  Write
email to people who you think are capable of addressing the particular
issue in question.  Go recruit some qualified developers.  Or just find
a bug that interests you and fix it.

Closing bugs without reading them is an anti-contribution.  If it were a
best practice, then there would already be a cron job in place to do it
automatically.



Raymond
___
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] Closing old bugs

[Reinhold Birkenfeld]

Raymond Hettinger wrote:
>> I've seen some systems that solve this problem by allowing users to
> "vote"
>> for favorite bugs... then you can tell the "important" bugs because
> they
>> are more likely to have lots of votes. As I see it, Facundo is using a
>> variant of that system. He is asking whether there is *ONE PERSON* out
>> there who cares enough about a bug to subscribe to it and then to
> respond
>> to his inquiry.  If there's not even one such person, then he's
> closing
>> the bug (but if one such person comes along later, they can re-report
> it).
> 
> -1  This is both silly and harmful.  It in no way resembles a
> professional approach to bug resolution.  It throws away valuable
> information based on some vague theory of developer marketing (i.e.
> threatening to close a bug will cause a qualified, interested developer
> to suddenly have both the time and inclination to address it properly).

ACK so far.

> If the real goal is to "kick some life" into bug resolution, then do
> something that directly fulfills that goal.  Host a bug day.  Make a
> newsgroup posting requesting thoughts on your favorite ten bugs.  Write
> email to people who you think are capable of addressing the particular
> issue in question.  Go recruit some qualified developers.  Or just find
> a bug that interests you and fix it.

Well, to "fix it" is not so easy for most people. You have to post a patch
or attach it to the bug and then wait for someone to check it in. It's not
sure that this is done anytime soon (no complaint; time is short, I know).
Even fixes that are agreed upon by several people are not always checked in
for a long time.

Reinhold

-- 
Mail address is perfectly valid!

___
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] Vestigial code in threadmodule?

[Neal Norwitz]

On 6/2/05, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> Looking at bug #1209880, the following function from threadmodule.c is
> referenced.  I think the args==NULL case, which can return None
> instead of a Boolean value, can never be reached because
> PyArg_ParseTuple() will fail if args==NULL.
> 
> Before ripping the args==NULL code out, I wanted to be sure my
> analysis is correct; is there some subtlety here I'm missing that
> makes args==NULL possible?

I think the args == NULL code should be ripped out, but there seems to
be a different problem.

If args is NULL to PyArg_ParseTuple() an assertion will be triggered
(or it'll just crash).  See vgetargs1() in Python/getargs.c::138.

args can be NULL if load_args() in Python/ceval.c fails (line 3724). 
The trace starts at line 3551, PyCFunction_Call() will be called with
the NULL args on line 3553.  PyCFunction_Call() will call a PyMethod
that will likely call PyArg_ParseTuple() or something like it.

I think the following patch should fix this (it just adds an if condition).

Does this make sense or am I missing something?

n
--
Index: Python/ceval.c
===
RCS file: /cvsroot/python/python/dist/src/Python/ceval.c,v
retrieving revision 2.422
diff -u -r2.422 ceval.c
--- Python/ceval.c  4 Apr 2005 15:49:02 -   2.422
+++ Python/ceval.c  2 Jun 2005 13:16:14 -
@@ -3549,9 +3549,13 @@
else {
PyObject *callargs;
callargs = load_args(pp_stack, na);
-   READ_TIMESTAMP(*pintr0);
-   C_TRACE(x=PyCFunction_Call(func,callargs,NULL));
-   READ_TIMESTAMP(*pintr1);
+   if (callargs) {
+   READ_TIMESTAMP(*pintr0);
+  
C_TRACE(x=PyCFunction_Call(func,callargs,NULL));+ 
 READ_TIMESTAMP(*pintr1);
+   }
+   else
+   x = NULL;
Py_XDECREF(callargs);
}
} else {
___
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] PEP 343 rewrite complete

[Arnold deVos]

Guido van Rossum wrote:
> [Phillip J. Eby]
>>* The transaction handler could also be written as:
>>
>> @with_template
>> def transactional(db):
>> db.begin()
>> try:
>> yield db
>> except:
>> db.rollback()
>> else:
>> db.commit()
>>
>>at least, if I understand it correctly.
> 
> 
> Ah, of course. I've updated the PEP.
> 

This template eats eats the exception, which will cause a RuntimeError
in the proposed Wrapper, I think.  A raise after rollback is needed.

- Arnold
___
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] Vestigial code in threadmodule?

[Jeremy Maxfield]

If you're digging  into the threadmodule.c could you take a look at
bug #1163563 
(http://sourceforge.net/tracker/index.php?func=detail&aid=1163563&group_id=5470&atid=105470)
I've posted a patch
(http://sourceforge.net/tracker/index.php?
func=detail&aid=1203393&group_id=5470&atid=305470)

Regards,
Max


On 6/2/05, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> Looking at bug #1209880, the following function from threadmodule.c is
> referenced.  I think the args==NULL case, which can return None
> instead of a Boolean value, can never be reached because
> PyArg_ParseTuple() will fail if args==NULL.
> 
> Before ripping the args==NULL code out, I wanted to be sure my
> analysis is correct; is there some subtlety here I'm missing that
> makes args==NULL possible?
> 
> --amk
> 
> static PyObject *
> lock_PyThread_acquire_lock(lockobject *self, PyObject *args)
> {
>   int i = 1;
> 
>   if (!PyArg_ParseTuple(args, "|i:acquire", &i))
>  return NULL;
> 
>   Py_BEGIN_ALLOW_THREADS
>   i = PyThread_acquire_lock(self->lock_lock, i);
>   Py_END_ALLOW_THREADS
> 
>   if (args == NULL) {
>  Py_INCREF(Py_None);
>  return Py_None;
>   }
>   else
>  return PyBool_FromLong((long)i);
> }
> ___
> 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/anothermax%40gmail.com
> 


-- 
flickr: http://www.flickr.com/photos/anothermax/sets
___
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] Vestigial code in threadmodule?

[Tim Peters]

[A.M. Kuchling]
> Looking at bug #1209880, the following function from threadmodule.c is
> referenced.  I think the args==NULL case, which can return None
> instead of a Boolean value, can never be reached because
> PyArg_ParseTuple() will fail if args==NULL.

It would assert-fail in a debug build.  In a release build the most
likely outcome would be a segfault (NULL-pointer dereference in the
expansion of vgetargs1's "PyTuple_Check(args)").

> Before ripping the args==NULL code out, I wanted to be sure my
> analysis is correct; is there some subtlety here I'm missing that
> makes args==NULL possible?

Rip it out; blame me .

> --amk
>
> static PyObject *
> lock_PyThread_acquire_lock(lockobject *self, PyObject *args)

Noe that this is a file-local function.  The only references are here:

static PyMethodDef lock_methods[] = {
{"acquire_lock", (PyCFunction)lock_PyThread_acquire_lock, 
 METH_VARARGS, acquire_doc},
{"acquire",  (PyCFunction)lock_PyThread_acquire_lock, 
 METH_VARARGS, acquire_doc},

METH_VARARGS always passes a tuple (possibly empty).  These are very
old functions, so I bet they used to use METH_OLDARGS (implied by
absence at the time) ... yup, METH_VARARGS was introduced here in rev
2.48, and unintentionally changed the return contract of this
function.  So that was a backward incompatibility introduced in Python
2.3a1.  Since nobody complained then or since, I vote to keep "the
new" return contract and fiddle the docs to match it.
___
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] PEP 343 rewrite complete

[Arnold deVos]

Arnold deVos wrote:
> 
> This template eats eats the exception, which will cause a RuntimeError
> in the proposed Wrapper, I think.  A raise after rollback is needed.

Actually, the Wrapper as written in the PEP does not raise RuntimeError
if the generator catches a block's exception.

Shouldn't the relevant clause in the Wrapper go like this:

try:
self.gen.throw(type, value, traceback)
except type:
return
except StopIteration:
raise RuntimeError("generator caught exception")
else:
raise RuntimeError("generator didn't stop")

And the transaction template would go like this (re-raising the exception):

@with_template
def transactional(db):
db.begin()
try:
yield None
except:
db.rollback()
raise
else:
db.commit()

At least this is what I gleaned from the earlier threads.  It means that
the template does not appear to supress an exception that it cannot
actually supress.

- Arnold

___
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] PEP 343 rewrite complete

[Guido van Rossum]

[Arnold deVos, responding to himself]
> > This template eats eats the exception, which will cause a RuntimeError
> > in the proposed Wrapper, I think.  A raise after rollback is needed.

No, the generator returns after rolling back, which causes throw() to
raise StopIteration, which is good enough for the wrapper as written.

> Actually, the Wrapper as written in the PEP does not raise RuntimeError
> if the generator catches a block's exception.
> 
> Shouldn't the relevant clause in the Wrapper go like this:
> 
> try:
> self.gen.throw(type, value, traceback)
> except type:
> return
> except StopIteration:
> raise RuntimeError("generator caught exception")
> else:
> raise RuntimeError("generator didn't stop")

I considered that, but decided that it should be okay for the
generator to respond to a throw() by returning (thus replacing the
exception thrown by StopIteration) since the call to __exit__() is
contained inside a finally-clause, so that when __exit__() returns
normally, the finally-clause will re-raise the original exception
anyway.

Note that there are currently no other use cases for throw() except
the with_template decorator and the close() method. Both allow the
generator to respond either by letting the exception pass through it
unchanged (after executing finally-clauses if present) or by simply
returning (which will raise StopIteration in the caller of throw()).
Erroneous behaviors are, in both cases, raising some other exception
or *yielding* another value. There may be *other* use cases for
yielding a value, for example, a future (looping) block-statement a la
PEP 343. Raising another exception is always an indication of a bug in
the generator.

> And the transaction template would go like this (re-raising the exception):
> 
> @with_template
> def transactional(db):
> db.begin()
> try:
> yield None
> except:
> db.rollback()
> raise
> else:
> db.commit()
> 
> At least this is what I gleaned from the earlier threads.  It means that
> the template does not appear to supress an exception that it cannot
> actually supress.

I disagree (at the -0 to -0.5 level); given that the with_template
decorator allows StopIteration, I think that "appearing to suppress an
exception it doesn't actually suppress" is a minor sin -- the key
point is that the cleanup gets executed and doesn't raise a new
exception or reaches a yield-statement.

I'll summarize this discussion in the PEP.

-- 
--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] PEP 343 rewrite complete

[Guido van Rossum]

[me]
> I'll summarize this discussion in the PEP.

I've added this section to the PEP. Is anyone dead set against the
tentative resolutions here?

Open Issues

Discussion on python-dev has revealed some open issues.  I list
them here, with my preferred resolution and its motivation.  The
PEP as currently written reflects this preferred resolution.

1. What exception should be raised by close() when the generator
   yields another value as a response to the GeneratorExit
   exception?

   I originally chose TypeError because it represents gross
   misbehavior of the generator function, which should be fixed by
   changing the code.  But the with_template decorator class uses
   RuntimeError for similar offenses.  Arguably they should all
   use the same exception.  I'd rather not introduce a new
   exception class just for this purpose, since it's not an
   exception that I want people to catch: I want it to turn into a
   traceback which is seen by the programmer who then fixes the
   code.  So now I believe they should both raise RuntimeError.
   There are some precedents for that: it's raised by the core
   Python code in situations where endless recursion is detected,
   and for uninitialized objects (and for a variety of
   miscellaneous conditions).

2. Both the generator close() method and the __exit__() method of
   the with_template decorator class catch StopIteration and
   consider it equivalent to re-raising the exception passed to
   throw().  Is allowing StopIteration right here?

   This is so that a generator doing cleanup depending on the
   exception thrown (like the transactional() example below) can
   *catch* the exception thrown if it wants to and doesn't have to
   worry about re-raising it.  I find this more convenient for the
   generator writer.  Against this was brought in that the
   generator *appears* to suppress an exception that it cannot
   suppress: the transactional() example would be more clear
   according to this view if it re-raised the original exception
   after the call to db.rollback().  I personally would find the
   requirement to re-raise the exception an annoyance in a
   generator used as a with-template, since all the code after
   yield is used for is cleanup, and it is invoked from a
   finally-clause (the one implicit in the with-statement) which
   re-raises the original exception anyway.


-- 
--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] PEP 343 rewrite complete

[Nick Coghlan]

Guido van Rossum wrote:
> I hope that I've got the rewrite of PEP 343 to include generator
> extensions right now. I've chosen the 'with' keyword. Please review
> here; I think this is ready for review by the unwashed masses. :-)
> 
>   http://www.python.org/peps/pep-0343.html
> 

Looks pretty good to me (looking at version 1.19).

One comment is that, in the 'optional extensions' section, where you 
say 'such mistakes are easily diagnosed', you could point to your 
generator wrapper as an example where attempting to reuse the block 
handler raises a RuntimeError on the second attempt.

Also, I'm wondering if it would be useful to have a 'closing' template 
that looked like:

   @with_template
   def closing(obj):
   try:
   yield obj
   finally:
   obj.close()

That can be used to deterministically close anything with a close 
method, be it file, generator, or something else:

   with closing(open("argument.txt")) as contradiction:
  for line in contradiction:
  print line

   with closing(some_gen()) as data:
  for datum in data:
  process(datum)


Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
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] PEP 343 rewrite complete

[Phillip J. Eby]

At 01:08 AM 6/3/2005 +1000, Nick Coghlan wrote:
>Also, I'm wondering if it would be useful to have a 'closing' template
>that looked like:
>
>@with_template
>def closing(obj):
>try:
>yield obj
>finally:
>obj.close()

+1 if you make it 'if hasattr(obj,"close"): obj.close()' in the finally 
clause, so that it will still work if the type of the object changes.

___
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] PEP 343 rewrite complete

[Guido van Rossum]

On 6/2/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:08 AM 6/3/2005 +1000, Nick Coghlan wrote:
> >Also, I'm wondering if it would be useful to have a 'closing' template
> >that looked like:
> >
> >@with_template
> >def closing(obj):
> >try:
> >yield obj
> >finally:
> >obj.close()
> 
> +1 if you make it 'if hasattr(obj,"close"): obj.close()' in the finally
> clause, so that it will still work if the type of the object changes.

But then you'd get back the bug where it would silently do nothing
when you pass it the wrong thing; wasn't that argument used against an
earlier proposal to skip calling __exit__() when it doesn't exist?

-- 
--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] PEP 343 rewrite complete

[Phillip J. Eby]

At 09:20 AM 6/2/2005 -0700, Guido van Rossum wrote:
>On 6/2/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 01:08 AM 6/3/2005 +1000, Nick Coghlan wrote:
> > >Also, I'm wondering if it would be useful to have a 'closing' template
> > >that looked like:
> > >
> > >@with_template
> > >def closing(obj):
> > >try:
> > >yield obj
> > >finally:
> > >obj.close()
> >
> > +1 if you make it 'if hasattr(obj,"close"): obj.close()' in the finally
> > clause, so that it will still work if the type of the object changes.
>
>But then you'd get back the bug where it would silently do nothing
>when you pass it the wrong thing;

That's not a bug, it's a feature.  If the object doesn't have a 'close()' 
method, clearly it doesn't need to be closed.  If it's the "wrong" object 
for what you're using it for in the body of the 'with' block, it'll show up 
there, so this doesn't hide any errors.

The idea is that "with closing(foo):" is just an assertion that you only 
intend to use 'foo' in the body of that block, and not afterwards, so if 
'foo' is something that needs closing, go ahead and close it.

The specific use case I have in mind is situations where a piece of code 
expects an iterable, but there are callers (or callees) that need to do 
cleanup.  On the other hand some callers (or callees) would like to just 
pass in or return a list, or are passing or returning an object from 
somewhere else that may or may not have a close() method.

Thus, a whole bunch of code would suddenly be strewed with assumptions 
about whether things can be closed or not, which seems like pure 
administrivia.  The important functionality is what the object does 
*before* you close it; that's what the programmer should be able to remain 
focused on.


>wasn't that argument used against an
>earlier proposal to skip calling __exit__() when it doesn't exist?

I thought the resolution of that discussion was that you should use an 
explicit wrapper if you want this behavior -- which is what 'closing()' 
is.  Anyway, if you don't like it, don't put it in.  I just thought it 
would be a good example to include for a wrapper whose behavior is more 
optional in nature.

___
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] [Python-checkins] python/dist/src/Lib sre_compile.py, 1.57, 1.58

[Raymond Hettinger]

> Index: sre_compile.py
> ===
> RCS file: /cvsroot/python/python/dist/src/Lib/sre_compile.py,v
> retrieving revision 1.57
> retrieving revision 1.58
> diff -u -d -r1.57 -r1.58
> --- sre_compile.py28 Feb 2005 19:27:52 -  1.57
> +++ sre_compile.py2 Jun 2005 13:35:52 -   1.58
> @@ -167,7 +167,7 @@
>  emit(av-1)
>  elif op is GROUPREF_EXISTS:
>  emit(OPCODES[op])
> -emit((av[0]-1)*2)
> +emit(av[0]-1)
>  skipyes = _len(code); emit(0)
>  _compile(code, av[1], flags)
>  if av[2]:


The times two operation also occurs twice in nearby code.  Are those
also incorrect?


Raymond Hettinger
___
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] [Python-checkins] python/dist/src/Lib sre_compile.py, 1.57, 1.58

[A.M. Kuchling]

On Thu, Jun 02, 2005 at 03:34:17PM -0400, Raymond Hettinger wrote:
> The times two operation also occurs twice in nearby code.  Are those
> also incorrect?

I believe they're correct.  

EXPN: The regex engine refers to both 'groups', where group #N means
the corresponding group in the pattern, and 'marks', which is a table
of indexes into the string; group #0 -> mark 0 and 1, group #1 -> mark
2 and 3, etc.  The compiler was storing the mark value, but then the
code for the GROUPREF_EXISTS opcode was doubling it, converting group
to mark:

case SRE_OP_GROUPREF_EXISTS:
TRACE(("|%p|%p|GROUPREF_EXISTS %d\n", ctx->pattern,
   ctx->ptr, ctx->pattern[0]));
/*codeyes  codeno ... */
i = ctx->pattern[0];
{
int groupref = i+i;
if (groupref >= state->lastmark) {
ctx->pattern += ctx->pattern[1];
break;
} else {
...
 }

The two other uses of *2 are for the MARK opcode, which stores the
current position in the string in the corresponding entry in the
table; it really does want the mark number, so the doubling is
correct.

The 'groupref = i+i' in the above code is a bit odd -- why not write 2*i?  I
thought it might be a typo for i+1, but that wouldn't make sense
either; eventually I decided this was just a stylistic thing.

--am"Only the effbot knows for sure"k



___
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] PEP 343 rewrite complete

[Eric Nieuwland]

Phillip J. Eby wrote:
> At 10:00 PM 6/1/2005 +0200, Eric Nieuwland wrote:
>> Phillip J. Eby wrote:
>> > -1, too confusing.
>>
>> A matter of taste, I guess. IMHO 'with' secretly handling exceptions 
>> is
>> confusing.
>
> It doesn't secretly handle them; it simply gets access to them, which 
> is an entirely different thing.
>
> By confusing, I mean that it is not clear from your construct what 
> exceptions are caught by the 'except' clause, due to its structural 
> layout.  It's also not clear whether the __enter__/__exit__ of EXPR 
> wrap BLOCK1 only, or both BLOCK1 and BLOCK2.  These aspects are 
> "confusing" because whatever decision you make about the semantics, 
> someone will have to *remember* them, as opposed to being 
> unambiguously represented by the block structure.
>
> By contrast, if you remove the except: clause from your construct, it 
> is clear that BLOCK1 is what is wrapped, and there is no possible 
> confusion about who sees what exceptions.  Exceptions inside the block 
> are communicated to __exit__, exceptions outside (including those in 
> the 'with' statement itself) are not.

OK. This forwarding (is that the proper expression here?) of an 
exception to __exit__ is what I meant by 'secretly handling'.

If everybody agrees I'll write
with EXPR as VAR:
try:
BLOCK1
except EXCEPTION:
BLOCK2
instead. Seems a waiste to me, though.
I was thinking about 'try EXPR [as VAR]:' as a 'try' that handles 
uncaught exceptions by forwarding it to EXPR's __exit__ method. No 
confusion with me.

--eric

___
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] PEP 343 rewrite complete

[Phillip J. Eby]

At 10:04 PM 6/2/2005 +0200, Eric Nieuwland wrote:
>I was thinking about 'try EXPR [as VAR]:' as a 'try' that handles uncaught 
>exceptions by forwarding it to EXPR's __exit__ method. No confusion with me.

No doubt.  However, it's not obvious what happens to an exception in EXPR; 
surely it can't be passed to EXPR's __exit__ method.  So, is it handled by 
the try, or does it pass out of the block?  Whichever answer you give, 
there is somebody who will think the opposite.  And this is precisely the 
ambiguity I've been talking about.

In contrast, a 'with' unmixed with 'try' is absolutely unambiguous as to 
which except: clauses handle what exceptions where.

___
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] PEP 343 rewrite complete

[Eric Nieuwland]

On 2 jun 2005, at 22:12, Phillip J. Eby wrote:

> At 10:04 PM 6/2/2005 +0200, Eric Nieuwland wrote:
>> I was thinking about 'try EXPR [as VAR]:' as a 'try' that handles 
>> uncaught exceptions by forwarding it to EXPR's __exit__ method. No 
>> confusion with me.
>
> No doubt.  However, it's not obvious what happens to an exception in 
> EXPR; surely it can't be passed to EXPR's __exit__ method.  So, is it 
> handled by the try, or does it pass out of the block?  Whichever 
> answer you give, there is somebody who will think the opposite.  And 
> this is precisely the ambiguity I've been talking about.
>
> In contrast, a 'with' unmixed with 'try' is absolutely unambiguous as 
> to which except: clauses handle what exceptions where.

 I never thought of that! Now I see what you mean.
I could only save my idea by stating "the scope of 'try' only starts 
after the ':'", but that seems too artificial.

--eric

___
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] PEP 343 rewrite complete

[Phillip J. Eby]

At 10:16 PM 6/2/2005 +0200, Eric Nieuwland wrote:

>On 2 jun 2005, at 22:12, Phillip J. Eby wrote:
>
> > At 10:04 PM 6/2/2005 +0200, Eric Nieuwland wrote:
> >> I was thinking about 'try EXPR [as VAR]:' as a 'try' that handles
> >> uncaught exceptions by forwarding it to EXPR's __exit__ method. No
> >> confusion with me.
> >
> > No doubt.  However, it's not obvious what happens to an exception in
> > EXPR; surely it can't be passed to EXPR's __exit__ method.  So, is it
> > handled by the try, or does it pass out of the block?  Whichever
> > answer you give, there is somebody who will think the opposite.  And
> > this is precisely the ambiguity I've been talking about.
> >
> > In contrast, a 'with' unmixed with 'try' is absolutely unambiguous as
> > to which except: clauses handle what exceptions where.
>
> I never thought of that! Now I see what you mean.
>I could only save my idea by stating "the scope of 'try' only starts
>after the ':'", but that seems too artificial.

That's what I mean: if you have to solve it by decree, it becomes a rule 
that people have to *remember* (or at least read carefully and think about 
it), which goes against the "executable pseudocode" nature.

___
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] PEP 343 rewrite complete

[Delaney, Timothy C (Timothy)]

Phillip J. Eby wrote:

> That's not a bug, it's a feature.  If the object doesn't have a
> 'close()' 
> method, clearly it doesn't need to be closed.  If it's the "wrong"
> object 
> for what you're using it for in the body of the 'with' block, it'll
> show up 
> there, so this doesn't hide any errors.

For those semantics, I think one of the following would be better:

with local(obj):

with scoped(obj):

but those semantics apply better to __enter__ and __exit__ anyway.

I think a "closing adaptor" should only work with objects that have a
close() method.

Perhaps:

with scoped_closable(obj):

Tim Delaney
___
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] PEP 343 rewrite complete

[Guido van Rossum]

[Nick Coghlan]
> Also, I'm wondering if it would be useful to have a 'closing' template
> that looked like:
> 
>@with_template
>def closing(obj):
>try:
>yield obj
>finally:
>obj.close()
> 
> That can be used to deterministically close anything with a close
> method, be it file, generator, or something else:
> 
>with closing(open("argument.txt")) as contradiction:
>   for line in contradiction:
>   print line
> 
>with closing(some_gen()) as data:
>   for datum in data:
>   process(datum)

I just realized this has a race condition. The bytecode for the
expression closing(open("...")) must necessarily contain a bytecode
that calls open() followed by another bytecode that calls closing().
If a ^C happens between these two byte codes, the stack contains an
open file object that won't be closed explicitly.

With the original opening() template, this race can be avoided (and I
intend to do so) by implementing opening() in C (as a class with
__enter__ and __exit__ methods), and by making sure that the
interpreter does *not* check for interrupts between the call to
__enter__ and the start of the try-finally-statement in the
translation of the with-statement.

The only way to avoid the race that I can see with the closing()
template would be to disable signals for the duration of the
evaluation of the expression in the with-statement, but I really don't
like that solution at all -- system calls like that can be
excruciatingly expensive compared to bytecode execution. Most
applications don't catch ^C so they don't need this extra protection
-- but the compiler doesn't know that so everybody pays for it. The
solution for avoiding interrupts between the __enter__() call and the
try start doesn't require disabling signals; there can be a single
opcode that calls __enter__ and sets up the try-finally context.

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

[Python-Dev] sys.path in interactive session

[Reinhold Birkenfeld]

While looking at bug #779191, I saw that sys.path's first element
is '' in interactive sessions, but the current dir otherwise. Is this
intentional?

Reinhold

-- 
Mail address is perfectly valid!

___
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] sys.path in interactive session

[Guido van Rossum]

I've always liked it this way; using "" instead of "." means that if
you os.path.join() it with a script name you don't get a spurious "./"
prepended.

I think that the "absolutizing" of sys.path entries is relatively new
(seems to have started in 2.3).

Also note that it's not really the current directory but the directory
containing the script; that is definitely intentional.

On 6/2/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> While looking at bug #779191, I saw that sys.path's first element
> is '' in interactive sessions, but the current dir otherwise. Is this
> intentional?
> 
> Reinhold
> 
> --
> Mail address is perfectly valid!
> 
> ___
> 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/guido%40python.org
> 


-- 
--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] sys.path in interactive session

[Bob Ippolito]

On Jun 2, 2005, at 4:50 PM, Guido van Rossum wrote:

> On 6/2/05, Reinhold Birkenfeld  [EMAIL PROTECTED]> wrote:
>
>> While looking at bug #779191, I saw that sys.path's first element
>> is '' in interactive sessions, but the current dir otherwise. Is this
>> intentional?
>>
>
> I've always liked it this way; using "" instead of "." means that if
> you os.path.join() it with a script name you don't get a spurious "./"
> prepended.
>
> I think that the "absolutizing" of sys.path entries is relatively new
> (seems to have started in 2.3).
>
> Also note that it's not really the current directory but the directory
> containing the script; that is definitely intentional.

The absolutizing of sys.path in site.py is misbehavior anyway.. it  
spits in the face of path hooks, for example .

I still haven't committed that patch, I haven't had a whole lot of  
Python-time lately with co-founding a new company, preparing to move,  
WWDC, etc... but nobody bothered to complain, so if someone wants to  
commit  before I get a chance, feel free!

-bob

___
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] sys.path in interactive session

[Phillip J. Eby]

At 05:08 PM 6/2/2005 -0700, Bob Ippolito wrote:
>On Jun 2, 2005, at 4:50 PM, Guido van Rossum wrote:
> >
> > I think that the "absolutizing" of sys.path entries is relatively new
> > (seems to have started in 2.3).
> >
> > Also note that it's not really the current directory but the directory
> > containing the script; that is definitely intentional.
>
>The absolutizing of sys.path in site.py is misbehavior anyway..

Your patch doesn't fix it doing this to __file__; probably this should not 
touch __file__ if a module has a __loader__ set, or if the path it's 
absolutizing doesn't exist.

Actually, your patch doesn't fix it doing this to all the sys.path entries, 
either.  It appears that site.py may be quite broken with respect to PEP 
302.  Fixing it is going to be interesting, since it's quite possible that 
you can have stuff on PYTHONPATH for which the sys.path_hooks entries don't 
exist yet.  Thus, you can't guarantee when you absolutize a path entry that 
it is in fact a filename, unless you check for its existence - which in 
principle could be a coincidence.

It may be that we need to define more clearly what is allowed on sys.path, 
such that site.py can tell the difference between filesystem paths, and 
non-filesystem PEP 302 specifiers.  Right now, the only major PEP 302 
implementation that I know of is zipimport, but zipimport uses strings that 
are effectively filesystem paths, so site.py doesn't break them.


___
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] PEP 343 rewrite complete

[Arnold deVos]

Guido van Rossum wrote:
> 
>[...] a generator doing cleanup depending on the
>exception thrown (like the transactional() example below) can
>*catch* the exception thrown if it wants to and doesn't have to
>worry about re-raising it.  I find this more convenient for the
>generator writer.  Against this was brought in that the
>generator *appears* to suppress an exception that it cannot
>suppress: the transactional() example would be more clear
>according to this view if it re-raised the original exception
>after the call to db.rollback().  [...]

Of course, the explicit re-raise is only needed in a minority of use 
cases where the exception is caught. Two additional points in favour of 
this:

- refactoring a naked try as a with + template is more direct and 
uniform across all use cases.

- it is upwards compatible if the prohibition on templates suppressing 
exceptions is ever reconsidered. (Flow control macro discussion not 
withstanding.)

- Arnold

___
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

[Python-Dev] For review: PEP 343: Anonymous Block Redux and Generator Enhancements

[Guido van Rossum]

After many rounds of discussion on python-dev, I'm inviting public
comments for PEP 343. Rather than posting the entire PEP text here,
I'm inviting everyone to read it on line
(http://www.python.org/peps/pep-0343.html) and then post comments on a
Wiki page I've created for this purpose
(http://wiki.python.org/moin/WithStatement).

I think this is a good one; I hope people agree. Its acceptance will
obsolete about 4 other PEPs! (A sign that it fulfills a need and that
the proposed solution is powerful.)

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