Ben Finney writes:
> James Pye writes:
>
> > with daemonized():
> > run_some_subprocess()
>
> This use case is addressed by my up-coming PEP, currently in draft
> form but submitted to the PEP editor. A reference implementation is
> at http://pypi.python.org/pypi/python-daemon/>.
On second b
James Pye writes:
> The identification of this issue came from an *experiment* attempting
> to create a *single* "daemonized()" CM that would execute the with-
> statement's block in a new child process and, of course, not execute
> it in the parent. At first, I ran into the RuntimeError in the
On Mar 16, 2009, at 3:40 PM, Nick Coghlan wrote:
Not wasted - I prefer having this as a recognised limitation of the
semantics rather than as an accident of the implementation.
Well, I'm glad some good came from the issue report. =)
Who knows, maybe somebody will come up with a real world use
Brett Cannon wrote:
> At this point importlib is done for its public API for Python 3.1. That
> means it's time to turn my attention to making sure the semantics of
> import are well documented. But where to put all of the details? The
> language reference for import
> (http://docs.python.org/dev/p
Nick Coghlan wrote:
One of the
premises of PEP 343 was "Got a frequently recurring block of code that
only has one variant sequence of statements somewhere in the middle?
Well, now you can factor that out
Um, no -- it says explicitly right at the very top of
PEP 343 that it's only about factori
On Mon, Mar 16, 2009, Michael Foord wrote:
>
> Personally I would rather see the import semantics themselves in the
> language reference.
Either way is fine with me, but it needs to be cross-referenced.
--
Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/
Adopt A Pr
2009/3/16 Brett Cannon :
> At this point importlib is done for its public API for Python 3.1. That
> means it's time to turn my attention to making sure the semantics of import
> are well documented. But where to put all of the details? The language
> reference for import
> (http://docs.python.org/
Brett Cannon wrote:
At this point importlib is done for its public API for Python 3.1.
That means it's time to turn my attention to making sure the semantics
of import are well documented. But where to put all of the details?
The language reference for import
(http://docs.python.org/dev/py3k/r
Guido van Rossum wrote:
> On Mon, Mar 16, 2009 at 3:19 PM, Nick Coghlan wrote:
>> Guido van Rossum wrote:
Hell, I largely wrote PEP 377 to try to get out of having to document
these semantic problems with the with statement - if I'm having trouble
getting *python-dev* to grasp the p
At this point importlib is done for its public API for Python 3.1. That
means it's time to turn my attention to making sure the semantics of import
are well documented. But where to put all of the details? The language
reference for import (
http://docs.python.org/dev/py3k/reference/simple_stmts.ht
On Mon, Mar 16, 2009 at 3:19 PM, Nick Coghlan wrote:
> Guido van Rossum wrote:
>>> Hell, I largely wrote PEP 377 to try to get out of having to document
>>> these semantic problems with the with statement - if I'm having trouble
>>> getting *python-dev* to grasp the problem, what hope do other use
Guido van Rossum wrote:
>> Hell, I largely wrote PEP 377 to try to get out of having to document
>> these semantic problems with the with statement - if I'm having trouble
>> getting *python-dev* to grasp the problem, what hope do other users of
>> Python have?
>
> Hell, if you can't come up with
Baptiste Carvello wrote:
> Nick Coghlan a écrit :
>>
>> Implementing __with__ instead would give the CM complete control over
>> whether or not to execute the block.
>>
> please note, however, that this is an important change in the semantics
> of the with statement. As things are today, barring ex
On Mon, Mar 16, 2009 at 2:37 PM, Nick Coghlan wrote:
> Guido van Rossum wrote:
>> Yeah, it really seems pretty much limited to contextlib.nested(). I'd
>> be happy to sacrifice the possibility to *exactly* emulate two nested
>> with-statements.
>
> Then I really haven't explained the problem well
Guido van Rossum wrote:
> Yeah, it really seems pretty much limited to contextlib.nested(). I'd
> be happy to sacrifice the possibility to *exactly* emulate two nested
> with-statements.
Then I really haven't explained the problem well at all. One of the
premises of PEP 343 was "Got a frequently r
Nick Coghlan a écrit :
Implementing __with__ instead would give the CM complete control over
whether or not to execute the block.
please note, however, that this is an important change in the semantics of the
with statement. As things are today, barring exceptional circunstances, the body
of
On Mar 15, 2009, at 3:25 PM, Greg Ewing wrote:
with renaming_file("blarg.txt", "w") as f:
...
By chance during the weekend I actually wrote something like that:
from __future__ import with_statement
import os
import codecs
import shutil
import tempfile
from contextlib import contextma
On Mon, Mar 16, 2009 at 11:26 AM, Steven Bethard
wrote:
> On Mon, Mar 16, 2009 at 11:06 AM, Guido van Rossum wrote:
>> Moreover, since the main use case seems to be fixing a corner case of
>> the nested() context manager, perhaps the effort towards changing the
>> language would be better directe
On Mon, Mar 16, 2009 at 11:06 AM, Guido van Rossum wrote:
> Moreover, since the main use case seems to be fixing a corner case of
> the nested() context manager, perhaps the effort towards changing the
> language would be better directed towards supporting "with a, b:" as a
> shorthand for "with a
Moreover, since the main use case seems to be fixing a corner case of
the nested() context manager, perhaps the effort towards changing the
language would be better directed towards supporting "with a, b:" as a
shorthand for "with a: with b:" .
On Mon, Mar 16, 2009 at 10:01 AM, Guido van Rossum w
I have no right to speak because I haven't read through all the
details of the proposal, but reading this I am very sad that we have
to introduce a whole new exception (and one with special status as
well) in order to fix such a niggly corner case of the context manager
protocol.
Since IIUC the or
Greg Ewing wrote:
> What might make more sense is a context manager,
> e.g.
>
> with renaming_file("blarg.txt", "w") as f:
> ...
As you were describing the problems with "rename on close", I actually
immediately thought of the oft-repeated db transaction commit/rollback
example from PEP 343
Michael Foord wrote:
> Well, StopIteration is still an implementation detail that only
> occasionally bleeds through to actual programming. It says nothing about
> whether using exceptions for non-exceptional circumstances (control
> flow) is good practise. Personally I think it makes the intent of
P.J. Eby wrote:
> At 06:28 AM 3/16/2009 +1000, Nick Coghlan wrote:
>> There are some practical hurdles to that idea (specifically, creating a
>> callable which uses its parent's namespace rather than having its own),
>> but the basic concept seems sound.
>
> Actually, that bit's pretty simple -- t
24 matches
Mail list logo
