Re: [Python-Dev] Tidier Exceptions

[Guido van Rossum]

[Greg Ewing]
> Are there plans as to when string exceptions will be
> exterminated? Surely the only places they're used now
> are in some very old library modules.

No concrete plans; I was always planning to abandon them in 3.0 but
haven't felt the need to do it sooner. Last I looked Zope 2 still
depended on them (especially in the bowels of ZODB); maybe Tim Peters
knows if that's still the case.

If you want to do it sooner, maybe we need a small PEP with the
timeline (e.g. warn in Python 2.5, illegal in Python 2.6). Or perhaps
a patch on SF is all that's needed.

I expect it would be much more challenging to switch to the model
where all exceptions derive from a single (new-style) base class.

(And no, there are no plans to kill classic classes before 3.0 either.)

-- 
--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] "with" use case: replacing a file

[Nick Coghlan]

Guido van Rossum wrote:
>>P.S. The points regarding non-local flow control in Joel Spolsky's latest Joel
>>on Software article (especially the links at the end) may have had something 
>>to
>>do with my change of heart. . .
> 
> 
> I'm a big fan of Joel. Care to share the specific URL for the article
> you're referring to?
> 

Sorry about that (I was in a hurry this morning). It was here:
http://www.joelonsoftware.com/articles/Wrong.html

The link of particular interest regarding exception handling was this one:
http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.aspx

Some interesting points about some of the cons of exception based code (at 
least 
some of which relate to what we're dealing with in factoring out finally 
clauses, and C++ deals with via scope-based destruction).

Anyway, it made me realise that having any callables you invoke potentially 
raise exceptions is already tricky to deal with, and allowing a different call 
to potentially *suppress* those exceptions is a recipe for serious confusion.

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] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum]

I just read Raymond Chen's rant against control flow macros:
http://blogs.msdn.com/oldnewthing/archive/2005/01/06/347666.aspx

I think this pretty much kills PEP 340, as well as Nick Coghlan's
alternative: both proposals let you write a "template" that can be
used to hide exception-catching code, which is a form of control flow
(and a pretty important one if you read Chen's rant against exceptions
referenced by the former, even if you don't agree with everything he
says in the latter).

Which leaves us, IMO, with the choice between PEP 310 and my own
"PEP-340-redux" proposal; these *only* introduce a finally-clause,
which does not affect the control flow. I'm not counting exceptions
that might happen in the finally-clause; exceptions can happen
anywhere anyway. But I am counting the *catching* of an exception as
control flow, since that means that code past BLOCK (in the same
function) is reachable even if BLOCK was not executed to completion;
and this is the argument against PEP 340 and against Nick's
alternative.

Let's compare and contrast the two remaining competitors:

PEP 310
===

Syntax:
with EXPR [= VAR]:
BLOCK

Translation:
[VAR =] abc = EXPR
if hasattr(abc, "__enter__"):
abc.__enter__()
try:
BLOCK
finally:
abc.__exit__()

Pros:
- dead simple

Cons:
- can't use a decorated generator for EXPR

PEP 340 redux
=

Syntax:
do EXPR [as VAR]:
BLOCK

Translation:
abc = EXPR
[VAR =] abc.__enter__()
try:
BLOCK
finally:
abc.__exit__(*"sys.exc_info()") # Not exactly

Pros:
- can use a decorated generator as EXPR
- separation of EXPR and VAR (VAR gets what EXPR.__enter__() returns)

Cons:
- slightly less simple (__enter__ must return something for VAR;
  __exit__ takes optional args)

Everything else is equal or can be made equal. We can make them more
equal by treating the arguments passed to __exit__() as a separate
decision, and waffling about whether __enter__() should be optional (I
think it's a bad idea even for PEP 310; it *could* be made optional
for PEP 340 redux).

Let's also not quibble about the keyword used; again, that can be a
separate decision. Note that only PEP 310 can use the "VAR = EXPR"
syntax; PEP 340 redux *must* use "EXPR as VAR" since it doesn't assign
the value of EXPR to VAR; PEP 310 can be rewritten using this syntax
as well.

So then the all-important question I want to pose is: do we like the
idea of using a (degenerate, decorated) generator as a "template" for
the do-statement enough to accept the slightly increased complexity?
The added complexity is caused by the need to separate VAR from EXPR
so that a generator can be used. I personally like this separation; I
actually like that the "anonymous block controller" is logically
separate from the variable bound by the construct. From Greg Ewing's
response to the proposal to endow file objects with __enter__ and
__exit__ methods, I believe he thinks so too.

Straight up-or-down votes in the full senate are appreciated at this point.

On to the secondary questions:

- Today I like the 'do' keyword better; 'with' might confuse folks
coming from Pascal or VB

- I have a more elaborate proposal for __exit__'s arguments. Let the
translation be as follows:

abc = EXPR
[VAR =] abc.__enter__()
oke = False  # Pronounced "okay"
exc = ()
try:
try:
BLOCK
oke = True
except:
exc = sys.exc_info()
raise
finally:
abc.__exit__(oke, *exc)

This means that __exit__ can be called with the following arguments:

abc.__exit__(True) - normal completion of BLOCK

abc.__exit__(False) - BLOCK was left by a non-local goto (break/continue/return)

abc.__exit__(False, t, v, tb) - BLOCK was left by an exception

(An alternative would be to always call it with 4 arguments, the last
three being None in the first two cases.)

If we adopt PEP 340 redux, it's up to the decorator for degenerate
generators to decide how to pass this information into the generator;
if we adopt PEP 342 ("continue EXPR") at the same time, we can let the
yield-expression return a 4-tuple (oke, t, v, tb). Most templates can
ignore this information (so they can just use a yield-statement).

PS. I've come up with another interesting use case: block signals for
the duration of a block. This could be a function in the signal
module, e.g. signal.blocking([ist of signals to block]). The list
would default to all signals. Similar signal.ignoring().

-- 
--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] Python's Unicode width default (New Py_UNICODE doc)

[M.-A. Lemburg]

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
> 
>>Martin, please reconsider... the choice is between:
> 
> 
> The point is that this all was discussed, and decided the
> other way 'round. There is no point in going back and forth
> between the two choices:
> 
> http://mail.python.org/pipermail/python-dev/2003-June/036461.html

So you call two emails to the python-dev list a discussion ?

AFAICT, only Barry mildly suggested to have an automatic
--enable-unicode=ucs4 switch and then Jeff Epler provided
the patch including the warning that the patch wasn't tested
and that it does not attempt to make a more educated
guess as to where to find tcl.h (unlike setup.py does
in order to build _tkinter.c).

> If we remove the code, people will *again* report that
> _tkinter stops building on Redhat (see #719880). I
> see no value in breaking what works now.

I'm not breaking anything, I'm just correcting the
way things have to be configured in an effort to
bring back the cross-platforma configure default.

>>a) We have a cross-platform default Unicode width
>>   setting of UCS2.
> 
> 
> It is hardly the default anymore cross-platform. Many
> installations on Linux are built as UCS-4 now - no
> matter what configure does.

I'm talking about the *configure* default, not the
default installation you find on any particular
platform (this remains a platform decision to be made
by the packagers).

>>b) The default Unicode width is undefined and the only
>>   thing we can tell the user is:
>>
>>   Run the configure script and then try the interpreter
>>   to check whether you've got a UCS2 or UCS4 build.
> 
> 
> It's not at all undefined. There is a precise, deterministic,
> repeatable algorithm that determines the default, and
> if people want to know, we can tell them.

The outcome of the configure tests is bound to be
highly random across installations since it depends
whether TCL was installed on the system and how it
was configured. Furthermore, if a user wants to build
against a different TCL version, configure won't detect
this change, since it's setup.py that does the _tkinter.c
compilation.

The main point is that we can no longer tell users:
if you run configure without any further options,
you will get a UCS2 build of Python.

