On Tue, Jan 13, 2009 at 11:12 PM, Carl Johnson <carl@carlsensei.com> wrote:

From the department of doomed ideas:

data = f.read() with open("file.txt") as f

Has the idea of a with-expression already been preemptively shot down?

I guess the objection is that the above could easily be rewritten as

data = read_and_close("file.txt")

if one defines the appropriate function. The counter-objection is that why do I need to write a micro-function when the with-statement already does what I want, except it takes up two lines when it would still be clear as one line. But then the counter-counter-objection is that you can write

with open("file.txt") as f: data = f.read()

today. To which the counter-counter-counter-objection is, yeah, but that looks cluttered and ugly in a way that the first example doesn't... Except the first example is sort of cluttered.

I dunno, what do other people think about this? Doomed or super-doomed?

Fairly doomed, IMHO. To be consistent at all, Python would also have to allow the related Perlisms of: x **= 2 while x < y x += y for y in z x.sort() if should_sort which seem pretty gross to me as the control structure gets somewhat hidden. And as you pointed out, it's just plain unnecessary since such code can already be written as a one-liner, with the advantage of less reformatting if it later becomes a multiliner. Also, having a consistent order of block-statement before block-body enhances the uniformity of the language. About the only good examples of block bodies coming before block statements which I can think of offhand are do-while and Haskell's `where` clause, which both seem to me to be sufficiently special cases as to not have bearing here. That's my 2¢ anyway. Cheers, Chris -- Follow the path of the Iguana... http://rebertia.com

strippedLines = [sline for line in lines with line.strip() as sline if sline] or something like that. :P (-1) -panzi Carl Johnson schrieb:

From the department of doomed ideas:

data = f.read() with open("file.txt") as f

Has the idea of a with-expression already been preemptively shot down?

I guess the objection is that the above could easily be rewritten as

data = read_and_close("file.txt")

if one defines the appropriate function. The counter-objection is that why do I need to write a micro-function when the with-statement already does what I want, except it takes up two lines when it would still be clear as one line. But then the counter-counter-objection is that you can write

with open("file.txt") as f: data = f.read()

today. To which the counter-counter-counter-objection is, yeah, but that looks cluttered and ugly in a way that the first example doesn't... Except the first example is sort of cluttered.

I dunno, what do other people think about this? Doomed or super-doomed?

-- Carl

On Tue, Jan 13, 2009 at 11:12 PM, Carl Johnson <carl@carlsensei.com> wrote:

From the department of doomed ideas:

data = f.read() with open("file.txt") as f

Has the idea of a with-expression already been preemptively shot down?

I guess the objection is that the above could easily be rewritten as

data = read_and_close("file.txt")

if one defines the appropriate function. The counter-objection is that why do I need to write a micro-function when the with-statement already does what I want, except it takes up two lines when it would still be clear as one line. But then the counter-counter-objection is that you can write

with open("file.txt") as f: data = f.read()

today. To which the counter-counter-counter-objection is, yeah, but that looks cluttered and ugly in a way that the first example doesn't... Except the first example is sort of cluttered.

I dunno, what do other people think about this? Doomed or super-doomed?

Fairly doomed, IMHO. To be consistent at all, Python would also have to allow the related Perlisms of: x **= 2 while x < y x += y for y in z x.sort() if should_sort which seem pretty gross to me as the control structure gets somewhat hidden. And as you pointed out, it's just plain unnecessary since such code can already be written as a one-liner, with the advantage of less reformatting if it later becomes a multiliner. Also, having a consistent order of block-statement before block-body enhances the uniformity of the language. About the only good examples of block bodies coming before block statements which I can think of offhand are do-while and Haskell's `where` clause, which both seem to me to be sufficiently special cases as to not have bearing here. That's my 2¢ anyway. Cheers, Chris -- Follow the path of the Iguana... http://rebertia.com

strippedLines = [sline for line in lines with line.strip() as sline if sline] or something like that. :P (-1) -panzi Carl Johnson schrieb:

From the department of doomed ideas:

data = f.read() with open("file.txt") as f

Has the idea of a with-expression already been preemptively shot down?

I guess the objection is that the above could easily be rewritten as

data = read_and_close("file.txt")

if one defines the appropriate function. The counter-objection is that why do I need to write a micro-function when the with-statement already does what I want, except it takes up two lines when it would still be clear as one line. But then the counter-counter-objection is that you can write

with open("file.txt") as f: data = f.read()

today. To which the counter-counter-counter-objection is, yeah, but that looks cluttered and ugly in a way that the first example doesn't... Except the first example is sort of cluttered.

I dunno, what do other people think about this? Doomed or super-doomed?

-- Carl