headers
Arnaud Delobelle | 1 Mar 2009 11:34

Re: Revised**5 PEP on yield-from


On 28 Feb 2009, at 20:54, Jacob Holm wrote:

> Replying to myself here...
>
> Jacob Holm wrote:
>> I think I can actually see a way to do it that should be fast  
>> enough, but I'd like to
>> work out the details first. If it works it will be O(1) with low  
>> constants as long as
>> you don't build trees, and similar to traversing a delegation chain  
>> in the worst case.
>>
>> All this depends on getting it working using delegation chains  
>> first though, as most of
>> the StopIteration and Exception handling would be the same.
>
> I have now worked out the details, and it is indeed possible to get  
> O(1) for simple cases and amortized O(logN)
> in general, all with fairly low constants.

I'm sorry if I'm missing something obvious, but there are two things I  
can't work out:

* What you are measuring the time complexity of.
* What N stands for.

I suspect that N is the 'delegation depth': the number of yield-from  
that have to be gone through.  I imagine that you are measuring the  
time it takes to get the next element in the generator.  These are
(Continue reading)

Permalink | Reply | 15 comments |
headers
Jacob Holm | 1 Mar 2009 13:30
Picon

Re: Revised**5 PEP on yield-from

Hi Arnaud

Arnaud Delobelle wrote:
>> I have now worked out the details, and it is indeed possible to get 
>> O(1) for simple cases and amortized O(logN)
>> in general, all with fairly low constants.
>
> I'm sorry if I'm missing something obvious, but there are two things I 
> can't work out:
I am glad you asked. Reading it again, I can see that this is definitely 
not obvious.

>
> * What you are measuring the time complexity of.
The time for a single 'next', 'send', 'throw' or 'close' call to a 
generator or a single "yield from" expression, excluding the time spent 
running the user-defined code in it. (Does that make sense?) In other 
words, the total overhead of finding the actual user code to run and 
handling the return values/exceptions according to the PEP.

> * What N stands for.
>
> I suspect that N is the 'delegation depth': the number of yield-from 
> that have to be gone through. I imagine that you are measuring the 
> time it takes to get the next element in the generator. These are 
> guesses - can you correct me?
N is the total number of suspended generators in the tree(s) of 
generators involved in the operation. Remember that it is possible to 
have multiple generators yield from the same 'parent' generator. The 
'delegation depth' would be the height of that tree.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Christian Heimes | 1 Mar 2009 14:49
Picon

with statement: multiple context manager

Hello fellow Pythonistas!

On a regularly basis I'm bothered and annoyed by the fact that the with
statement takes only one context manager. Often I need to open two files
to read from one and write to the other. I propose to modify the with
statement to accept multiple context manangers.

Example
=======

The nested block::

  with lock:
      with open(infile) as fin:
          with open(outfile, 'w') as fout:
              fout.write(fin.read())

could be written as::

  with lock, open(infile) as fin, open(outfile, 'w') as fout:
      fout.write(fin.read())

The context managers' __enter__() and __exit__() methods are called FILO
(first in, last out). When an exception is raised by the __enter__()
method, the right handed context managers are omitted.

Grammar
=======

I'm not sure if I got the grammar right but I *think* the new grammar
(Continue reading)

Permalink | Reply | 19 comments |
headers
Mathias Panzenböck | 1 Mar 2009 15:30
Picon
Gravatar

Re: with statement: multiple context manager

Why not use this?

from contextlib import nested
with nested(lock, open(infile), open(outfile, 'w')) as (_, fin, fout):
    fout.write(fin.read())

Ok, the _ is ugly, but is it ugly enough so we need this extension to the with 
statement?

	-panzi
Permalink | Reply | 0 comments |
headers
Guido van Rossum | 1 Mar 2009 20:46
Favicon

Re: with statement: multiple context manager

On Sun, Mar 1, 2009 at 5:49 AM, Christian Heimes <lists@...> wrote:
> On a regularly basis I'm bothered and annoyed by the fact that the with
> statement takes only one context manager. Often I need to open two files
> to read from one and write to the other. I propose to modify the with
> statement to accept multiple context manangers.
>
> Example
> =======
>
> The nested block::
>
>  with lock:
>      with open(infile) as fin:
>          with open(outfile, 'w') as fout:
>              fout.write(fin.read())
>
>
> could be written as::
>
>  with lock, open(infile) as fin, open(outfile, 'w') as fout:
>      fout.write(fin.read())
>
>
> The context managers' __enter__() and __exit__() methods are called FILO
> (first in, last out). When an exception is raised by the __enter__()
> method, the right handed context managers are omitted.
>
> Grammar
> =======
>
(Continue reading)

Permalink | Reply | 17 comments |
headers
Eli Courtwright | 1 Mar 2009 20:53

Re: with statement: multiple context manager

On Sun, Mar 1, 2009 at 2:46 PM, Guido van Rossum <guido@...> wrote:
> I am sympathetic to this desire -- I think we almost added this to the
> original PEP but decided to hold off until a clear need was found.

I second the motion to have this syntax added to the language.  I've
often had to write nested with blocks to open one file for reading and
another for writing.

 - Eli