I want to restore this fact which was true before
Jeff's patch was applied.

Telling users to look at the configure script printout
to determine whether they have just built a UCS2
or UCS4 is just not right given its implications.

>>I want to change the --enable-unicode switch back to
>>always use UCS2 as default and add a new option value
>>"tcl" which then triggers the behavior you've added to
>>support _tkinter, ie.
>>
>>--enable-unicode=tcl
>>
>>bases the decision to use UCS2 or UCS4 on the installed
>>TCL interpreter (if there is one).
> 
> Please don't - unless you also go back and re-open the
> bug reports, change the documentation, tell the Linux
> packagers that settings have changed, and so on.
> 
> Why deliberately break what currently works?

It will continue to work - the only change, if any,
is to add --enable-unicode=tcl or --enable-unicode=ucs4
(if you know that TCL uses UCS4) to your configure
setup. The --enable-unicode=ucs4 configure setting
is part of RedHat and SuSE already, so there won't
be any changes necessary.

BTW, SuSE builds TCL using UCS2 which seems to be
the correct choice given this comment in tcl.h:
"""
 * At this time UCS-2 mode is the default and recommended mode.
 * UCS-4 is experimental and not recommended.  It works for the core,
 * but most extensions expect UCS-2.
"""
and _tkinter.c built for a UCS4 Python does work with
a UCS2 TCL.

About the documentation: this still refers to the UCS2
default build and will need to be updated to also
mention UCS4 anyway.

About the bug reports: feel free to assign them to me.
We can have a canned response if necessary, but I
doubt that it will be necessary.

Explicit is better than implicit :-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 13 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] "with" use case: replacing a file

[Phillip J. Eby]

At 07:23 PM 5/13/2005 +1000, Nick Coghlan wrote:
>Guido van Rossum wrote:
> >>P.S. The points regarding non-local flow control in Joel Spolsky's 
> latest Joel
> >>on Software article (especially the links at the end) may have had 
> something to
> >>do with my change of heart. . .
> >
> >
> > I'm a big fan of Joel. Care to share the specific URL for the article
> > you're referring to?
> >
>
>Sorry about that (I was in a hurry this morning). It was here:
>http://www.joelonsoftware.com/articles/Wrong.html

"Wrong" is an excellent title for that article; it's completely wrongheaded 
about exceptions.  :)  Great basic idea (make wrong code look wrong), but 
for all practical purposes the actual specific advice in the article is 
only meaningful for C, where you can't create real types and there are no 
exceptions.  In Python, there are *much* saner solutions to his strawman 
problems.

___
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] Merging PEP 310 and PEP 340-redux?

[Michael Hudson]

Guido van Rossum <[EMAIL PROTECTED]> writes:

> I just read Raymond Chen's rant against control flow macros:
> http://blogs.msdn.com/oldnewthing/archive/2005/01/06/347666.aspx
>
> I think this pretty much kills PEP 340, as well as Nick Coghlan's
> alternative: both proposals let you write a "template" that can be
> used to hide exception-catching code, which is a form of control flow
> (and a pretty important one if you read Chen's rant against exceptions
> referenced by the former, even if you don't agree with everything he
> says in the latter).

Well, I'm not sure what the content of the latter article is, other
than "getting things right can be hard".

BTW, the "else:" on try statements is so very handy for getting this
sort of thing (more) corrent.

> Which leaves us, IMO, with the choice between PEP 310 and my own
> "PEP-340-redux" proposal; these *only* introduce a finally-clause,
> which does not affect the control flow. I'm not counting exceptions
> that might happen in the finally-clause; exceptions can happen
> anywhere anyway. But I am counting the *catching* of an exception as
> control flow, since that means that code past BLOCK (in the same
> function) is reachable even if BLOCK was not executed to completion;
> and this is the argument against PEP 340 and against Nick's
> alternative.
>
> Let's compare and contrast the two remaining competitors:
>
> PEP 310
> ===
>
> Syntax:
> with EXPR [= VAR]:
> BLOCK
>
> Translation:
> [VAR =] abc = EXPR
> if hasattr(abc, "__enter__"):
> abc.__enter__()
> try:
> BLOCK
> finally:
> abc.__exit__()
>
> Pros:
> - dead simple
>
> Cons:
> - can't use a decorated generator for EXPR

Sorry, why not?  [note: I work this out, below, but I still think the
code is worth posting]

import sys

class BlockTemplate(object):
  def __init__(self, g, args, kw):
  self.g = g
  self.args = args
  self.kw = kw
  def __enter__(self):
  self.giter = self.g(*self.args)
  self.giter.next()
  def __exit__(self):
  try:
  self.giter.next()
  except StopIteration:
  pass
  else:
  raise RuntimeError, "generator not exhausted"

def template(g):
def _(*args, **kw):
return BlockTemplate(g, args, kw)
return _

@template
def redirected_stdout(out):
print 'hi'
save_stdout = sys.stdout
sys.stdout = out
yield None
sys.stdout = save_stdout
print 'ho'


## with redirected_stdout(fileobj):
## print 1

output = open("foo", "w")

abc = redirected_stdout(output)
abc.__enter__()
try:
print 1
finally:
abc.__exit__()

output.close()

print repr(open("foo").read())

(this was a bit harder to get right than I expected, mind).

Oh, I guess the point is that with a decorated generator you can yield
a value to be used as VAR, rather than just discarding the value as
here.  Hmm.

> PEP 340 redux
> =
>
> Syntax:
> do EXPR [as VAR]:
> BLOCK
>
> Translation:
> abc = EXPR
> [VAR =] abc.__enter__()
> try:
> BLOCK
> finally:
> abc.__exit__(*"sys.exc_info()") # Not exactly

These two expansions look very similar to me.  What am I missing?

> Pros:
> - can use a decorated generator as EXPR
> - separation of EXPR and VAR (VAR gets what EXPR.__enter__() returns)

Oh!  Hmm.  This is a bit subtle.

I guess I should think about some examples.

> Cons:
> - slightly less simple (__enter__ must return something for VAR;
>   __exit__ takes optional args)

If things were fiddled such that sys.exc_info() return non-Nones when
a finally clause is being executed because of an exception, we don't
really need this wart, do we?

> Everything else is equal or can be made equal. We can make them more
> equal by treating the arguments passed to __exit__() as a separate
> decision, and waffling about whether __enter__() should be optional (I
> think it's a bad idea even for PEP 310; it *could* be made optional
> for PEP 340 redux).

I don't really recall why it's optional in PEP 310.

> Let's also not quibble about the keyword used; again, that can be a
> separate decision. Note that only PEP 310 can use the "VAR = EXPR"
> syntax; PEP 340 redux *must* use "EXPR as VAR" since it doesn't assign
> the value of EXPR to VAR; PEP 310 can be rewritten using this syntax
> as well.
>
> So then the all-important question I want to pose is: do we like the
> idea of using a (degenerate, decorated) generator as a "template" for
> the do-statement enough to accept the slightly increased complexity?

Looking at my above code, no (even though I think I've rendered the
point moot...).  Compare and contrast:

@template
def redirected_stdout(out):
save_stdout = sys.stdout
sys.stdout = out

yield None

sys.stdout = save_stdout

class redirected_stdout(object):

def __init__(self, output):
self.output = output

def __enter__(self):
self.save_stdout = sys.stdout
sys.stdout = self.output

def __exit_

Re: [Python-Dev] Merging PEP 310 and PEP 340-redux?

[Phillip J. Eby]

At 03:05 AM 5/13/2005 -0700, Guido van Rossum wrote:
>So then the all-important question I want to pose is: do we like the
>idea of using a (degenerate, decorated) generator as a "template" for
>the do-statement enough to accept the slightly increased complexity?

