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,
Gu
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:
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 absen
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 ne
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 sysco
Martin v. LÃwis 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
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
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 th
Hi all,
probably unsuprisingly i am still pondering the idea of having
an optional __except__ hook on block handlers. The PEP says this
about this:
An extension to the protocol to include an optional __except__
handler, which is called when an exception is raised, and which
can han
[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__()
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 that are ok to fail.
With
Facundo Batista wrote:
Is there a document that details which objects are cached in memory
(to not create the same object multiple times, for performance)?
why do you think you need to know?
If not, could please somebody point me out where this is implemented
for strings?
Objects/stringobject.c (wh
Facundo Batista <[EMAIL PROTECTED]> writes:
> Is there a document that details which objects are cached in memory
> (to not create the same object multiple times, for performance)?
No.
> If not, could please somebody point me out where this is implemented
> for strings?
In PyString_FromStringAn
Is there a document that details which objects are cached in memory
(to not create the same object multiple times, for performance)?
If not, could please somebody point me out where this is implemented
for strings?
Thank you!
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://ww
14 matches
Mail list logo