Permalink | Reply | 11 comments |
headers
Chris Rebert | 1 Mar 2009 21:22
Favicon

Re: with statement: multiple context manager

On Sun, Mar 1, 2009 at 11:53 AM, Eli Courtwright <eli <at> courtwright.org> wrote:
> On Sun, Mar 1, 2009 at 2:46 PM, Guido van Rossum <guido <at> python.org> wrote:
>> I am sympathetic to this desire -- I think we almost added this to the
>> original PEP but decided to hold off until a clear need was found.
>
> I second the motion to have this syntax added to the language.  I've
> often had to write nested with blocks to open one file for reading and
> another for writing.

It does seem slightly incongruous though, given that the
for-statement, which is quite similar to the with-statement in that
they both bind new variables in a subsidiary block of code, does not
directly support multiple simultaneous bindings.

To put it more concretely, currently one must write:

for a, b, c in zip(seq1, seq2, seq3):
    #body

Rather than:

for a in seq1, b in seq2, c in seq3:
   #body

But for some reason we're proposing to, in a way, make nested() built
into `with` but not make zip() likewise built into `for`.

While I still mostly like the idea, it does seem to undermine Python's
uniformity a bit.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Daniel Stutzbach | 1 Mar 2009 21:49

Re: "try with" syntactic sugar

On Fri, Feb 27, 2009 at 1:20 PM, Guido van Rossum <guido-+ZN9ApsXKcFQFI55V6+gNQ@public.gmane.orgg> wrote:
On Fri, Feb 27, 2009 at 4:49 AM, Curt Hagenlocher <curt-mb4O9IysIuT8BSalH0K3+A@public.gmane.org> wrote:
> That way lies madness.  What distinguishes "with" from other compound
> statements is that it's already about resource management in the face
> of possible exceptions.

Still, a firm -1 from me. Once we have "try try" I'm sure people are
going to clamor for "try if", "try while", "try for", even (oh horror
:-) "try try". I don't think we should complicate the syntax just to
save one level of indentation occasionally.

In addition to reasons outlined by Curt, "with" is unique because it's short-hand for a "try" block with a "finally" clause.  Unfortunately, "with" doesn't allow for other clauses and so I often end up using both "try" and "with".

Also, "try if", "try while", and "try for" wouldn't work because they already have a meaning for the "else" clause.  "with" does not.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
_______________________________________________
Python-ideas mailing list
Python-ideas@...
http://mail.python.org/mailman/listinfo/python-ideas
Permalink | Reply | 6 comments |
headers
Christian Heimes | 1 Mar 2009 21:57
Picon

Re: with statement: multiple context manager

Chris Rebert wrote:
> While I still mostly like the idea, it does seem to undermine Python's
> uniformity a bit.

I played with both possible versions before I wrote the proposal. Both
ways have their pros and cons. I'm preferring the proposed way::

  with a, b as x, d as y:
       ...

over the other possibility::

  with a, b, c as _, x, y:
      ...

for two reasons. For one I dislike the temporary variable that is
required for some cases, e.g. the case I used in my initial proposal. It
doesn't feel quite right to use a useless placeholder. The proposed way
follows the example of the import statement, too::

  from module import a, b as x, d as y

Christian
Permalink | Reply | 9 comments |
headers
Gregory P. Smith | 1 Mar 2009 22:01
Favicon

Re: with statement: multiple context manager



On Sun, Mar 1, 2009 at 11:46 AM, Guido van Rossum <guido <at> python.org> wrote:
On Sun, Mar 1, 2009 at 5:49 AM, Christian Heimes <lists-RPk2yecm54SELgA04lAiVw@public.gmane.org> wrote:
> On a regularly basis I'm bothered and annoyed by the fact that the with
> statement takes only one context manager. Often I need to open two files
> to read from one and write to the other. I propose to modify the with
> statement to accept multiple context manangers.
>
> Example
> =======
>
> The nested block::
>
>  with lock:
>      with open(infile) as fin:
>          with open(outfile, 'w') as fout:
>              fout.write(fin.read())
>
>
> could be written as::
>
>  with lock, open(infile) as fin, open(outfile, 'w') as fout:
>      fout.write(fin.read())

Alternatively if closer conformity with for loop syntax is desirable consider this:

with lock, open(infile), open(outfile) as lock, fin, fout: 
    fout.fwrite(fin.read())


>
>
> The context managers' __enter__() and __exit__() methods are called FILO
> (first in, last out). When an exception is raised by the __enter__()
> method, the right handed context managers are omitted.
>
> Grammar
> =======
>
> I'm not sure if I got the grammar right but I *think* the new grammar
> should look like::
>
> with_stmt: 'with' with_vars ':' suite
> with_var: test ['as' expr]
> with_vars: with_var (',' with_var)* [',']

I am sympathetic to this desire -- I think we almost added this to the
original PEP but decided to hold off until a clear need was found.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-ideas mailing list
Python-ideas-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org
http://mail.python.org/mailman/listinfo/python-ideas

_______________________________________________
Python-ideas mailing list
Python-ideas@...
http://mail.python.org/mailman/listinfo/python-ideas
Permalink | Reply | 4 comments |

Gmane