Since the "do protocol" is now distinct from the iterator protocol, I don't 
believe a decorator is still required.  The purpose of the decorator was to 
help reduce confusion between the block statement and a "for" loop.  Since 
you can no longer swallow exceptions, there is no downside to using an 
existing generator as the target of a "do" statement.  That is, the concern 
about generators catching StopIteration from a "yield" doesn't matter, as 
they will simply step through to their next yield statement, and then the 
original exception will propagate.


>The added complexity is caused by the need to separate VAR from EXPR
>so that a generator can be used. I personally like this separation; I
>actually like that the "anonymous block controller" is logically
>separate from the variable bound by the construct. From Greg Ewing's
>response to the proposal to endow file objects with __enter__ and
>__exit__ methods, I believe he thinks so too.
>
>Straight up-or-down votes in the full senate are appreciated at this point.

+1.


>On to the secondary questions:
>
>- Today I like the 'do' keyword better; 'with' might confuse folks
>coming from Pascal or VB

+1 on "do EXPR as VAR", where VAR may be any valid LHS of an assignment.


>This means that __exit__ can be called with the following arguments:
>
>abc.__exit__(True) - normal completion of BLOCK
>
>abc.__exit__(False) - BLOCK was left by a non-local goto 
>(break/continue/return)
>
>abc.__exit__(False, t, v, tb) - BLOCK was left by an exception
>
>(An alternative would be to always call it with 4 arguments, the last
>three being None in the first two cases.)

I'm not sure the extra argument is a good idea; doesn't this introduce the 
same sort of invisible control flow as swallowing exceptions?  Also, since 
the block controller can't actually change the control flow, I'm having a 
hard time thinking of any actual use cases for this information.


>If we adopt PEP 340 redux, it's up to the decorator for degenerate
>generators to decide how to pass this information into the generator;
>if we adopt PEP 342 ("continue EXPR") at the same time, we can let the
>yield-expression return a 4-tuple (oke, t, v, tb). Most templates can
>ignore this information (so they can just use a yield-statement).

I was going to propose having a generator-iterator's __exit__() raise the 
triple inside the generator, or raise StopIteration inside the generator if 
there is no triple.  I'd ideally also like close() as a synonym for 
__exit__() with no arguments.  Although these are properly the subject of 
PEPs 288 and 325 respectively, I felt this would elegantly bring them both 
to closure.

However, after thinking it through, I realized that I don't see any obvious 
way to make __exit__ reusable for PEPs 288 and 325, because for 288 at 
least, I'd want __exit__ to either return the next yielded value or raise 
StopIteration.  But, this isn't compatible with the "do protocol"'s needs, 
unless the "do protocol" suppressed StopIteration, and that doesn't seem 
like such a good idea.

It seems to me that passing exceptions into a generator does in fact 
require a distinct method.  But, I still do believe that 
generator-iterators can have predefined __enter__ and __exit__ methods 
without the need for a decorator.


>PS. I've come up with another interesting use case: block signals for
>the duration of a block. This could be a function in the signal
>module, e.g. signal.blocking([ist of signals to block]). The list
>would default to all signals. Similar signal.ignoring().

Sweet.  You could also use it for temporary signal handling, i.e. "set this 
signal handler for the duration of the block".  Sort of the same class of 
"make sure I restore a global I'm tampering with" use case as redirecting 
stdout, and Tim Peters' Decimal context use cases.

___
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] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum]

[Michael Hudson, after much thinking aloud]
> Oh, I guess the point is that with a decorated generator you can yield
> a value to be used as VAR, rather than just discarding the value as
> here.  Hmm.

Right. (I thought it was worth quoting this for the benefit of other
who went down the same trail but didn't quite make it to this
destination.)

> If things were fiddled such that sys.exc_info() return non-Nones when
> a finally clause is being executed because of an exception, we don't
> really need this wart, do we?

The problem is that sys.exc_info() almost always returns *something*
-- it's usually the last exception that was *ever* caught, except in
certain circumstances.

Phillip wrote on the same issue:
> I'm not sure the extra argument is a good idea; doesn't this introduce the
> same sort of invisible control flow as swallowing exceptions?  Also, since
> the block controller can't actually change the control flow, I'm having a
> hard time thinking of any actual use cases for this information.

The 'oke' argument is so that the author of transactional() can decide
what to do with a non-local goto: commit, rollback or hit the author
over the head with a big stick.

[Michael again]
> Compare and contrast:
> 
> @template
> def redirected_stdout(out):
> save_stdout = sys.stdout
> sys.stdout = out
> 
> yield None
> 
> sys.stdout = save_stdout
> 
> class redirected_stdout(object):
> 
> def __init__(self, output):
> self.output = output
> 
> def __enter__(self):
> self.save_stdout = sys.stdout
> sys.stdout = self.output
> 
> def __exit__(self):
> sys.stdout = self.save_stdout
> 
> The former is shorter and contains less (well, no) 'self.'s, but I
> think I find the latter somewhat clearer.

Tastes differ. I think the generator wins; more so when there's more
state to remember.

[Michael quoting Guido]
> > The added complexity is caused by the need to separate VAR from EXPR
> > so that a generator can be used. I personally like this separation; I
> > actually like that the "anonymous block controller" is logically
> > separate from the variable bound by the construct.
> 
> Nevertheless, I think I actually like this argument!

(Repeated for the benefit of others.)

> > Straight up-or-down votes in the full senate are appreciated at this point.
> 
> +1 for the PEP 340 variant.

-- 
--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] Merging PEP 310 and PEP 340-redux?

[Paul Moore]

On 5/13/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Tastes differ. I think the generator wins; more so when there's more
> state to remember.
[...]
> > > Straight up-or-down votes in the full senate are appreciated at this 
> > > point.
> >
> > +1 for the PEP 340 variant.

I am also +1 for the PEP 340 variant. I can see the value in
generators when state management starts to become more complex.

No significant opinion on choice of keyword.

I don't follow the subtleties for the more elaborate __exit__, so I'll
pass on that one as well.

Paul.
___
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] Merging PEP 310 and PEP 340-redux?

[Phillip J. Eby]

At 08:41 AM 5/13/2005 -0700, Guido van Rossum wrote:
>The 'oke' argument is so that the author of transactional() can decide
>what to do with a non-local goto: commit, rollback or hit the author
>over the head with a big stick.

Since this is just a replacement for a try/except/finally block, I'd expect 
that in a transactional case that a non-local goto would work the same as 
any other non-exception exit.

ISTM that the resource block use cases are:

* Save the current state of something, modify it, and then restore the old 
state once the block completes (try/finally, used for locking, redirection, 
signals, decimal context, etc.)

* Automatically roll back partially-done work in case of exception, and/or 
"roll forward" completed work (try/except/else, used for "transaction" 
scenarios)

* Release allocated resource(s) after use (try/finally, used to close files 
and suchlike)

None of these, AFAICT, benefit from differing behavior in the presence of 
nonlinear (but non-exceptional) control flow.  It just seems too magical to 
me in the new context.  When we were talking about a "block" construct or 
user-defined syntax, it made more sense because you could actually redefine 
the *meaning* of those constructs to some extent -- and because the 
*target* of the break and continue statements at least was the block 
itself, not some containing block.

___
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] Tidier Exceptions

[Tim Peters]

[Guido, on string exceptions]
> ...
> Last I looked Zope 2 still depended on them (especially in the
> bowels of ZODB); maybe Tim Peters knows if that's still the
> case.

Certainly none of that in ZODB, or in ZRS.  Definitely some in Zope 2.6:



I don't think there are any string exceptions in Zope 2.7, Zope 2.8,
or Zope 3.  Development on Zope 2.6 stopped about a year ago, so the
2.6 story will never change; by the same token, no version of Python
after 2.3.5 will ever be approved for use with 2.6 anyway.
___
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] Merging PEP 310 and PEP 340-redux?

