On Fri, 03 Oct 2008 09:15:35 -0500, Grant Edwards wrote:
> On 2008-10-03, greg <[EMAIL PROTECTED]> wrote:
>> Lawrence D'Oliveiro wrote:
>>> In message <[EMAIL PROTECTED]>, Steven
>>> D'Aprano wrote:
>>>
>>> > (2) Even when the source is available, it is sometimes a legal trap
>>> > to read it wit
On 2008-10-03, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-10-03 at 09:15 -0500, Grant Edwards wrote:
>> On 2008-10-03, greg <[EMAIL PROTECTED]> wrote:
>> > Lawrence D'Oliveiro wrote:
>> >> In message <[EMAIL PROTECTED]>, Steven D'Aprano
>> >> wrote:
>> >>
>> >> > (2) Even when the s
On Fri, 2008-10-03 at 09:15 -0500, Grant Edwards wrote:
> On 2008-10-03, greg <[EMAIL PROTECTED]> wrote:
> > Lawrence D'Oliveiro wrote:
> >> In message <[EMAIL PROTECTED]>, Steven D'Aprano
> >> wrote:
> >>
> >> > (2) Even when the source is available, it is sometimes a legal trap to
> >> > read i
On 2008-10-03, greg <[EMAIL PROTECTED]> wrote:
> Lawrence D'Oliveiro wrote:
>> In message <[EMAIL PROTECTED]>, Steven D'Aprano
>> wrote:
>>
>> > (2) Even when the source is available, it is sometimes a legal trap to
>> > read it with respect to patents and copyright.
>>
>> That's not how patents
On Fri, 03 Oct 2008 17:09:07 +1200, greg wrote:
> Lawrence D'Oliveiro wrote:
>> In message <[EMAIL PROTECTED]>, Steven
>> D'Aprano wrote:
>>
>> > (2) Even when the source is available, it is sometimes a legal trap
>> > to read it with respect to patents and copyright.
>>
>> That's not how patent
Lawrence D'Oliveiro wrote:
In message <[EMAIL PROTECTED]>, Steven D'Aprano
wrote:
> (2) Even when the source is available, it is sometimes a legal trap to
> read it with respect to patents and copyright.
That's not how patents work.
I don't think that's how copyrights work either. As far as
I
Steven D'Aprano a écrit :
On Mon, 29 Sep 2008 18:27:22 +0200, Bruno Desthuilliers wrote:
Lawrence D'Oliveiro a écrit :
In message <[EMAIL PROTECTED]>, Ross Ridge wrote:
You need either use trial and error to find out, or look at the
source.
So what's wrong with using the source as documenta
In message <[EMAIL PROTECTED]>, Steven D'Aprano
wrote:
> (1) It's not always available.
But we're talking about Python libraries here, right?
> (2) Even when the source is available, it is sometimes a legal trap to
> read it with respect to patents and copyright.
That's not how patents work.
--
On Mon, 29 Sep 2008 18:27:22 +0200, Bruno Desthuilliers wrote:
> Lawrence D'Oliveiro a écrit :
>> In message <[EMAIL PROTECTED]>, Ross Ridge wrote:
>>
>>> You need either use trial and error to find out, or look at the
>>> source.
>>
>> So what's wrong with using the source as documentation? :)
Lawrence D'Oliveiro a écrit :
In message <[EMAIL PROTECTED]>, Ross Ridge wrote:
You need either use trial and error to find out, or look at the source.
So what's wrong with using the source as documentation? :)
Don't know... Ok, having higher-level documentation (the big picture,
and quic
In message <[EMAIL PROTECTED]>, Ross Ridge wrote:
> You need either use trial and error to find out, or look at the source.
So what's wrong with using the source as documentation? :)
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 25, 3:05 pm, Bruno Desthuilliers wrote:
> Steven D'Aprano a écrit :
>
> > On Wed, 24 Sep 2008 17:11:28 -0400, Ross Ridge wrote:
>
> >> Plenty of people were quick to say that the exception should be passed
> >> through to the caller. No one said this behaviour should be documented.
> >> T
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> Also note that there are quite a couples cases where the library authors
> themselves cannot predict which exception types may be raised - as soon
> as the library functions expect callback functions, file-like or
> dict-like or whatever-like obj
Ross Ridge a écrit :
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
Also note that there are quite a couples cases where the library authors
themselves cannot predict which exception types may be raised - as soon
as the library functions expect callback functions, file-like or
dict-like or wh
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>Also note that there are quite a couples cases where the library authors
>themselves cannot predict which exception types may be raised - as soon
>as the library functions expect callback functions, file-like or
>dict-like or whatever-like objects
Ross Ridge wrote:
> Plenty of people were quick to say that the exception should be passed
> through to the caller. No one said this behaviour should be documented.
> There may be little practical difference bewteen calling sys.exit()
> after printing an error and progating an exception if no one
Steven D'Aprano a écrit :
On Wed, 24 Sep 2008 17:11:28 -0400, Ross Ridge wrote:
Plenty of people were quick to say that the exception should be passed
through to the caller. No one said this behaviour should be documented.
There may be little practical difference bewteen calling sys.exit()
af
On Wed, 24 Sep 2008 17:11:28 -0400, Ross Ridge wrote:
> Plenty of people were quick to say that the exception should be passed
> through to the caller. No one said this behaviour should be documented.
> There may be little practical difference bewteen calling sys.exit()
> after printing an error
On Wed, 24 Sep 2008 10:54:40 -0500, Grant Edwards wrote:
> You're right. I had forgotten that sys.exit() is actually raising the
> system exit exception, and that the application calling the library
> could handle that exception.
Could but shouldn't.
The exception hierarchy was re-designed in P
> Why, yes, I am wearing my BOFH hat. How could you tell?
>
> --
> Tim Rowe
evil, but I think you may be a BSEFH, not a BOFH.
--
http://mail.python.org/mailman/listinfo/python-list
Grant Edwards <[EMAIL PROTECTED]> wrote:
> Same here. It's like an automotive engine controls designer
> asking if a failed O2 sensor should turn on the check engine
> light or blow up the car.
Ross Ridge <[EMAIL PROTECTED]> wrote:
> No, it's more like asking if the failed sensor should turn on
Ross Ridge a écrit :
(snip)
Grant Edwards <[EMAIL PROTECTED]> wrote:
Same here. It's like an automotive engine controls designer
asking if a failed O2 sensor should turn on the check engine
light or blow up the car.
Ross Ridge <[EMAIL PROTECTED]> wrote:
No, it's more like asking if the fail
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> Presumably somebody has suggested that calling sys.exit() was a good
> option. I'm curious to what possible reason they could give for such a
> poor choice.
Grant Edwards <[EMAIL PROTECTED]> wrote:
>Same here. It's like an automotive engine controls
On 2008-09-24, Ross Ridge <[EMAIL PROTECTED]> wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>> Presumably somebody has suggested that calling sys.exit() was a good
>> option. I'm curious to what possible reason they could give for such a
>> poor choice.
>
> Grant Edwards <[EMAIL PROTECTED]
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> Presumably somebody has suggested that calling sys.exit() was a good
> option. I'm curious to what possible reason they could give for such a
> poor choice.
Grant Edwards <[EMAIL PROTECTED]> wrote:
>Same here. It's like an automotive engine controls
2008/9/24 Bruno Desthuilliers <[EMAIL PROTECTED]>:
> Drake a écrit :
>> many of the library functions to raise IOError Exceptions. The
>> question is: should the library function be able to just dump to
>> sys.exit() with a message about the error (like "couldn't open this
>> file"),
>
> Arrghll !
On 2008-09-24, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Sep 2008 13:25:26 -0700, Drake wrote:
>
>> I have a general question of Python style, or perhaps just good
>> programming practice.
>>
>> My group is developing a medium-sized library of general-purpose Python
>> functions, som
On Sep 23, 4:25 pm, Drake <[EMAIL PROTECTED]> wrote:
> The
> question is: should the library function be able to just dump to
> sys.exit() with a message about the error (like "couldn't open this
> file"),
I'm kind of curious what your library is for. Is it something where
exiting the app be the
Drake a écrit :
I have a general question of Python style, or perhaps just good
programming practice.
My group is developing a medium-sized library of general-purpose
Python functions, some of which do I/O. Therefore it is possible for
many of the library functions to raise IOError Exceptions. T
On Sep 24, 8:10 am, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Side note:
>
> sys.exit() is just another way to write raise SystemExit. The function
> is defined as:
>
As can be seen if you were ever silly enough to call sys.exit() in
IDLE. ;)
--
http://mail.python.org/mailman/listinfo/python-
On Tue, 23 Sep 2008 13:25:26 -0700, Drake wrote:
> I have a general question of Python style, or perhaps just good
> programming practice.
>
> My group is developing a medium-sized library of general-purpose Python
> functions, some of which do I/O. Therefore it is possible for many of
> the libr
Drake wrote:
I have a general question of Python style, or perhaps just good
programming practice.
My group is developing a medium-sized library of general-purpose
Python functions, some of which do I/O. Therefore it is possible for
many of the library functions to raise IOError Exceptions. The
Drake wrote:
I have a general question of Python style, or perhaps just good
programming practice.
My group is developing a medium-sized library of general-purpose
Python functions, some of which do I/O. Therefore it is possible for
many of the library functions to raise IOError Exceptions. The
> The
> question is: should the library function be able to just dump to
> sys.exit() with a message about the error (like "couldn't open this
> file"), or should the exception propagate to the calling program which
> handles the issue?
>
my view is that the exceptions are there precisely to tell
On 2008-09-23, Drake <[EMAIL PROTECTED]> wrote:
> My group is developing a medium-sized library of general-purpose
> Python functions, some of which do I/O. Therefore it is possible for
> many of the library functions to raise IOError Exceptions. The
> question is: should the library function be a
Drake wrote:
I have a general question of Python style, or perhaps just good
programming practice.
My group is developing a medium-sized library of general-purpose
Python functions, some of which do I/O. Therefore it is possible for
many of the library functions to raise IOError Exceptions. The
I have a general question of Python style, or perhaps just good
programming practice.
My group is developing a medium-sized library of general-purpose
Python functions, some of which do I/O. Therefore it is possible for
many of the library functions to raise IOError Exceptions. The
question is: sh
37 matches
Mail list logo
