> except:
> return 0
So wrong on so many levels...
--
http://mail.python.org/mailman/listinfo/python-list
En Thu, 10 Sep 2009 08:26:16 -0300, David C. Ullrich
escribió:
On Wed, 9 Sep 2009 15:13:49 -0700 (PDT), r wrote:
On Sep 9, 4:19 pm, Charles Yeomans wrote:
I removed the except block because I prefer exceptions to error codes.
how will the caller know an exception has occurred? What if l
On Wed, 9 Sep 2009 15:13:49 -0700 (PDT), r wrote:
>On Sep 9, 4:19 pm, Charles Yeomans wrote:
>(snip:)
>> Unfortunately, both of these simple templates have the following
>> problem -- if open fails, a NameError will be raised from the finally
>> block.
>
>(snip)
>> I removed the except block
On Sep 9, 4:19 pm, Charles Yeomans wrote:
(snip:)
> Unfortunately, both of these simple templates have the following
> problem -- if open fails, a NameError will be raised from the finally
> block.
(snip)
> I removed the except block because I prefer exceptions to error codes.
how will the c
On Sep 9, 2009, at 4:50 PM, r wrote:
On Sep 9, 3:18 pm, David C Ullrich wrote:
(snip)
These days I've actually got the syntax and spelling memorized -
I can type "close()" without needing to look it up!
+1
You are so right David! I think some people around here need to look
up "code reuse"
r wrote:
[snip]
#-- Double Extra Creidit --#
Create a backup_file() function that takes as arg and
creates a copy of the file with the extension ".bak"...
backup_file('C:\test.txt') -> 'C:\test.bak'
You should've used raw strings. :-)
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 9, 3:18 pm, David C Ullrich wrote:
(snip)
> These days I've actually got the syntax and spelling memorized -
> I can type "close()" without needing to look it up!
+1
You are so right David! I think some people around here need to look
up "code reuse". Here are a couple of simple templates
On Sat, 05 Sep 2009 23:41:08 +, Steven D'Aprano wrote:
> On Sat, 05 Sep 2009 16:14:02 +, kj wrote:
>
>> Finally, I was under the impression that Python closed filehandles
>> automatically when they were garbage-collected.
[...]
>
> (3) For quick and dirty scripts, or programs that only u
En Sun, 06 Sep 2009 21:20:52 -0300, Stephen Hansen
escribió:
On Sun, Sep 6, 2009 at 4:31 PM, r wrote:
On Sep 6, 1:14 pm, "Jan Kaliszewski" wrote:
> 05-09-2009 r wrote:
> > i find the with statement (while quite useful in general
> > practice) is not a "cure all" for situations that need a
On Sun, Sep 6, 2009 at 4:31 PM, r wrote:
> On Sep 6, 1:14 pm, "Jan Kaliszewski" wrote:
> > 05-09-2009 r wrote:
> > > i find the with statement (while quite useful in general
> > > practice) is not a "cure all" for situations that need and exception
> > > caught.
> >
> > In what sense?
>
> *ahem
On Sep 6, 1:14 pm, "Jan Kaliszewski" wrote:
> 05-09-2009 r wrote:
> > i find the with statement (while quite useful in general
> > practice) is not a "cure all" for situations that need and exception
> > caught.
>
> In what sense?
*ahem*! in the sense that the with statement (while quite useful
05-09-2009 r wrote:
i find the with statement (while quite useful in general
practice) is not a "cure all" for situations that need and exception
caught.
In what sense?
I think that:
with open(...) as f:
foo...
is equivalent to:
f = open(...)
try:
foo...
finally:
>
> It's just too bad that 'with' doesn't support multiple separate "x as y"
>> clauses.
>>
>
> The developers already agreed with you ;-).
>
> "With more than one item, the context managers are processed as if multiple
> with statements were nested:
>
> with A() as a, B() as b:
>suite
> is equ
Stephen Hansen wrote:
This is precisely why the with statement exists; to provide a cleaner
way to wrap a block in setup and teardown functions. Closing is one.
Yeah, you get some extra indentation-- but you sorta have to live with
it if you're worried about correct code. I think it's a good c
On Sat, Sep 5, 2009 at 6:51 PM, kj wrote:
> In <02b2e6ca$0$17565$c3e8...@news.astraweb.com> Steven D'Aprano <
> st...@remove-this-cybersource.com.au> writes:
>
> >(3) For quick and dirty scripts, or programs that only use one or two
> >files, relying on the VM to close the file is sufficient (alt
On Sun, 06 Sep 2009 01:51:50 +, kj wrote:
> In <02b2e6ca$0$17565$c3e8...@news.astraweb.com> Steven D'Aprano
> writes:
>
>>(3) For quick and dirty scripts, or programs that only use one or two
>>files, relying on the VM to close the file is sufficient (although lazy
>>in my opinion *wink*)
>
In <02b2e6ca$0$17565$c3e8...@news.astraweb.com> Steven D'Aprano
writes:
>(3) For quick and dirty scripts, or programs that only use one or two
>files, relying on the VM to close the file is sufficient (although lazy
>in my opinion *wink*)
It's not a matter of laziness or industriousness, but
On Sat, 05 Sep 2009 16:14:02 +, kj wrote:
> Finally, I was under the impression that Python closed filehandles
> automatically when they were garbage-collected. (In fact (3) suggests
> as much, since it does not include an implicit call to fh.close.) If so,
> the difference between (1) and (3
On Sep 5, 2:47 pm, Dennis Lee Bieber wrote:
(snip)
> > Finally, I was under the impression that Python closed filehandles
> > automatically when they were garbage-collected. (In fact (3)
> > suggests as much, since it does not include an implicit call to
> > fh.close.) If so, the difference betwe
CPython uses reference counting, so an object is garbage collected as
soon as there are no references to it, but that's just an implementation
detail.
Other implementations, such as Jython and IronPython, don't use
reference counting, so you don't know when an object will be garbage
collected, wh
On Sep 5, 1:17 pm, Dave Angel wrote:
> kj wrote:
> > There's something wonderfully clear about code like this:
>
> > # (1)
> > def spam(filename):
> > for line in file(filename):
> > do_something_with(line)
>
> > It is indeed pseudo-codely beautiful. But I gather that
kj wrote:
There's something wonderfully clear about code like this:
# (1)
def spam(filename):
for line in file(filename):
do_something_with(line)
It is indeed pseudo-codely beautiful. But I gather that it is not
correct to do this, and that instead one should do som
kj wrote:
There's something wonderfully clear about code like this:
# (1)
def spam(filename):
for line in file(filename):
do_something_with(line)
It is indeed pseudo-codely beautiful. But I gather that it is not
correct to do this, and that instead one should do
There's something wonderfully clear about code like this:
# (1)
def spam(filename):
for line in file(filename):
do_something_with(line)
It is indeed pseudo-codely beautiful. But I gather that it is not
correct to do this, and that instead one should do something l
24 matches
Mail list logo