[Steven Bethard]

On 5/13/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> So then the all-important question I want to pose is: do we like the
> idea of using a (degenerate, decorated) generator as a "template" for
> the do-statement enough to accept the slightly increased complexity?

+0.  I'm not thoroughly convinced that generators are that much easier
to read than a class.  But I don't find them hard to read, and I think
it would only take a little effort to learn that generators might not
always be intended to build iterators.

If we do support generators in do-statements, I'd like their
__enter__() and __exit__() methods (if possible) to have semantics
like Nick Coghlan suggested[1], so that:
 * __enter__() raises an exception if next() has already been called, and
 * __exit__() raises an exception if StopIteration is not raised
The first makes sure that the generator is only used once, and the
second makes sure that there is only one yield on the given control
path through the generator.  In all but the most sick and twisted
code, raising exceptions like this will be identifying errors in how
the generator was written.

> Straight up-or-down votes in the full senate are appreciated at this point.

+1 on the PEP 340 redux semantics.

> On to the secondary questions:
> 
> - Today I like the 'do' keyword better; 'with' might confuse folks
> coming from Pascal or VB

+1 on using 'do'.

> - I have a more elaborate proposal for __exit__'s arguments. Let the
> translation be as follows:
[snip]
> abc.__exit__(True) - normal completion of BLOCK
> 
> abc.__exit__(False) - BLOCK was left by a non-local goto 
> (break/continue/return)
> 
> abc.__exit__(False, t, v, tb) - BLOCK was left by an exception

-1. This looks like a fair bit of added complexity for not much gain. 
The only example that even *might* make use of this was the
transactional one, and I haven't yet seen a use case where it actually
*is*.

The simpler semantics give you the difference between a normal exit
and an exceptional exit.  I'd like to see an example that needs to
know the difference between block completion exit and a
break/continue/return exit before I'd want to make PEP 340 redux this
much more complex.

STeVe

[1] http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
-- 
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum]

[Guido]
> >The 'oke' argument is so that the author of transactional() can decide
> >what to do with a non-local goto: commit, rollback or hit the author
> >over the head with a big stick.

[Phillip J. Eby]
> Since this is just a replacement for a try/except/finally block, I'd expect
> that in a transactional case that a non-local goto would work the same as
> any other non-exception exit.
> 
> ISTM that the resource block use cases are:
> 
> * Save the current state of something, modify it, and then restore the old
> state once the block completes (try/finally, used for locking, redirection,
> signals, decimal context, etc.)
> 
> * Automatically roll back partially-done work in case of exception, and/or
> "roll forward" completed work (try/except/else, used for "transaction"
> scenarios)
> 
> * Release allocated resource(s) after use (try/finally, used to close files
> and suchlike)
> 
> None of these, AFAICT, benefit from differing behavior in the presence of
> nonlinear (but non-exceptional) control flow.  It just seems too magical to
> me in the new context.  When we were talking about a "block" construct or
> user-defined syntax, it made more sense because you could actually redefine
> the *meaning* of those constructs to some extent -- and because the
> *target* of the break and continue statements at least was the block
> itself, not some containing block.

That works for me; I was just hypothesizing about the needs of others,
but personally I'm fine with not knowing. I guess part of my
motivation is also that this information is readily available
intenally when a finally-clause is executed, since when the clause
completes a pending non-local goto has to be resumed. But there's no
reason to expose *all* internal state information...

So the signature of __exit__ is just what sys.exc_info() returns.

-- 
--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] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum]

[Steven Bethard]
> +0.  I'm not thoroughly convinced that generators are that much easier
> to read than a class.  But I don't find them hard to read, and I think
> it would only take a little effort to learn that generators might not
> always be intended to build iterators.

I am proposing (like Phillip Eby in his response to PEP 340) to use a
special decorator that turns a generator into a "do-template", so the
intention is evident from the generator declaration.

> If we do support generators in do-statements, I'd like their
> __enter__() and __exit__() methods (if possible) to have semantics
> like Nick Coghlan suggested[1], so that:
>  * __enter__() raises an exception if next() has already been called, and
>  * __exit__() raises an exception if StopIteration is not raised

I guess you missed my post where I gave the code for the decorator; it
does exactly that.

> The simpler semantics give you the difference between a normal exit
> and an exceptional exit.  I'd like to see an example that needs to
> know the difference between block completion exit and a
> break/continue/return exit before I'd want to make PEP 340 redux this
> much more complex.

I agreed to that in my response to Phillip Eby. I do want to pass the
exception into __exit__ so that it can be logged, for example.

-- 
--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] "with" use case: replacing a file

[Nick Coghlan]

Phillip J. Eby wrote:
> At 07:23 PM 5/13/2005 +1000, Nick Coghlan wrote:
>> Sorry about that (I was in a hurry this morning). It was here:
>> http://www.joelonsoftware.com/articles/Wrong.html
> 
> "Wrong" is an excellent title for that article; it's completely 
> wrongheaded about exceptions.  :)  Great basic idea (make wrong code 
> look wrong), but for all practical purposes the actual specific advice 
> in the article is only meaningful for C, where you can't create real 
> types and there are no exceptions.  In Python, there are *much* saner 
> solutions to his strawman problems.

I have to agree. However, having had to deal with C++'s excuse for exceptions 
(and the effects of C programmers being let loose on them), I can understand 
where he is coming from.

And the basic idea of flow control you can't see being a potential problem is 
sound. For exceptions in general, the benefits are worth the costs, but I don't 
think the same can be said for allowing statement templates the power to 
suppress them.

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

[Python-Dev] Pre-PEP: Unifying try-except and try-finally

[Jim Jewett]

[Guido]
>>> Can I go ahead and approve this now?

[Michael Hudson]
>> While I see the cost of this PEP being pretty small, I see the benefit
>> the same way too.

[Guido]
> Sure. Let me approve it and we'll see if someone cares enough to implement it.

No one will scream if you approve it, but when you asked permission
it seemed somehow serious and permanent.  By itself, the change is 
fine -- but there is still a nagging worry that it might interact badly with 
PEP-340 (or 3XX) Resource Management blocks.

(1)  If people could write a single try statement instead of nesting them,
would they be less likely to factor the locking out into a separate statement?

(2)  If 340 ends up as a simple version that doesn't handle fancy except:
processing, would this change make PEP 340 look crippled in comparison?
Would people avoid Resource Managers as a matter of style?

-jJ
___
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] Merging PEP 310 and PEP 340-redux?

[Nick Coghlan]

Guido van Rossum wrote:
> I just read Raymond Chen's rant against control flow macros:
> http://blogs.msdn.com/oldnewthing/archive/2005/01/06/347666.aspx
> 
> I think this pretty much kills PEP 340, as well as Nick Coghlan's
> alternative: both proposals let you write a "template" that can be
> used to hide exception-catching code, which is a form of control flow
> (and a pretty important one if you read Chen's rant against exceptions
> referenced by the former, even if you don't agree with everything he
> says in the latter).

It seems the effect of Raymond's articles on you was similar to their effect on 
me :)

> Straight up-or-down votes in the full senate are appreciated at this point.

PEP 340 redux for me (as you might have guessed) - I think the transaction() 
use 
case is a genuinely useful one. The ability to access the return value of 
__enter__() is also more useful than simply duplicating what could be achieved 
by an assignment on the line before the user defined statement.

> On to the secondary questions:
> 
> - Today I like the 'do' keyword better; 'with' might confuse folks
> coming from Pascal or VB

I think 'do' can be made to read correctly in more contexts that 'with'. The 
lack of a corresponding 'while' or 'until' should eliminate any temptation to 
see it as a loop.

The 'with' keyword also means I keep wanting the magic methods to be called 
"__acquire__" and "__release__" (and those would be harder to type. . .)

