Re: [Python-Dev] [poll] New name for __builtins__
Guido van Rossum schrieb: >> > On Nov 30, 2007, at 6:05 PM, Guido van Rossum wrote: >> >> It's almost as if nobody has seen my proposal to leave __builtins__ >> >> alone and rename the __builtin__ module instead. > >> Fred Drake wrote: >> > +1 for a module named "builtin", or something similarly obscure. > > On Nov 30, 2007 3:42 PM, Neil Toronto <[EMAIL PROTECTED]> wrote: >> Would it be too confusing to call it "builtins"? > > To the contrary, I like that best (and want to note for the record > that that's what I proposed when I first brought it up here :-). > > If someone wants to prepare a patch, be my guest! Done, see #1535. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [poll] New name for __builtins__
Georg Brandl wrote: > Done, see #1535. I've written a 2to3 fixer, see #1535. Christian ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problems with GeneratorExit deriving from Exception
Hello Python-Dev,
Here at IMVU, we love Python 2.5's generators-as-coroutines. That feature has
let us succinctly express algorithms that intermix asynchronous network requests
and UI operations without writing complicated state machines, and, perhaps most
importantly, get high-quality unit tests around these algorithms.
However, we've been having a problem with the way GeneratorExit interacts with
our coroutine system. Let's take a bit of simplified example code from our
system:
@task
def pollForChatInvites(chatGateway, userId):
while True:
try:
# Network call.
result = yield
chatGateway.checkForInvite({'userId': userId})
except Exception: # An XML-RPC call can fail for many
reasons.
result = None
# ... handle result here
yield Sleep(10)
If a task (coroutine) is cancelled while it's waiting for the result from
checkForInvite, a GeneratorExit will be raised from that point in the generator,
which will be caught and ignored by the "except Exception:" clause, causing a
RuntimeError to be raised from whoever tried to close the generator. Moreover,
any finally: clauses or with-statement contexts don't run.
We have also run into problems where a task tries to "return" (yield Return())
from within a try: except Exception: block. Since returning from a coroutine is
roughly equivalent to "raise GeneratorExit", the exception can be caught and
ignored, with the same consequences as above.
This problem could be solved in several ways:
1) Make GeneratorExit derive from BaseException, just like SystemExit.
2) Add "except GeneratorExit: raise" to every usage of except Exception: in
tasks.
3) Change the semantics of except clauses so that you can use any container as
an exception filter. You could have a custom exception filter object that would
catch any Exception-derived exception except for GeneratorExit. Then we'd have
to teach the team to use "except ImvuExceptionFilter:" rather than "except
Exception:".
I prefer option #1, because it matches SystemExit and I haven't ever seen a case
where I wanted to catch GeneratorExit. When a generator is closed, I just want
finally: clauses to run, like a normal return statement would. In fact, we have
already implemented option #1 locally, but would like it to be standard.
Option #2 would add needless noise throughout the system,
You could argue that it's bad style to catch Exception, but there are many
situations where that's exactly what I want. I don't actually care _how_ the
xml-rpc call failed, just that the error is logged and the call is retried
later. Same with loading caches from disk.
Proposals for changing GeneratorExit to be a BaseException have come up on this
list in the past [1] [2], but were rejected as being too "theoretical". A
significant portion of the IMVU client is now specified with coroutines, so I
hope to resume this conversation.
Thoughts?
Chad
[1] http://mail.python.org/pipermail/python-dev/2006-March/062654.html
[2] http://mail.python.org/pipermail/python-dev/2006-March/062825.html
--
http://imvu.com/technology
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Non-string keys in namespace dicts
Are there any use-cases for allowing namespace dicts (such as globals, builtins and classes) to have non-string keys? I'm asking because I'm planning on accelerating method lookups next, and the possibility of a key compare changing the underlying dict could be a major pain. (It was a minor pain for globals.) Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with GeneratorExit deriving from Exception
On Dec 1, 2007 2:38 PM, Chad Austin <[EMAIL PROTECTED]> wrote:
> Here at IMVU, we love Python 2.5's generators-as-coroutines. That feature has
> let us succinctly express algorithms that intermix asynchronous network
> requests
> and UI operations without writing complicated state machines, and, perhaps
> most
> importantly, get high-quality unit tests around these algorithms.
>
> However, we've been having a problem with the way GeneratorExit interacts with
> our coroutine system. Let's take a bit of simplified example code from our
> system:
>
> @task
> def pollForChatInvites(chatGateway, userId):
> while True:
> try:
> # Network call.
> result = yield
> chatGateway.checkForInvite({'userId': userId})
> except Exception: # An XML-RPC call can fail for
> many reasons.
> result = None
> # ... handle result here
> yield Sleep(10)
>
> If a task (coroutine) is cancelled while it's waiting for the result from
> checkForInvite, a GeneratorExit will be raised from that point in the
> generator,
> which will be caught and ignored by the "except Exception:" clause, causing a
> RuntimeError to be raised from whoever tried to close the generator.
> Moreover,
> any finally: clauses or with-statement contexts don't run.
>
> We have also run into problems where a task tries to "return" (yield Return())
> from within a try: except Exception: block. Since returning from a coroutine
> is
> roughly equivalent to "raise GeneratorExit", the exception can be caught and
> ignored, with the same consequences as above.
>
> This problem could be solved in several ways:
>
> 1) Make GeneratorExit derive from BaseException, just like SystemExit.
>
> 2) Add "except GeneratorExit: raise" to every usage of except Exception: in
> tasks.
>
> 3) Change the semantics of except clauses so that you can use any container as
> an exception filter. You could have a custom exception filter object that
> would
> catch any Exception-derived exception except for GeneratorExit. Then we'd
> have
> to teach the team to use "except ImvuExceptionFilter:" rather than "except
> Exception:".
>
> I prefer option #1, because it matches SystemExit and I haven't ever seen a
> case
> where I wanted to catch GeneratorExit. When a generator is closed, I just
> want
> finally: clauses to run, like a normal return statement would. In fact, we
> have
> already implemented option #1 locally, but would like it to be standard.
>
> Option #2 would add needless noise throughout the system,
>
> You could argue that it's bad style to catch Exception, but there are many
> situations where that's exactly what I want. I don't actually care _how_ the
> xml-rpc call failed, just that the error is logged and the call is retried
> later. Same with loading caches from disk.
>
> Proposals for changing GeneratorExit to be a BaseException have come up on
> this
> list in the past [1] [2], but were rejected as being too "theoretical". A
> significant portion of the IMVU client is now specified with coroutines, so I
> hope to resume this conversation.
>
> Thoughts?
>
> Chad
>
> [1] http://mail.python.org/pipermail/python-dev/2006-March/062654.html
> [2] http://mail.python.org/pipermail/python-dev/2006-March/062825.html
Well argued. I suggest to go for option (1) -- make GeneratorExit
inherit from BaseException. We can do this starting 2.6. Feel free to
upload a patch to bugs.python.org.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non-string keys in namespace dicts
On Dec 1, 2007 7:09 PM, Neil Toronto <[EMAIL PROTECTED]> wrote: > Are there any use-cases for allowing namespace dicts (such as globals, > builtins and classes) to have non-string keys? I'm asking because I'm > planning on accelerating method lookups next, and the possibility of a > key compare changing the underlying dict could be a major pain. (It was > a minor pain for globals.) Since this has always worked, I suspect there are probably some packages that depend on this. We could deprecate this however in 2.6 and forbid it in 3.0; it's easy enough to switch to string keys, either using a unique prefix or even non-identifier characters like '.' or '$'. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non-string keys in namespace dicts
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | On Dec 1, 2007 7:09 PM, Neil Toronto <[EMAIL PROTECTED]> wrote: | > Are there any use-cases for allowing namespace dicts (such as globals, | > builtins and classes) to have non-string keys? I'm asking because I'm | > planning on accelerating method lookups next, and the possibility of a | > key compare changing the underlying dict could be a major pain. (It was | > a minor pain for globals.) | | Since this has always worked, I suspect there are probably some | packages that depend on this. My impression from a decade of reading c.l.p. is that most people posting there regard the possibility, when bypassing the normal identifier access mechanisms, of putting non-identifiers, let alone non-string keys into namespace dicts, as 1. Surprising (because they assumed a string- or name-only dict was used). or 2. A side effect (implementation dependent) of Python economizing on types. (But with the result of spurring optimization of dicts, which in turn reduced the motivation for a specialized type [until now].) In any case, it seemed pretty useless, since naming and using a dict was/is both easier and safer (more future proof). But there may have been a person or two who liked having semi-hidden variables or attributes. |We could deprecate this however in 2.6 | and forbid it in 3.0; it's easy enough to switch to string keys, | either using a unique prefix or even non-identifier characters like | '.' or '$'. Or use a separate, unrestricted, regular dict. +1 tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems with GeneratorExit deriving from Exception
Guido van Rossum wrote: > On Dec 1, 2007 2:38 PM, Chad Austin <[EMAIL PROTECTED]> wrote: >> This problem could be solved in several ways: >> >> 1) Make GeneratorExit derive from BaseException, just like SystemExit. > > Well argued. I suggest to go for option (1) -- make GeneratorExit > inherit from BaseException. We can do this starting 2.6. Feel free to > upload a patch to bugs.python.org. Great! Patch is uploaded at http://bugs.python.org/issue1537 The patch changes the definition of GeneratorExit so that it extends BaseException, adds a generator test, updates exception_hierarchy.txt, and updates the exceptions page in the documentation. This is my first patch to Python -- did I miss anything? Thanks, Chad ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
