Hello,
after proposing this here (albeit deep in the PEP 340 thread) and
getting a somewhat affirmatory response from Guido, I have written
something that could become a PEP if sufficiently hatched...
---
PEP: XXX
Title: Unifying try-except and try-finally
Version: $Revis
Nicholas Bastin wrote:
> The documentation for Py_UNICODE states the following:
>
> "This type represents a 16-bit unsigned storage type which is used by
> Python internally as basis for holding Unicode ordinals. On platforms
> where wchar_t is available and also has 16-bits, Py_UNICODE is a
On 5/3/05, Nicolas Fleury <[EMAIL PROTECTED]> wrote:
> We could avoid explaining to a newbie why the following code doesn't
> work if "opening" could be implemented in way that it works.
>
> for filename in filenames:
> block opening(filename) as file:
> if someReason: break
My initia
Hi,
Josiah Carlson <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
>>> strip
>> IMHO this should be left to hooker(apparerently not right word, but you
>> get the point :) ). If he allocates more mem. or does heavy stuff, that
>> will just fail. Anyway abort() is a failure too. Either a
Hi,
James William Pye <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> On Tue, 2005-05-03 at 13:39 -0700, Josiah Carlson wrote:
>
>> If I'm wrong, I'd like to hear it, but I'm still waiting for your patch
>> on sourceforge.
>
> Well, if he lost/loses interest for whatever reason, I'd be
James Y Knight wrote:
> On May 3, 2005, at 12:53 PM, Guido van Rossum wrote:
>
>>def saving_stdout(f):
>>save_stdout = sys.stdout
>>try:
>>sys.stdout = f
>>yield
>>finally:
>>sys.stdout = save_stdout
>
>
> I hope you aren't going to be using that in any thread
Tim Peters wrote:
> I don't think anyone has mentioned this yet, so I will: library
> writers using Decimal (or more generally HW 754 gimmicks) have a need
> to fiddle lots of thread-local state ("numeric context"), and must
> restore it no matter how the routine exits. Like "boost precision to
>
Guido van Rossum wrote:
> Fredrik, what does your intuition tell you?
having been busy with other stuff for nearly a week, and seeing that the PEP is
now at
version 1.22, my intuition tells me that it's time to read the PEP again before
I have any
opinion on anything ;-)
_
Phillip J. Eby wrote:
> This and other examples from the PEP still have a certain awkwardness of
> phrasing in their names. A lot of them seem to cry out for a "with"
> prefix, although maybe that's part of the heritage of PEP 310. But Lisp
> has functions like 'with-open-file', so I don't thi
> At 05:17 PM 5/3/05 -0700, Guido van Rossum wrote:
>>But I kind of doubt that it's an issue; you'd have to have a
>>try/except catching StopIteration around a yield statement that
>>resumes the generator before this becomes an issue, and that sounds
>>extremely improbable.
The specific offending
Delaney, Timothy C (Timothy) wrote:
> Guido van Rossum wrote:
>
>
>>I'd like the block statement to be defined exclusively in terms of
>>__exit__() though.
>
>
> This does actually suggest something to me (note - just a thought - no
> real idea if it's got any merit).
>
> Are there any use cas
Paul Moore wrote:
> Oh, and by the way - I prefer the keywordless form of the block
> statement (as used in my examples above). But it may exacerbate the
> issue with break unless we have a really strong name for these
> constructs
"may" exacerbate? Something of an understatement, unfortunately. '
On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote:
>> At the very least, if we can't guarantee the internal representation,
>> then the PyUnicode_FromUnicode API needs to go away, and be replaced
>> with something capable of transcoding various unicode inputs into the
>> internal python represent
I'm the track chair of the Python Language track at Europython (27-29
June, Göteborg, Sweden) . The general deadlline for talk submission has
been extended until the 7th of May.
There are still open slots for the language track. So if someone with
(core) language interests is or may be interest
On Wed, 2005-05-04 at 09:46 +, M.Utku K. wrote:
> The reinit. issue: The old way of returning old callback when a new
> callback is set sounds OK. Or better way: there may be an array to hold all
> the callbacks, Py_FatalError iterates and call each.
Why should reinitialization be allowed at
On May 4, 2005, at 01:57, Paul Moore wrote:
> tried to construct a plausible example, I couldn't find a case which
> made real-life sense. For example, with Nicolas' original example:
>
> for name in filenames:
> opening(name) as f:
> if condition: break
>
> I can't think
On 5/4/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On May 4, 2005, at 01:57, Paul Moore wrote:
> >
> > I can't think of a reasonable condition which wouldn't involve reading
> > the file - which either involves an inner loop (and we already can't
> > break out of two loops, so the third one i
On 5/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> With single-pass semantics, an iterator used in a block statement would have
> it's .next() method called exactly once, and it's __exit__ method called
> exactly
> once if the call to .next() does not raise StopIteration. And there's no need
>
James William Pye <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> On Wed, 2005-05-04 at 09:46 +, M.Utku K. wrote:
>> The reinit. issue: The old way of returning old callback when a new
>> callback is set sounds OK. Or better way: there may be an array to hold
>> all the callbacks, Py_
Nicholas Bastin wrote:
>
> On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote:
>
>>> At the very least, if we can't guarantee the internal representation,
>>> then the PyUnicode_FromUnicode API needs to go away, and be replaced
>>> with something capable of transcoding various unicode inputs into
On May 4, 2005, at 1:39 PM, M.-A. Lemburg wrote:
> Nicholas Bastin wrote:
>> On May 4, 2005, at 4:39 AM, M.-A. Lemburg wrote:
At the very least, if we can't guarantee the internal
representation, then the PyUnicode_FromUnicode API needs to go
away, and be replaced with something
The current documentation for Py_UNICODE states:
"This type represents a 16-bit unsigned storage type which is used by
Python internally as basis for holding Unicode ordinals. On platforms
where wchar_t is available and also has 16-bits, Py_UNICODE is a
typedef alias for wchar_t to enhance
Nicholas Bastin <[EMAIL PROTECTED]> writes:
> The current documentation for Py_UNICODE states:
>
> "This type represents a 16-bit unsigned storage type which is used by
> Python internally as basis for holding Unicode ordinals. On platforms
> where wchar_t is available and also has 16-bits, P
On Wed, May 04, 2005 at 03:29:33PM +, M.Utku K. wrote:
> James William Pye <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
> > Why should reinitialization be allowed at all? Seems to me that this
> > feature should be exclusively reserved for an embedding application to
> > handle the f
Paul Moore wrote:
> On 5/4/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
>>
>> On May 4, 2005, at 01:57, Paul Moore wrote:
>> >
>> > I can't think of a reasonable condition which wouldn't involve reading
>> > the file - which either involves an inner loop (and we already can't
>> > break out of two
I'm a bit surpised that no one has yet [1] suggested "begin" as a
keyword instead "block" as it seems to express the intent of blocks
and is concise and readable. For example, here are the examples in
PEP 340 rewritten using "begin":
begin locking():
...
begin opening(path) as f: #how about:
My first post to python-dev, but I guess my name is not completely unknown
in this list ;)
Actually, I have been wondering about subscribing to python-dev for at least
a couple of years, but never did it, because of the limited amount of time
I have to follow all the interesting mailing lists in
Adam Souzis wrote:
> I'm a bit surpised that no one has yet [1] suggested "begin" as a
> keyword instead "block" as it seems to express the intent of blocks
> and is concise and readable. For example, here are the examples in
> PEP 340 rewritten using "begin":
>
> begin locking():
>...
I don
Nicholas Bastin <[EMAIL PROTECTED]> writes:
> The current documentation for Py_UNICODE states:
>
> "This type represents a 16-bit unsigned storage type which is used by
> Python internally as basis for holding Unicode ordinals. On platforms
> where wchar_t is available and also has 16-bits, P
Nice one. Should be a piece of cake to implement. Please talk to
[EMAIL PROTECTED] about getting it checked into the PEP database.
I'm +1 on accepting this now -- anybody against?
On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Hello,
>
> after proposing this here (albeit deep in the
I have not read every email about this subject, so sorry if this has
already been mentioned.
In PEP 340 I read:
block EXPR1 as VAR1:
BLOCK1
I think it would be much clearer this (plus you save one keyword):
block VAR1 = EXPR1:
BLOCK1
Regards.
--
On May 4, 2005, at 1:02 PM, Michael Hudson wrote:
> Nicholas Bastin <[EMAIL PROTECTED]> writes:
>
>> The current documentation for Py_UNICODE states:
>>
>> "This type represents a 16-bit unsigned storage type which is used by
>> Python internally as basis for holding Unicode ordinals. On platfor
[ Guido ]:
> 1. Decide on a keyword to use, if any.
Shouldn't be the other way around ?
Decide to use *no* keyword, if that could be avoided.
In my large inexperience *no keyword* is much better (if feasible):
1) No name conflicts with previous code: block, blocktemplate, whatever
2)
On Wed, 2005-05-04 at 13:09, Guido van Rossum wrote:
> Nice one. Should be a piece of cake to implement. Please talk to
> [EMAIL PROTECTED] about getting it checked into the PEP database.
+1!
-Barry
signature.asc
Description: This is a digitally signed message part
[ Guido ]:
> Nice one. Should be a piece of cake to implement. Please talk to
> [EMAIL PROTECTED] about getting it checked into the PEP database.
>
> I'm +1 on accepting this now -- anybody against?
+1
Last week, while I was giving a Python course (in Rio de Janeiro-Brazil)
some students attempt
> Are there plans to improve decorators support in future Python
versions?
> By "improving decorator support" I mean for instance a module in the
> standard
> library providing some commonly used decorators such as ``memoize``,
> or utilities to create and compose decorators, and things like that.
On Wed, 2005-05-04 at 15:29 +, M.Utku K. wrote:
> Extension developer may discard or call them at his own will.
That's the issue, an extension developer shouldn't be able to discard
it, as I, the embedder, do not want my hook to be clobbered. The
extension developer doesn't set the context of
Gustavo J. A. M. Carneiro wrote:
> I have not read every email about this subject, so sorry if this has
> already been mentioned.
>
> In PEP 340 I read:
>
> block EXPR1 as VAR1:
> BLOCK1
>
> I think it would be much clearer this (plus you save one keyword):
>
> bl
Thomas Heller wrote:
> AFAIK, you can configure Python to use 16-bits or 32-bits Unicode chars,
> independend from the size of wchar_t. The HAVE_USABLE_WCHAR_T macro
> can be used by extension writers to determine if Py_UNICODE is the same as
> wchar_t.
note that "usable" is more than just "same
Rodrigo Dias Arruda Senra wrote:
> [ Guido ]:
> > 1. Decide on a keyword to use, if any.
>
> Shouldn't be the other way around ?
> Decide to use *no* keyword, if that could be avoided.
[...]
> Following the PEP and this thread, it seems to me that __no keyword__
> is less preferable than _
[Guido]
> I'm +1 on accepting this now -- anybody against?
I'm curious to know if you (Guido) remember why you removed this
feature in Python 0.9.6? From the HISTORY file:
"""
New features in 0.9.6:
- stricter try stmt syntax: cannot mix except and finally clauses on 1 try
"""
IIRC (and I may w
On May 4, 2005, at 2:29 PM, Fredrik Lundh wrote:
> Gustavo J. A. M. Carneiro wrote:
>
>
>> I have not read every email about this subject, so sorry if this
>> has
>> already been mentioned.
>>
>> In PEP 340 I read:
>>
>> block EXPR1 as VAR1:
>> BLOCK1
>>
>> I think it
On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>
> There is one problem with using no keyword: You cannot use arbitrary
> expressions
> in the new statement. Consider:
>
> resource = opening("file.txt")
> block resource:
> (...)
>
> resource = opening("file.txt")
> resource:
>
Alex Martelli wrote:
> Looking for a file with a certain magicnumber in its 1st two bytes...?
>
> for name in filenames:
> opening(name) as f:
> if f.read(2) == 0xFEB0: break
>
> This does seem to make real-life sense to me...
I'd like to suggest a small language enhancement that w
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Thomas Heller wrote:
>
>> AFAIK, you can configure Python to use 16-bits or 32-bits Unicode chars,
>> independend from the size of wchar_t. The HAVE_USABLE_WCHAR_T macro
>> can be used by extension writers to determine if Py_UNICODE is the same as
>>
Hi all,
> strip.
> What if more than one extension needs it ?
> Curently Im doing
>
> callback_type SetCallBack(callback_type newfunc)
>
> This will set the callback to newfunc and return the old one. Extension
> developer may discard or call them at his own will. What do you think?
>
> __
Gustavo J. A. M. Carneiro wrote:
> In PEP 340 I read:
>
> block EXPR1 as VAR1:
> BLOCK1
>
> I think it would be much clearer this (plus you save one keyword):
>
> block VAR1 = EXPR1:
> BLOCK1
I think you misunderstood the statement. EXPR1 creates an
[ Senra ]:
> > [ Guido ]:
> > > 1. Decide on a keyword to use, if any.
> >
> > Shouldn't be the other way around ?
> > Decide to use *no* keyword, if that could be avoided.
[ Reinhold ]:
> There is one problem with using no keyword: You cannot use arbitrary
> expressions
> in the new statem
Shane Hathaway wrote:
> Gustavo J. A. M. Carneiro wrote:
>
>> In PEP 340 I read:
>>
>>block EXPR1 as VAR1:
>>BLOCK1
>>
>> I think it would be much clearer this (plus you save one keyword):
>>
>>block VAR1 = EXPR1:
>>BLOCK1
>
>
> I think you misunderstood
On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> PS: What about "using"? Too C#-ish?
Another idea from a hobbyist programmer: "holding" or mabe just
"hold". Like this:
hold locked(myLock):
# Code here executes with myLock held. The lock is
# guaranteed to be r
"M.Utku K." <[EMAIL PROTECTED]> wrote in news:Xns964CE11B16061token@
80.91.229.5:
> _Callback(PyFatalError_Func func) )
> is in "pyerrors.h" but implemenatiton is
> is in "Pythonrun.c". Is it OK? Im listening for more.
>
Sorry, just checked decl. will be in "pydebug.h"
___
Guido> Nice one. Should be a piece of cake to implement. Please talk to
Guido> [EMAIL PROTECTED] about getting it checked into the PEP database.
Guido> I'm +1 on accepting this now -- anybody against?
I'm not against it, but I thought there were ambiguity reasons that this
construct
On Wed, 4 May 2005, Shane Hathaway wrote:
> I'd like to suggest a small language enhancement that would fix this
> example. Allow the break and continue statements to use a keyword,
> either "for" or "while", to state that the code should break out of both
> the block statement and the innermost "
[ Shane Hathaway ]:
> I'd like to suggest a small language enhancement that would fix this
> example. Allow the break and continue statements to use a keyword,
> either "for" or "while", to state that the code should break out of both
> the block statement and the innermost "for" or "while" statem
On Wed, 2005-05-04 at 14:41, Tim Peters wrote:
> IIRC (and I may well not), half of people guessed wrong about whether
> an exception raised in an "except:" suite would or would not skip
> execution of the same-level "finally:" suite.
It would not, obviously .
> try:
> 1/0
> except DivisionB
Ka-Ping Yee wrote:
> On Wed, 4 May 2005, Shane Hathaway wrote:
>>
>>for name in filenames:
>>opening(name) as f:
>>if f.read(2) == 0xFEB0:
>>break for
>
>
> This is very elegant.
Thanks.
> It works beautifully with "break", though at
> first that natural
[Tim]
> I'm curious to know if you (Guido) remember why you removed this
> feature in Python 0.9.6? From the HISTORY file:
>
> """
> New features in 0.9.6:
> - stricter try stmt syntax: cannot mix except and finally clauses on 1 try
> """
>
> IIRC (and I may well not), half of people guessed wro
Noam Raphael wrote:
> On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>>
>> There is one problem with using no keyword: You cannot use arbitrary
>> expressions
>> in the new statement. Consider:
>>
>> resource = opening("file.txt")
>> block resource:
>> (...)
>>
>> resource = open
Tim Peters wrote:
> [Guido]
>> I'm +1 on accepting this now -- anybody against?
>
> I'm curious to know if you (Guido) remember why you removed this
> feature in Python 0.9.6? From the HISTORY file:
>
> """
> New features in 0.9.6:
> - stricter try stmt syntax: cannot mix except and finally clau
Reinhold Birkenfeld wrote:
> There is one problem with using no keyword: You cannot use arbitrary
> expressions in the new statement.
[...]
> resource = opening("file.txt")
> resource:
> (...)
>
> The latter would have to be forbidden.
Noam Raphael wrote:
> Can you explain why it would have to
Ka-Ping Yee wrote:
> Reinhold Birkenfeld wrote:
>> Well, with it you could create suites with _any_ introducing
>> identifier. Consider:
>>
>> with:
>> (...)
>>
>> synchronized:
>> (...)
>>
>> try:
>> (...)
>>
>> transaction:
>> (...)
>>
>> Do you understand my concern? It would be
Reinhold Birkenfeld wrote:
> Noam Raphael wrote:
>
>>On 5/4/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
>>>resource = opening("file.txt")
>>>resource:
>>>(...)
>>>
>>>The latter would have to be forbidden.
>>
>>Can you explain why it would have to be forbidden please?
>
>
> Well, with
Shane Hathaway wrote:
> For each block statement, it is necessary to create a *new* iterator,
Right.
> since iterators that have stopped are required to stay stopped. So at a
> minimum, used-defined statements will need to call something, and thus
> will have parentheses. The parentheses might
Guido van Rossum wrote:
> Nice one. Should be a piece of cake to implement. Please talk to
> [EMAIL PROTECTED] about getting it checked into the PEP database.
>
> I'm +1 on accepting this now -- anybody against?
>
I'm +1. A couple of us discussed this at PyCon during the last day of the
sprints
[Reinhold Birkenfeld]
> ...
> I think the behaviour of the "else" clause is much harder to guess,
> mainly when used with the looping constructs.
No, that's obvious .
What about `else` mixed with try/except/finally?
try:
A
except:
B
else:
C
finally:
D
If A executes without excep
Reinhold Birkenfeld wrote:
> Shane Hathaway wrote:
>
>
>>For each block statement, it is necessary to create a *new* iterator,
>
>
> Right.
>
>
>>since iterators that have stopped are required to stay stopped. So at a
>>minimum, used-defined statements will need to call something, and thus
>
On Wed, 2005-05-04 at 13:08 -0600, Shane Hathaway wrote:
> Gustavo J. A. M. Carneiro wrote:
> > In PEP 340 I read:
> >
> > block EXPR1 as VAR1:
> > BLOCK1
> >
> > I think it would be much clearer this (plus you save one keyword):
> >
> > block VAR1 = EXPR1:
> >
Tim> What about `else` mixed with try/except/finally?
Tim> try:
Tim> A
Tim> except:
Tim> B
Tim> else:
Tim> C
Tim> finally:
Tim> D
Tim> If A executes without exception, does D execute before or after C?
According to Guido, execution is A, C
Tim Peters wrote:
> [Reinhold Birkenfeld]
>> ...
>> I think the behaviour of the "else" clause is much harder to guess,
>> mainly when used with the looping constructs.
>
> No, that's obvious .
OK, I'm persuaded. Well you wield the Force, master.
> What about `else` mixed with try/except/finally
On Wed, May 04, 2005, Paul Moore wrote:
>
> Yes, that'd do. I can't say I think it would be common, but it's a
> valid case. And the workaround is the usual messy flag variable:
>
> for name in filenames:
> found = False
> opening(name) as f:
> if f.read(2) == 0xFEB0: found = True
[ Reinhold Birkenfeld ]:
> Well, with it you could create suites with _any_ introducing
> identifier. Consider:
>
> with:
> (...)
>
> synchronized:
> (...)
>
> try:
> (...)
>
> transaction:
> (...)
>
>
> Do you understand my concern?
I definetely see your point. However,...
Aahz wrote:
> On Wed, May 04, 2005, Paul Moore wrote:
>>
>> Yes, that'd do. I can't say I think it would be common, but it's a
>> valid case. And the workaround is the usual messy flag variable:
>>
>> for name in filenames:
>> found = False
>> opening(name) as f:
>> if f.read(2) ==
Nicholas Bastin wrote:
> That makes PyUnicode_FromUnicode() a lot less useful. Well, really,
> not useful at all.
Why do you say that? Py_UNICODE is as good a type to store characters
as any other, and if you happen to have a Py_UNICODE[], you can use
that function to build a unicode object.
>
Nicholas Bastin wrote:
> "This type represents the storage type which is used by Python
> internally as the basis for holding Unicode ordinals. Extension module
> developers should make no assumptions about the size of this type on
> any given platform."
But people want to know "Is Python's Un
Martin v. Löwis wrote:
> Nicholas Bastin wrote:
>
>>"This type represents the storage type which is used by Python
>>internally as the basis for holding Unicode ordinals. Extension module
>>developers should make no assumptions about the size of this type on
>>any given platform."
>
>
> But
And per the PEP, I think the explaining that::
try:
A
except:
B
else:
C
finally:
D
is *exactly* equivalent to::
try:
try:
A
except:
B
else:
C
finally:
D
R
Hi,
Added the patch to the patch manager on SF.
Best regards.
___
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.c
Nick Coghlan wrote:
> Ah, someone else did post this idea first :)
I knew I was standing on the shoulders of others :)
> To deal with the generator issue, one option would be to follow up on
> Phillip's idea of a decorator to convert a generator (or perhaps any
> standard iterator) into a block
Shane Hathaway wrote:
> For each block statement, it is necessary to create a *new* iterator,
> since iterators that have stopped are required to stay stopped. So at a
> minimum, used-defined statements will need to call something, and thus
> will have parentheses. The parentheses might be enough
Aahz wrote:
> My standard workaround is using exceptions, but I'm not sure how that
> interacts with a block:
>
> try:
> for name in filenames:
> with opened(name) as f:
> if f.read(2) == 0xFEB0:
> raise Found
> except Found:
>
I'm forced by my day job to temporarily withdraw from the discussion
about PEP 340 (I've used up my Python quota for the next several
weeks).
If agreement is reached in python-dev to suggest specific changes to
the PEP, please let me know via mail sent directly to me and not cc'ed
to python-dev. B
[Shane Holloway]
> And per the PEP, I think the explaining that::
>
> try:
> A
> except:
> B
> else:
> C
> finally:
> D
>
> is *exactly* equivalent to::
>
> try:
> try:
> A
> except:
> B
> else:
>
Recently I needed some information about the floating point numbers on
my machine. So I wrote a tiny C99 program with the line
printf("%a\n", DBL_EPSILON);
The answer was "0x1p-52".
A search of comp.lang.python shows that I was not alone. Here are some
ideas.
1. Add to Python the constants in
Shane Hathaway wrote:
> For each block statement, it is necessary to create a *new* iterator,
> since iterators that have stopped are required to stay stopped. So at a
> minimum, used-defined statements will need to call something, and thus
> will have parentheses.
Not necessarily!
class Frob
Shane Holloway (IEEE) wrote:
> Another thing. In the specification of the Anonymous Block function, is
> there a reason that "itr = EXPR1" instead of "itr = iter(EXPR1)"? It
> seems to be a dis-symmetry with the 'for' loop specification.
Hmm... yeah. That's strange. In fact, if it gets chang
BJörn Lindqvist wrote:
> But why stop there? Lots of functions that takes a callable as
> argument could be upgraded to use the new block syntax.
Actually, this is something that occurred to me in
potential support of a thunk implementation: It's
possible that many functions already out there whi
Greg Ewing wrote:
> Shane Hathaway wrote:
>
>>For each block statement, it is necessary to create a *new* iterator,
>>since iterators that have stopped are required to stay stopped. So at a
>>minimum, used-defined statements will need to call something, and thus
>>will have parentheses.
>
>
> N
How about user-defined keywords?
Suppose you could write
statement opening
def opening(path, mode):
f = open(path, mode)
try:
yield
finally:
close(f)
which would then allow
opening "myfile", "w" as f:
do_something_with(f)
The 'statement' statement de
+1
This is awesome.
BTW, did we totally abandon the question of using block: as RHS?
jb
On May 5, 2005, at 12:12 AM, Greg Ewing wrote:
> How about user-defined keywords?
>
> Suppose you could write
>
>statement opening
>
>def opening(path, mode):
> f = open(path, mode)
> try
Just a little offtopic note to Jeff Bone: Jeff, every time I send a
message to Python-Dev, your "Mail.app 2.0" sends me a nasty auto-reply
that I can't quote in public. Please stop. Since I can't seem to reach
you by email, I'm trying to reach you through this mailing list. The
note refers to so
Edward C. Jones wrote:
> The documentation should discuss portability.
This is the critical issue here. Discussing portability is not
enough; these features really ought to be either available on
a majority of the installations, or not available at all.
In particular, they would need to be availab
91 matches
Mail list logo