> - I have a more elaborate proposal for __exit__'s arguments. Let the
> translation be as follows:

I plan to rewrite my proposal based on this suggestion, just to explore the 
ramifications. I think it will turn out quite nicely.

The ban on yielding inside try/finally will need to be extended to yielding 
inside user defined statements until such time as an iterator finalisation 
protocol is chosen, though.

> (An alternative would be to always call it with 4 arguments, the last
> three being None in the first two cases.)

The former is probably tidier. __exit__() method implementations which don't 
care about the exception details can still use "*exc_info" in the argument 
signature, while those that want to use the information can just name the three 
parts without needing to specify the "=None" defaults.

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] Merging PEP 310 and PEP 340-redux?

[Fredrik Lundh]

Michael Hudson wrote:

> Looking at my above code, no (even though I think I've rendered the
> point moot...).  Compare and contrast:
>
> @template
> def redirected_stdout(out):
> save_stdout = sys.stdout
> sys.stdout = out
>
> yield None
>
> sys.stdout = save_stdout
>
> class redirected_stdout(object):
>
> def __init__(self, output):
> self.output = output
>
> def __enter__(self):
> self.save_stdout = sys.stdout
> sys.stdout = self.output
>
> def __exit__(self):
> sys.stdout = self.save_stdout
>
> The former is shorter and contains less (well, no) 'self.'s, but I
> think I find the latter somewhat clearer.

the same argument could be used (and was probably used) against
generators: why not just use __getitem__ and instance state?

as soon as you write something longer than four lines, using more
than one state variable, you'll find that generator-based code is a
lot more readable.





___
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] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum]

[Nick Coghlan]
> The ban on yielding inside try/finally will need to be extended to yielding
> inside user defined statements until such time as an iterator finalisation
> protocol is chosen, though.

Ah! Good point. This breaks PEP 340 example 5. No big deal, but worth noting.

-- 
--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] Merging PEP 310 and PEP 340-redux?

[Fredrik Lundh]

Guido van Rossum wrote:

> PEP 340 redux
> =
>
> Syntax:
> do EXPR [as VAR]:
> BLOCK
>
> Translation:
> abc = EXPR
> [VAR =] abc.__enter__()
> try:
> BLOCK
> finally:
> abc.__exit__(*"sys.exc_info()") # Not exactly
>
> Pros:
> - can use a decorated generator as EXPR
> - separation of EXPR and VAR (VAR gets what EXPR.__enter__() returns)
>
> Cons:
> - slightly less simple (__enter__ must return something for VAR;
>   __exit__ takes optional args)

what happened to the original "yield the target object" solution?  or did
I just dream that?





___
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] Merging PEP 310 and PEP 340-redux?

[Nick Coghlan]

Phillip J. Eby wrote:
> At 08:41 AM 5/13/2005 -0700, Guido van Rossum wrote:
> 
>>The 'oke' argument is so that the author of transactional() can decide
>>what to do with a non-local goto: commit, rollback or hit the author
>>over the head with a big stick.

> * Automatically roll back partially-done work in case of exception, and/or 
> "roll forward" completed work (try/except/else, used for "transaction" 
> scenarios)

Doing transactions with try/except/else is not quite correct, since using any 
of 
the three non-local goto's actually executes neither the commit nor the 
rollback 
(of course, this is where Guido's stick comment comes into play. . .).

However, I'm fine with declaring that, from the perspective of a statement 
template, 'return', 'break' and 'continue' are all 'non-exceptional exits', and 
so templates like transaction() are expected to treat them as such.

Picking one way and enforcing it by restricting the information seen by 
__exit__() also seems to be a much better option than allowing the possibility 
of:

   do bobs.transaction():
   break
   # Triggers a rollback!

   do alices.transaction():
   break
   # Triggers a commit!

Going the 'non-exceptional exits' route also saves inventing a pseudo-exception 
to stand in for the 3 non-local goto statements (such a pseudo-exception would 
recreate the above behavioural hole, anyway).

An exceptional exit can be forced if a non-local goto needs to be executed in 
response to a failure:

   class AbortDo(Exception): pass

   do alices.transaction():
   break
   # Triggers a commit (non-exceptional exit)

   try:
   do alices.transaction():
   raise AbortDo
   # Triggers a rollback (exceptional exit)
   except AbortDo:
   break

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] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum]

[Guido van Rossum]
> > Cons:
> > - slightly less simple (__enter__ must return something for VAR;
> >   __exit__ takes optional args)

[Fredrik Lundh]
> what happened to the original "yield the target object" solution?  or did
> I just dream that?

Don't worry, that works when you use a generator. It just doesn't work
when you're using a class.

The do-statement proposal is a bit ambiguous: on the one hand it's not
strongly tied to generators, since you can easily write a class with
__enter__ and __exit__ methods; on the other hand its essential
difference from PEP 310 is that you *can* use a generator, given a
suitable decorator.

BTW, we need a name for such a decorated generator that only yields
once. I propose to call it a degenerator.

-- 
--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] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum]

[Nick Coghlan]
> However, I'm fine with declaring that, from the perspective of a statement
> template, 'return', 'break' and 'continue' are all 'non-exceptional exits', 
> and
> so templates like transaction() are expected to treat them as such.

Me too. The argument that made me realize this is okay came after
reading Raymond Chen's rant about control-flow macros: when you catch
an exception, you don't know how much of the try-block was executed
successfully, and neither does the author of that block; but when you
"catch" a non-local goto, you must assume that the block's author
knows what they are doing, so at least *they* know exactly which code
was executed (everything up to the break/continue/return) and which
wasn't. So the argument about rolling back indeterminate results
doesn't hold. If they want the transaction to fail, they should raise
an exception.

I really need to start writing PEP 343 to capture this particular
solution more carefully.

-- 
--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] Python's Unicode width default (New Py_UNICODE doc)

[Martin v. Löwis]

M.-A. Lemburg wrote:
> I'm not breaking anything, I'm just correcting the
> way things have to be configured in an effort to
> bring back the cross-platforma configure default.

Your proposed change will break the build of Python
on Redhat/Fedora systems.

> I'm talking about the *configure* default, not the
> default installation you find on any particular
> platform (this remains a platform decision to be made
> by the packagers).

Why is it good to have such a default? Why is that
so good that its better than having Tkinter work
by default?

> The main point is that we can no longer tell users:
> if you run configure without any further options,
> you will get a UCS2 build of Python.

It's not a matter of telling the users "no longer".
"We" currently don't tell that in any documentation;
if you had been telling that users, you were wrong.

./configure --help says that the default for
--enable-unicode is "yes".

> I want to restore this fact which was true before
> Jeff's patch was applied.

I understand that you want that. I'm opposed.

> Telling users to look at the configure script printout
> to determine whether they have just built a UCS2
> or UCS4 is just not right given its implications.

Right. We should tell them what the procedure is that
is used.

> It will continue to work - the only change, if any,
> is to add --enable-unicode=tcl or --enable-unicode=ucs4
> (if you know that TCL uses UCS4) to your configure
> setup. The --enable-unicode=ucs4 configure setting
> is part of RedHat and SuSE already, so there won't
> be any changes necessary.

Yes, but users of these systems need to adjust.

Regards,
Martin
___
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] Merging PEP 310 and PEP 340-redux?

[Brett C.]

Guido van Rossum wrote:
[SNIP]
> Straight up-or-down votes in the full senate are appreciated at this point.
> 

PEP 340 redux gets my +1; I think using generators will become more obviously
useful to people when, as Fredrick pointed out, your code grows more than a few
lines long.

> On to the secondary questions:
> 
> - Today I like the 'do' keyword better; 'with' might confuse folks
> coming from Pascal or VB
> 

 -0; I can deal with either, but I just like how 'with' reads more.

