[EMAIL PROTECTED] (holger krekel) wrote:
basically translates to:
if hasattr(x, '__enter__'):
x.__enter__()
try:
...
except:
if hasattr(x, '__except__'): x.__except__(...)
else: x.__exit__()
else:
x.__exit__()
Nope...
On Apr 22, 2005, at 16:51, holger krekel wrote:
Moreover, i think that there are more than the transactional
use cases mentioned in the PEP. For example, a handler
may want to log exceptions to some tracing utility
or it may want to swallow certain exceptions when
its block does IO operations
Good morning/evening/:
Here a few sourceforge bugs which can probably be closed:
[ 1168983 ] : ftplib.py string index out of range
Original poster reports that the problem disappeared after a patch
committed by Raymond
[ 1178863 ] Variable.__init__ uses self.set(), blocking specialization
seems
Martin v. Lwis wrote:
Brett C. wrote:
Yep, you're right. I initially thought that the parentheses meant it was a
Makefile-only variable, but it actually goes to the environment for those
unknown values.
Before I check it in, though, should setup.py be tweaked to use it as well? I
say yes.
Brett C. wrote:
Yep, you're right. I initially thought that the parentheses meant it was a
Makefile-only variable, but it actually goes to the environment for those
unknown values.
Before I check it in, though, should setup.py be tweaked to use it as well? I
say yes.
You means
Skip Montanaro wrote:
Guido or perhaps even (making for VAR optional in the for-loop syntax)
Guido with
Guido in synchronized(the_lock):
Guido BODY
This could be a new statement, so the problematic issue of implicit
try/finally in every for statement wouldn't be
Michael Chermside wrote:
Now the pattern matching is more interesting, but again, I'd need to
see a proposed syntax for Python before I could begin to consider it.
If I understand it properly, pattern matching in Haskell relies
primarily on Haskell's excellent typing system, which is absent
As best I can tell, the anonymous blocks are used to take
care of boilerplate code without changing the scope -- exactly
what macros are used for. The only difference I see is that in
this case, the macros are limited to entire (possibly compound)
statements.
To make this more concrete,
Nick Coghlan wrote:
Interestingly, with this approach, for dummy in my_resource() would still
wrap
the block of code in the entrance/exit code (because my_resource *is* a
generator), but it wouldn't get the try/finally semantics.
An alternative would be to replace the 'yield None' with
Nick Coghlan wrote:
An alternative would be to replace the 'yield None' with a 'break' or
'continue', and create an object which supports the resource protocol
and NOT the iterator protocol. Something like:
def my_resource():
print Hi! # Do entrance code
continue # Go on with
I always wondered why there usually is very sloppy error checking in
initmodule functions. Usually it goes like this (I removed
declarations and some other lines for clarity):
PyMODINIT_FUNC
PyInit_zlib(void)
{
m = Py_InitModule4(zlib, zlib_methods,
On 4/21/05, Guido van Rossum [EMAIL PROTECTED] wrote:
for dummy in synchronized(the_lock):
BODY
or perhaps even (making for VAR optional in the for-loop syntax)
with
in synchronized(the_lock):
BODY
Then synchronized() could be written cleanly as follows:
def
[Facundo Batista]
Is there a document that details which objects are cached in memory
(to not create the same object multiple times, for performance)?
The caches get cleaned-up before Python exit's, so you can find them all
listed together in the code in Python/pythonrun.c:
/* Sundry
Brett C. wrote:
You means sysconfig.py, right?
Right.
No, I mean Python's setup.py; line 174.
Ah, ok.
You mean Distutils' sysconfig, right? I can change that as well if you want.
Please do; otherwise, people might see strange effects.
Regards,
Martin
On Fri, Apr 22, 2005 at 19:03 -0700, Josiah Carlson wrote:
[EMAIL PROTECTED] (holger krekel) wrote:
basically translates to:
if hasattr(x, '__enter__'):
x.__enter__()
try:
...
except:
if hasattr(x, '__except__'): x.__except__(...)
On Sat, Apr 23, 2005, Nick Coghlan wrote:
In light of Alex's comments, I'd actually like to suggest the below as a
potential new definition for PEP 310 (making __exit__ optional, and adding
an __else__ handler):
if hasattr(x, '__enter__'):
x.__enter__()
try:
Nick Coghlan wrote:
Alternately, PEP 310 could be defined as equivalent to:
if hasattr(x, '__enter__'):
x.__enter__()
try:
try:
...
except:
if hasattr(x, '__except__'):
x.__except__(*sys.exc_info())
else:
At 01:41 PM 4/23/05 +1000, Nick Coghlan wrote:
Whichever way that point goes, this definition would allow PEP 310 to
handle Alex's example of factoring out standardised exception handling, as
well as the original use case of resource cleanup, and the transaction
handling:
class
Nick Coghlan [EMAIL PROTECTED] writes:
holger krekel wrote:
Moreover, i think that there are more than the transactional
use cases mentioned in the PEP. For example, a handler may want to
log exceptions to some tracing utility or it may want to swallow
certain exceptions when
its block
Bernhard Herzog wrote:
With the proposed implementation of PEP 310 rev. 1.5 it wouldn't work.
sys.exc_info returns a tuple of Nones unless an except: clause has been
entered. Either sys.exc_info() would have to be changed to always
return exception information after an exception has been raised
Aahz wrote:
On Sat, Apr 23, 2005, Nick Coghlan wrote:
In light of Alex's comments, I'd actually like to suggest the below as a
potential new definition for PEP 310 (making __exit__ optional, and adding
an __else__ handler):
if hasattr(x, '__enter__'):
x.__enter__()
try:
try:
holger krekel wrote:
On a side note, I don't see too much point in having __except__
return something when it is otherwise easy to say:
def __except__(self, typ, val, tb):
self.abort_transaction()
raise typ, val, tb
It has to do with Errors should never pass silently,
22 matches
Mail list logo