> - I have a more elaborate proposal for __exit__'s arguments. Let the
> translation be as follows:
> 
> abc = EXPR
> [VAR =] abc.__enter__()
> oke = False  # Pronounced "okay"
> exc = ()
> try:
> try:
> BLOCK
> oke = True
> except:
> exc = sys.exc_info()
> raise
> finally:
> abc.__exit__(oke, *exc)
> 
> This means that __exit__ can be called with the following arguments:
> 
> abc.__exit__(True) - normal completion of BLOCK
> 
> abc.__exit__(False) - BLOCK was left by a non-local goto 
> (break/continue/return)
> 
> abc.__exit__(False, t, v, tb) - BLOCK was left by an exception
> 
> (An alternative would be to always call it with 4 arguments, the last
> three being None in the first two cases.)
> 
> If we adopt PEP 340 redux, it's up to the decorator for degenerate
> generators to decide how to pass this information into the generator;
> if we adopt PEP 342 ("continue EXPR") at the same time, we can let the
> yield-expression return a 4-tuple (oke, t, v, tb). Most templates can
> ignore this information (so they can just use a yield-statement).
> 

I think a later email discussed just passing in the values from sys.exc_info(),
and I like that more since it will be None if no exception was raised and thus
straight-forward to detect without being overly verbose with the oke argument.

-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] Tidier Exceptions

[Brett C.]

Guido van Rossum wrote:
> [Brett C.]
> 
>>Seems like, especially if we require inheritance from a base exception class 
>>in
>>Python 3000, exceptions should have standard 'arg' and 'traceback' attributes
>>with a possible 'context' attribute (or always a 'context' attribute set to
>>None if not a chained exception).
>>
>>I don't think there is other data normally associated with exceptions is 
>>there?
> 
> 
> I despise the "arg" argument -- I like Java's "message" concept better.
> 

Works for me.

> 
>>I really need to get off my ass one of these days and just write a PEP 
>>targeted
>>for Python 3000 with base inheritance, standard attributes (including 
>>exception
>>chains), reworking the built-in exception inheritance hierarchy, and whether
>>bare 'except' statements should go or only catch certain exceptions.  Could
>>probably stand to break it up until multiple PEPs, though.  =)
> 
> 
> +1.
> 
> I think these things are sufficiently closely related to keep them all
> in one PEP.
> 

OK, I will see if I can get to the PEP this summer assuming I have time
(waiting on official offer on an internship that will keep me busy this summer,
but I am hoping to spend my free time Python hacking; got to finish the AST
branch some day  =).  Probably will also write it up in parts as outlined above
so that I can just get parts out quickly without being held up by discussions
about other sections.

-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] Tidier Exceptions

[Brett C.]

Guido van Rossum wrote:
> [Ka-Ping Yee]
> 
>>Maybe bare 'except' should be spelled 'except *'.
> 
> 
> -1.
> 
> 
>>I don't think it can be removed altogether because sometimes you just
>>need to be able to do magic, but it can be made a little more explicit.
> 
> 
> Assuming a single root of the exception tree, you can spell it
> explicitly as "except Exception" or perhaps (if that's not the root)
> "except Raisable" (cf. Java's Throwable).
> 

There are two possibilities for this.  Either we make all 'except' branches
explicit, or we make bare 'except' branches okay, but not catch the base
exception but the non-critical base exception.

The thinking is that BaseException be the bottom exception, with Exception
being inherited from for non-showstopping exceptions and CriticalException
being for exceptions that you really should not catch unless you mean it
(KeyboardInterrupt, SystemError, MemoryError, etc.).  That would make the bare
'except' much more reasonable.

But personally I still prefer requiring explicit 'except' branches and just
making sure the non-critical base exception is the easier one to type to make
sure people use it by default.

-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] Merging PEP 310 and PEP 340-redux?

[Shane Holloway (IEEE)]

+1 PEP 340 redux (although I marginally prefer the "with" keyword)

Guido van Rossum wrote:
> So then the all-important question I want to pose is: do we like the
> idea of using a (degenerate, decorated) generator as a "template" for
> the do-statement enough to accept the slightly increased complexity?
> The added complexity is caused by the need to separate VAR from EXPR
> so that a generator can be used. I personally like this separation; I
> actually like that the "anonymous block controller" is logically
> separate from the variable bound by the construct. From Greg Ewing's
> response to the proposal to endow file objects with __enter__ and
> __exit__ methods, I believe he thinks so too.

+1 to support template generators.  I think it allows for more 
flexibility on the class implementations as well, even if most of them 
return self.


> - Today I like the 'do' keyword better; 'with' might confuse folks
> coming from Pascal or VB

As a former pascal/delphi guy, I wasn't really confused.  ;)

+1 with
+0 do

> - I have a more elaborate proposal for __exit__'s arguments. Let the
> translation be as follows:

+1 -- as long as I can get information about how the block exited, I'm 
happy.

> If we adopt PEP 340 redux, it's up to the decorator for degenerate
> generators to decide how to pass this information into the generator;
> if we adopt PEP 342 ("continue EXPR") at the same time, we can let the
> yield-expression return a 4-tuple (oke, t, v, tb). Most templates can
> ignore this information (so they can just use a yield-statement).

+1 makes sense to me...
___
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] Chained Exceptions

[Brett C.]

Guido van Rossum wrote:
> [Guido]
> 
>>>What if that method catches that exception?
> 
> 
> [Ka-Ping Yee]
> 
>>Did you mean something like this?
>>
>>def handle():
>>try:
>>open('spamspamspam')
>>except:
>>catchit()
>># point A
>>...
>>
>>def catchit():
>>try:
>>1/0
>>except:
>>pass
>>
>>Then there's no exception to propagate, so it doesn't matter.
>>Once we're get to point A, the division by zero is long forgotten.
> 
> 
> But at what point does the attaching happen? If I catch the
> ZeroDivisionException inside catchit() and inspects its context
> attribute, does it reference the IOError instance raised by
> open('spamspamspam')?

Yes, at least in the way I am imagining this being implemented.  I was thinking
that when an exception happens, the global exception variable is checked to see
if it has a value.  If it does that gets assigned to the new exception's
'context' attribute and the new exception gets assigned to the global exception
variable.

> This could potentially cause a lot of extra
> work: when an inner loop that raises and catches lots of exceptions is
> invoked in the context of having caught an exception at some outer
> level, the inner loop keeps attaching the outer exception to each
> exception raised.
> 

[this also contains a partial answer to Philip's email also in this thread]

Maybe, but as long as caught exceptions get cleared that should be an issue.
Would this be solved if, when an 'except' branch is exited, exceptions are
cleared?  So, in the above example, once the 'pass' is hit in catchit() no
exception is considered active any longer.  This could be done with a CLEAR_EXC
opcode very easily inserted at the end of an 'except' branch by the compiler.

This would require explicit re-raising of exceptions to keep them alive after
an 'except' ends, but I think that is actually a good idea and since this might
all wait until Python 3000 anyway we don't need to worry about the semantic 
change.

-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] Python's Unicode width default (New Py_UNICODE doc)

[M.-A. Lemburg]

Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
> 
>>I'm not breaking anything, I'm just correcting the
>>way things have to be configured in an effort to
>>bring back the cross-platforma configure default.
> 
> Your proposed change will break the build of Python
> on Redhat/Fedora systems.

You know that this is not true. Python will happily
continue to compile on these systems.

>>I'm talking about the *configure* default, not the
>>default installation you find on any particular
>>platform (this remains a platform decision to be made
>>by the packagers).
> 
> 
> Why is it good to have such a default? Why is that
> so good that its better than having Tkinter work
> by default?

It is important to be able to rely on a default that
is used when no special options are given. The decision
to use UCS2 or UCS4 is much too important to be
left to a configure script.

>>The main point is that we can no longer tell users:
>>if you run configure without any further options,
>>you will get a UCS2 build of Python.
> 
> 
> It's not a matter of telling the users "no longer".
> "We" currently don't tell that in any documentation;
> if you had been telling that users, you were wrong.
>
> ./configure --help says that the default for
> --enable-unicode is "yes".

Let's see:
http://www.python.org/peps/pep-0100.html
http://www.python.org/peps/pep-0261.html
http://www.python.org/doc/2.2.3/whatsnew/node8.html

Apart from the mention in the What's New document for
Python 2.2 and a FAQ entry, the documentation doesn't
mention UCS4 at all.

However, you're right: the configure script should print
"(default if ucs2)".

>>I want to restore this fact which was true before
>>Jeff's patch was applied.
> 
> 
> I understand that you want that. I'm opposed.

Noted.

>>Telling users to look at the configure script printout
>>to determine whether they have just built a UCS2
>>or UCS4 is just not right given its implications.
> 
> Right. We should tell them what the procedure is that
> is used.

No, we should make it an explicit decision by the
user running the configure script.

BTW, a UCS4 TCL is just as non-standard as a UCS4
Python build. Non-standard build options should never be
selected by a configure script all by itself.

>>It will continue to work - the only change, if any,
>>is to add --enable-unicode=tcl or --enable-unicode=ucs4
>>(if you know that TCL uses UCS4) to your configure
>>setup. The --enable-unicode=ucs4 configure setting
>>is part of RedHat and SuSE already, so there won't
>>be any changes necessary.
> 
> Yes, but users of these systems need to adjust.

Not really: they won't even notice the change in the
configure script if they use the system provided Python
versions. Or am I missing something ?


Regardless of all this discussion, I think we should
try to get _tkinter.c to work with a UCS4 TCL version
as well. The conversion from UCS4 (Python) to UCS2 (TCL)
is already integrated, so adding support for the other way
around should be  rather straight forward.

Any takers ?

Regards,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 13 2005)
 >>> Python/Zope Consulting and Support ...http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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] Chained Exceptions

[Guido van Rossum]

[Brett C.]
> Maybe, but as long as caught exceptions get cleared that should be an issue.
> Would this be solved if, when an 'except' branch is exited, exceptions are
> cleared?  So, in the above example, once the 'pass' is hit in catchit() no
> exception is considered active any longer.  This could be done with a 
> CLEAR_EXC
> opcode very easily inserted at the end of an 'except' branch by the compiler.

Sure, but that would be backwards incompatible. There's plenty of code
that expects sys.exc_info() to continue to return the caught exception
*outside* the except block. This is all incredibly tricky, to some
extent for backwards compatibility reasons (please read the source
code for maintaining the exc_info data!).

In Python 3000, I think we can get rid of sys.exc_info() altogether
once we place the traceback in the exception object as the 'traceback'
attribute: if you want this info, all you need is write

except SomeException, err:
# now type is err.__class__, value is err, and traceback is
err.traceback.

If you want to have this with an "except:" clause, you can just catch
'Exception' or perhaps 'BaseException'. This isn't possible in Python
2.x since there's no single base class.

-- 
--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] PEP 343 - Abstract Block Redux

[Guido van Rossum]

I've written up the specs for my "PEP 340 redux" proposal as a
separate PEP, PEP 343.

http://python.org/peps/pep-0343.html

Those who have been following the thread "Merging PEP 310 and PEP
340-redux?" will recognize my proposal in that thread, which received
mostly positive responses there.

Please review and ask for clarifications of anything that's unclear.

-- 
--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] Merging PEP 310 and PEP 340-redux?

[Greg Ewing]

Guido van Rossum wrote:
> So then the all-important question I want to pose is: do we like the
> idea of using a (degenerate, decorated) generator as a "template" for
> the do-statement enough to accept the slightly increased complexity?

I can't see how this has anything to do with whether
a generator is used or not. Keeping them separate
seems to be a useful thing in its own right.

Greg

___
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] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum]

[Guido van Rossum]
> > So then the all-important question I want to pose is: do we like the
> > idea of using a (degenerate, decorated) generator as a "template" for
> > the do-statement enough to accept the slightly increased complexity?

[Greg Ewing]
> I can't see how this has anything to do with whether
> a generator is used or not. Keeping them separate
> seems to be a useful thing in its own right.

Assuming by "them" you mean the value of EXPR and the value assigned
to VAR, I don't care how this conclusion is reached, as long as their
separation is seen as a useful thing. :-)

I came up with the idea of making them separate when I tried to figure
out how to decorate a generator to drive a PEP-310-style
with-statement, and found I couldn't do it for the opening() example.
(Michael Hudson illustrated this nicely in his reply in this thread.
:-)

But it's fine if the separation is considered generally useful even
without thinking of generators.

-- 
--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] Merging PEP 310 and PEP 340-redux?

[Greg Ewing]

Here's my vote on things at the moment:

+1 on

   do EXPR as VAR:
 ...

+1 on keeping the EXPR and VAR distinct.

+1 on keeping the do and generator protocols distinct.

+1 on not going out of our way to let the controller
catch exceptions or alter control flow. Let's keep it
as simple as we can.

-0.7 on directly giving generators do-protocol methods.
I'm not yet convinced that encouraging people to use
generators to implement block controllers is a good
idea. If we blur the distinction too much at this
stage, we may regret it later if we come up with a
better idea. Also I don't see that people will be
writing block controllers anywhere near as often as
iterators, so writing classes for them isn't going to
be a big chore. And people can always use a
do-protocol-to-generator adaptor if they really want.

Greg


___
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] Merging PEP 310 and PEP 340-redux?

[Nick Coghlan]

Guido van Rossum wrote:
> BTW, we need a name for such a decorated generator that only yields
> once. I propose to call it a degenerator.

Cute, but 'template generator' may be clearer (that's what I've been calling 
them so far, anyway). Then 'iterator generator' can be used to explicitly refer 
to generators intended for use in for loops.

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] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum]

[Greg Ewing]
> -0.7 on directly giving generators do-protocol methods.

I'm -1 on this myself.

> I'm not yet convinced that encouraging people to use
> generators to implement block controllers is a good
> idea. If we blur the distinction too much at this
> stage, we may regret it later if we come up with a
> better idea. Also I don't see that people will be
> writing block controllers anywhere near as often as
> iterators, so writing classes for them isn't going to
> be a big chore. And people can always use a
> do-protocol-to-generator adaptor if they really want.

Right. I'm +0 on adding a standard module defining a do_template
decorator that turns a degenerate generator into a do-statement
controller.

-- 
--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 - Abstract Block Redux

[Phillip J. Eby]

At 05:13 PM 5/13/2005 -0700, Guido van Rossum wrote:
>I've written up the specs for my "PEP 340 redux" proposal as a
>separate PEP, PEP 343.
>
>http://python.org/peps/pep-0343.html
>
>Those who have been following the thread "Merging PEP 310 and PEP
>340-redux?" will recognize my proposal in that thread, which received
>mostly positive responses there.
>
>Please review and ask for clarifications of anything that's unclear.

May I suggest this alternative translation in the "Specification" section:

 abc = EXPR
 __args = ()  # pseudo-variable, not visible to the user

 try:
 VAR = abc.__enter__()
 try:
 BLOCK
 except:
 __args = sys.exc_info()
 finally:
 abc.__exit__(*__args)

While slighly more complex than the current translation, the current 
translation seems a bit misleading to me.  OTOH, that may simply be because 
I see the *sys.exc_info() part and immediately wonder what happens when 
there was no exception, and sys.exc_info() contains some arbitrary previous 
data...

Also, one question: will the "do protocol" be added to built-in "resource" 
types?  That is, locks, files, sockets, and so on?  Or will there instead 
be "macros" like the "opening" and "locking" templates?  I notice that 
grammatically, "do gerund" works a lot better than "do noun", so all of 
your examples are words like locking, blocking, opening, redirecting, and 
so on.  This makes it seem awkward for e.g. "do self.__lock", which doesn't 
make any sense.  But the extra call needed to make it "do 
locking(self.__lock)" seems sort of gratuitous.

It makes me wonder if "with" or "using" or some similar word that works 
better with nouns might be more appropriate, as then it would let us just 
add the resource protocol to common objects, and still read well.  For 
example, a Decimal Context object might implement __enter__ by setting 
itself as the thread-local context, and __exit__ by restoring the previous 
context."do aDecimalContext" doesn't make much sense, but "with 
aDecimalContext" or "using aDecimalContext" reads quite nicely.
 

___
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 - Abstract Block Redux

[Nick Coghlan]

Guido van Rossum wrote:
> I've written up the specs for my "PEP 340 redux" proposal as a
> separate PEP, PEP 343.
> 
> http://python.org/peps/pep-0343.html
> 
> Those who have been following the thread "Merging PEP 310 and PEP
> 340-redux?" will recognize my proposal in that thread, which received
> mostly positive responses there.
> 
> Please review and ask for clarifications of anything that's unclear.

+1 here.

The stdout redirection example needs to be corrected to avoid yielding inside a 
try/finally though:

 5. Redirect stdout temporarily:

 @do_template
 def redirecting_stdout(new_stdout):
 save_stdout = sys.stdout
 try:
 sys.stdout = new_stdout
 except:
 sys.stdout = save_stdout
 raise
 else:
 yield None
 sys.stdout = save_stdout

Used as follows:

 do opening(filename, "w") as f:
 do redirecting_stdout(f):
 print "Hello world"

This could be left as the more elegant original if iterator finalisation (e.g. 
using a "__finish__()" slot) came in at the same time as user defined 
statements, allowing the above to be written naturally with try/finally.

Arnold deVos's HTML tagging example would need access to the exception 
information and could be rewritten as a class:

   def tag(object):
   def __init__(self, name):
   self.name = cgi.escape(name)

   def __enter__(self):
   print '<%s>' % self.name
   return self.name

   def __exit__(self, *exc_info):
   if not exc_info or exc_info[0] is None:
   print '' % self.name

Used as follows::

   do tag('html'):
   do tag('head'):
  do tag('title'):
 print 'A web page'
   do tag('body'):
  for par in pars:
 do tag('p'):
print par

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] Merging PEP 310 and PEP 340-redux?

[Ka-Ping Yee]

On Fri, 13 May 2005, Guido van Rossum wrote:
> Straight up-or-down votes in the full senate are appreciated at this point.

I prefer the "PEP 340 redux" version.  Both the flexibility for __enter__
to return a separate object and the ability for __exit__ to react to
exceptions are useful.

> - Today I like the 'do' keyword better; 'with' might confuse folks
> coming from Pascal or VB

I prefer 'with'.  The 'do' keyword sounds "loopy" and doesn't make
grammatical sense.


-- ?!ng
___
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] Merging PEP 310 and PEP 340-redux?

[Bill Janssen]

> I prefer 'with'.  The 'do' keyword sounds "loopy" and doesn't make
> grammatical sense.

I agree.  "with [VAR =] BLOCK:" just reads better.  "with BLOCK [as
VAR]:" is OK, too.  Or even "within", as in

  within BLOCK binding VAR:
  SOMETHING

Probably too techy.

Bill




















___
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 - Abstract Block Redux

[Guido van Rossum]

[Phillip J. Eby]
> May I suggest this alternative translation in the "Specification" section:
> 
>  abc = EXPR
>  __args = ()  # pseudo-variable, not visible to the user
> 
>  try:
>  VAR = abc.__enter__()
>  try:
>  BLOCK
>  except:
>  __args = sys.exc_info()
>  finally:
>  abc.__exit__(*__args)

Done (except you forgot to add a "raise" to the except claise).

> While slighly more complex than the current translation, the current
> translation seems a bit misleading to me.  OTOH, that may simply be because
> I see the *sys.exc_info() part and immediately wonder what happens when
> there was no exception, and sys.exc_info() contains some arbitrary previous
> data...

Right. Well, anyway, the actual implementation will just get the
exception info from the try/finally infrastructure -- it's squirreled
away somewhere on the stack even if sys.exc_info() (intentionally)
doesn't have access to it.

> Also, one question: will the "do protocol" be added to built-in "resource"
> types?  That is, locks, files, sockets, and so on?

One person proposed that and it was shot down by Greg Ewing. I think
it's better to require a separate wrapper.

> Or will there instead
> be "macros" like the "opening" and "locking" templates?  I notice that
> grammatically, "do gerund" works a lot better than "do noun", so all of
> your examples are words like locking, blocking, opening, redirecting, and
> so on.  This makes it seem awkward for e.g. "do self.__lock", which doesn't
> make any sense.  But the extra call needed to make it "do
> locking(self.__lock)" seems sort of gratuitous.

Maybe. There seems to be a surge of proponents for 'do' at the moment.

> It makes me wonder if "with" or "using" or some similar word that works
> better with nouns might be more appropriate, as then it would let us just
> add the resource protocol to common objects, and still read well.  For
> example, a Decimal Context object might implement __enter__ by setting
> itself as the thread-local context, and __exit__ by restoring the previous
> context."do aDecimalContext" doesn't make much sense, but "with
> aDecimalContext" or "using aDecimalContext" reads quite nicely.

Maybe. I think we ought to implement the basic mechanism first and
then decide how fancy we want to get, so I'd rather not get into this
in the PEP. I'll add this to 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 - Abstract Block Redux

[Guido van Rossum]

[Nick Coghlan]
> The stdout redirection example needs to be corrected to avoid yielding inside 
> a
> try/finally though:

Thanks -- fixed now.

> This could be left as the more elegant original if iterator finalisation (e.g.
> using a "__finish__()" slot) came in at the same time as user defined
> statements, allowing the above to be written naturally with try/finally.

Let's not try to tie this to other features. I tried that with PEP 340
and you know the mess it became. :-)

-- 
--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] Merging PEP 310 and PEP 340-redux?

[Guido van Rossum]

[Bill Janssen]
> I agree.  "with [VAR =] BLOCK:" just reads better.  "with BLOCK [as
> VAR]:" is OK, too.

Maybe someone can set up a public poll (isn't that something you can
do on Yahoo? Or some volunteer can probably write it in Zope in 3
minutes) asking whether people prefer 'do' or 'with'. I'll go with the
outcome; this is pretty much the only contentious point in PEP 343 at
this point.

(That's http://www.python.org/peps/pep-0343.html in case you missed my
announcement; somehow Gmail classified it as spam for me even though I
sent it myself! :-)

-- 
--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 - Abstract Block Redux

[Robert Brewer]

Guido van Rossum wrote:
> I've written up the specs for my "PEP 340 redux" proposal as a
> separate PEP, PEP 343.
> 
> http://python.org/peps/pep-0343.html
> 
> Those who have been following the thread "Merging PEP 310 and PEP
> 340-redux?" will recognize my proposal in that thread, which received
> mostly positive responses there.
> 
> Please review and ask for clarifications of anything that's unclear.

There's a typo in the code snippets at the moment.

The translation of the above statement is:

abc = EXPR
exc = ()  # Or (None, None, None) ?
try:
try:
VAR = abc.__enter__()
BLOCK
except:
exc = sys.exc_info()
raise
finally:
abc.__exit__(exc)

I think you meant "abc.__exit__(*exc)". Assuming that, then "exc =
(None, None, None)" makes the most sense. If exc_info() is going to be
passed as a single arg, then I'd rather have the default "exc = ()", so
I can simply check "if exc:" in the __exit__ method.


Robert Brewer
System Architect
Amor Ministries
[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