Python style: exceptions vs. sys.exit()
Drake
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: 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?
Thanks in advance for anyone who can either answer my question or
point me to where this question has already been answered.
Larry Bates
IMHO libraries should always just let the exception propagate up to the caller.
That allows the caller the option of taking the appropriate action.
-Larry
Grant Edwards
> 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 able to just dump to
> sys.exit() with a message about the error (like "couldn't open this
> file"),
No. A library module should never call sys.exit().
> or should the exception propagate to the calling program which
> handles the issue?
Yes. Let the application handle the error if it wants to. If
it's not handled, it'll end up causing the program to exit.
--
Grant Edwards grante Yow! It's a hole all the
at way to downtown Burbank!
visi.com
Craig Allen
> 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 the calling
program about the error and give the programmer a chance to do
something smart about it. A library, properly, doesn't even know the
context in which it is running, and sys.exit() is pretty heavy handed
for a library to call and shows assumptions beyond what a library
should assume about its running environment.
imho
Terry Reedy
> 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: should the library function be able to just dump to
> sys.exit() with a message about the error (like "couldn't open this
> file"),
No
> or should the exception propagate to the calling program which
> handles the issue?
Yes -- with an informative error message.
If the caller ignores the exception, the program will exit with a full
stack trace anyway.
Christian Heimes
> 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: 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?
Side note:
sys.exit() is just another way to write raise SystemExit. The function
is defined as:
static PyObject *
sys_exit(PyObject *self, PyObject *args)
{
PyObject *exit_code = 0;
if (!PyArg_UnpackTuple(args, "exit", 0, 1, &exit_code))
return NULL;
/* Raise SystemExit so callers may catch it or clean up. */
PyErr_SetObject(PyExc_SystemExit, exit_code);
return NULL;
}
Christian
Steven D'Aprano
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.
Hint: if a library function can't open a file, the application should be
given the opportunity to open a different file. Or do something
completely different instead. Whatever. That's not up to the library to
decide, not even if the library is in such a broken state that it can't
continue. Why not? Because the application might deal with that by
unloading the library and continuing regardless.
--
Steven
Asun Friere
> 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. ;)
Bruno Desthuilliers
> 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: 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 ! NO, DONT !
> or should the exception propagate to the calling program which
> handles the issue?
Yes, by all means and for God's sake.
> Thanks in advance for anyone who can either answer my question or
> point me to where this question has already been answered.
There have been numerous threads about this here.
Carl Banks
> 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 only appropriate action for an IO error?
Even if it is, I will echo other people's advice: a library should
never call exit, at least not by default. For your imagined use it
might make sense to exit upon any failure, but other people using the
library might not want to do that.
For that matter, a library should never print error or status
messages. Messages should either be sent to the caller somehow, or
handled using the logging facility.
Carl Banks
Grant Edwards
> 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 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"), or should the
>> exception propagate to the calling program which handles the issue?
>>
>> Thanks in advance for anyone who can either answer my question or point
>> me to where this question has already been answered.
>
>
> 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.
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.
--
Grant Edwards grante Yow! Mr and Mrs PED, can I
at borrow 26.7% of the RAYON
visi.com TEXTILE production of the
INDONESIAN archipelago?
Tim Rowe
> 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 ! NO, DONT !
Can I put in a vote *for* the questioner's library dumping to
sys.exit() on any abnormal condition? It would reduce employment
competition for the rest of us.
Why, yes, I am wearing my BOFH hat. How could you tell?
--
Tim Rowe
Ross Ridge
> 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 <invalid@invalid> 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.
No, it's more like asking if the failed sensor should turn on a strange
and mysterious light on the dashboard and then blow up the car if the
driver doesn't immediately stop and check the engine. The owners manual
would only vaguely hint at the fact that this could happen.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
Grant Edwards
> Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> 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 <invalid@invalid> 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.
>
> No, it's more like asking if the failed sensor should turn on
> a strange and mysterious light on the dashboard
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.
> and then blow up the car if the driver doesn't immediately
> stop and check the engine. The owners manual would only
> vaguely hint at the fact that this could happen.
--
Grant Edwards grante Yow! Why is it that when
at you DIE, you can't take
visi.com your HOME ENTERTAINMENT
CENTER with you??
Ross Ridge
> 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 <invalid@invalid> 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 <rri...@csclub.uwaterloo.ca> wrote:
> No, it's more like asking if the failed sensor should turn on
> a strange and mysterious light on the dashboard
Grant Edwards <invalid@invalid> 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.
Well, my point was that exceptions in Python are a bit like a car's
check engine light. Few drivers know what this mysterious light means,
and aren't prepared to do anything about it when it goes on.
Bruno Desthuilliers
(snip)
> Grant Edwards <invalid@invalid> 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 <rri...@csclub.uwaterloo.ca> wrote:
>> No, it's more like asking if the failed sensor should turn on
>> a strange and mysterious light on the dashboard
>
> Grant Edwards <invalid@invalid> 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.
>
> Well, my point was that exceptions in Python are a bit like a car's
> check engine light. Few drivers know what this mysterious light means,
> and aren't prepared to do anything about it when it goes on.
You're kidding, aren't you ?
Ross Ridge
> 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 <rri...@csclub.uwaterloo.ca> wrote:
> No, it's more like asking if the failed sensor should turn on
> a strange and mysterious light on the dashboard
Grant Edwards <invalid@invalid> 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.
> Well, my point was that exceptions in Python are a bit like a car's
> check engine light. Few drivers know what this mysterious light means,
> and aren't prepared to do anything about it when it goes on.
Bruno Desthuilliers <bdesth.qu...@free.quelquepart.fr> wrote:
>You're kidding, aren't you ?
Of course not. 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 using the library knows that it could generate that exception
in those circumstances.
Craig Allen
> 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.
Steven D'Aprano
> 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 Python 2.5 specifically so
that SystemExit and KeyboardInterrupt no longer inherit from Exception.
That means this will do the right thing:
try:
process(record)
if changed:
update(record)
except Exception:
# don't write the record if any error occurs
pass
Neither SystemExit nor KeyboardInterrupt are errors, and they should not
be treated as errors. I quote from the Fine Manual:
[SystemExit] inherits from BaseException instead of StandardError or
Exception so that it is not accidentally caught by code that catches
Exception. This allows the exception to properly propagate up and cause
the interpreter to exit.
http://docs.python.org/lib/module-exceptions.html
SystemExit is not an error. KeyboardInterrupt is not an error. Libraries
should not use SystemExit to signal an error any more than they should
use MemoryError to signal a missing attribute.
Whether or not an application exits is up to the application to decide,
not the library it wraps. Libraries should report errors by raising an
Exception (note the capital E), and the application should decide whether
or not it is recoverable, and if not, exit (perhaps by simply not
catching the exception).
--
Steven
Steven D'Aprano
> 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 using the
> library knows that it could generate that exception in those
> circumstances.
That's true, I didn't explicitly say that the library should be
documented. Nor did I say that it shouldn't be riddled with bugs. There's
little practical difference between a buggy library and one that raises
unexpected (i.e. undocumented) exceptions either.
--
Steven
Bruno Desthuilliers
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 etc, it's the caller's responsability
to handle the exceptions that may be raised by what *he* passes to the
library...
Ross Ridge
> 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 using the
> library knows that it could generate that exception in those
> circumstances.
Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> wrote:
>That's true, I didn't explicitly say that the library should be
>documented. Nor did I say that it shouldn't be riddled with bugs. There's
>little practical difference between a buggy library and one that raises
>unexpected (i.e. undocumented) exceptions either.
The problem is that few Python libraries properly document where and
when they might generate exceptions. They'll document the fact that
they have an "error" exception, but only vaguely say which functions or
methods could generate it and why. You need either use trial and error
to find out, or look at the source.
Ross Ridge
>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 etc, it's the caller's responsability
>to handle the exceptions that may be raised by what *he* passes to the
>library...
Ug... that's another documentation pet-peeve of mine. Libraries that
say they take file-like (or whatever-like) object, but don't say exactly
how file-like it needs.
Bruno Desthuilliers
> Bruno Desthuilliers <bruno.42.de...@websiteburo.invalid> 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 etc, it's the caller's responsability
>> to handle the exceptions that may be raised by what *he* passes to the
>> library...
>
> Ug... that's another documentation pet-peeve of mine. Libraries that
> say they take file-like (or whatever-like) object, but don't say exactly
> how file-like it needs.
Seems not to be such a problem in practice...
Ross Ridge
> 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 etc, it's the caller's responsability
> to handle the exceptions that may be raised by what *he* passes to the
> library...
> Ug... that's another documentation pet-peeve of mine. Libraries that
> say they take file-like (or whatever-like) object, but don't say exactly
> how file-like it needs.
Bruno Desthuilliers <bruno.42.de...@websiteburo.invalid> wrote:
>Seems not to be such a problem in practice...
Not if you don't mind figuring out such things by trial and error or
looking at the source.
Lie
No, the library author can always predict which exception his library
may raise. If a callback function, file-like, dict-like, etc raises an
exception, it is not his libraries' exception anymore and is not his
responsibility. In that case we should refer to the documentation for
the callback/etc/etc instead of the documentation for the library.
Lawrence D'Oliveiro
> 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? :)
Bruno Desthuilliers
> In message <gbgu3v$mie$1...@rumours.uwaterloo.ca>, 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 quick description of what and how for classes and functions) really
helps. But when it comes to nitty-gritty details, source code is the
best documentation ever, since it's always accurate and up to date.
FWIW, I'm often surprised by people asking questions about some
implementation detail of some open-source library or framework that are
very easily answered just looking at the source code. Reading the source
is 1/ the best way to really know how something is implemented and 2/
usually very instructive.
Steven D'Aprano
Reading the source code is good, but it's not a panacea. There are at
least four things wrong with the advice to read the source code:
(1) It's not always available.
(2) Even when the source is available, it is sometimes a legal trap to
read it with respect to patents and copyright. E.g. some Microsoft so-
called "open" licences (but not all) allow you to read the source, but if
you do then everything you program in a related field from that point is
legally contaminated and could be considered a derivative work of
Microsoft's software.
(3) Source code not always understandable without significant effort.
Code can be obfuscated, either to hide the algorithm, as an optimization,
or simply because the coder is cleverer than you are. It might be in a
language you don't understand (e.g. Python built-ins are written in C,
not Python. I have to learn C to find out what exceptions sorted() can
raise?).
That's why accurate documentation should be preferred in the first place:
it is easier to read and understand. It might take you hours of hard
study to learn that function spam(x) raises ValueError if the argument is
invalid, or two seconds to read it in the docs.
Yes, documentation can fall behind the source code, but once the code is
stable and the documentation has caught up and is accurate, there's no
reason to re-invent the wheel by slugging through the source just to find
out something already documented.
(4) Even when the source code is available, legally unencumbered, in a
language you understand and not too complicated for you to grasp, there's
the combinatorial explosion: you may need to read and understand an
arbitrarily large and complex chain of software merely to know what a
single function can do. E.g. you want to know what exceptions function
spam() can raise:
def spam(x):
a = 1
b = 2
c = ham(x)
return fried_eggs(a, b, c)
Now you need to understand ham() and fried_eggs(), but they aren't
documented either. So you turn to their source code, and each of them
call two functions, each of which call another two functions, each of
which call *another* two functions...
How much source code are you expected to read just to understand the four-
line function spam()?
--
Steven
Lawrence D'Oliveiro
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.
Bruno Desthuilliers
>
>> Lawrence D'Oliveiro a écrit :
>>> In message <gbgu3v$mie$1...@rumours.uwaterloo.ca>, 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 quick description of what and how for classes and functions) really
>> helps. But when it comes to nitty-gritty details, source code is the
>> best documentation ever, since it's always accurate and up to date.
>>
>> FWIW, I'm often surprised by people asking questions about some
>> implementation detail of some open-source library or framework that are
>> very easily answered just looking at the source code. Reading the source
>> is 1/ the best way to really know how something is implemented and 2/
>> usually very instructive.
>
> Reading the source code is good, but it's not a panacea.
Not what I implied.
> There are at
> least four things wrong with the advice to read the source code:
My "advice to read the source code" was not meant as a *replacement* for
documentation, but as a *complement* to it. What I meant is that you
just can't document each and every detail of implementation.
>
> (1) It's not always available.
>
> (2) Even when the source is available, it is sometimes a legal trap to
> read it with respect to patents and copyright. E.g. some Microsoft so-
> called "open" licences (but not all) allow you to read the source, but if
> you do then everything you program in a related field from that point is
> legally contaminated and could be considered a derivative work of
> Microsoft's software.
I obviously implied that source was freely available and you had the
right to read it. Else it just makes no sense.
> (3) Source code not always understandable without significant effort.
That's why reading the source can have a great educational value, isn't
it ?-)
> Code can be obfuscated, either to hide the algorithm,
same problem as closed-source software - not concerned by this advice.
> as an optimization,
> or simply because the coder is cleverer than you are. It might be in a
> language you don't understand (e.g. Python built-ins are written in C,
> not Python. I have to learn C to find out what exceptions sorted() can
> raise?).
Every developer should have at least basic knowledge of C. MHO of course.
> That's why accurate documentation should be preferred in the first place.
Indeed. Did I say otherwise ? Now not all code has accurate
documentation, and then you're happy to be able to access and possibly
understand the source code. I'm not talking about an ideal world here.
(snip)
> Yes, documentation can fall behind the source code, but once the code is
> stable and the documentation has caught up and is accurate, there's no
> reason to re-invent the wheel by slugging through the source just to find
> out something already documented.
Once again, that's not what I said.
> (4) Even when the source code is available, legally unencumbered, in a
> language you understand and not too complicated for you to grasp, there's
> the combinatorial explosion: you may need to read and understand an
> arbitrarily large and complex chain of software merely to know what a
> single function can do.
Yes, this happens when hi-level documentation is lacking. At least you
have a chance to gain some insight !-)
> E.g. you want to know what exceptions function
> spam() can raise:
>
> def spam(x):
> a = 1
> b = 2
> c = ham(x)
> return fried_eggs(a, b, c)
>
> Now you need to understand ham() and fried_eggs(), but they aren't
> documented either. So you turn to their source code, and each of them
> call two functions, each of which call another two functions, each of
> which call *another* two functions...
And still you're a lucky guy if there's no callback, conditional import
and / or polymorphic dispatch involved.
Steve, I may not have been clear, but I didn't meant that code shouldn't
be documented. I was :
1/ answering to the question "So what's wrong with using the source as
documentation?", my own personal answer being that it's something I
often do, whether because I want to find out some detail not covered by
the available documentation, whatever this available documention is worth
2/ digressing about the fact that, to my suprise, few developpers seem
to *first* have a look at the source code when either documentation is
lacking or they'd like to know more about some implementation detail.
But FWIW, it seems that few developpers even bother reading the
documentation at all :(
greg
I don't think that's how copyrights work either. As far as
I know, whether something is deemed a derivative work is
judged on the basis of how similar it is to another work,
not whether its author had knowledge of the other work.
As long as you express an idea in an original way, it
shouldn't matter where you got the idea from.
--
Greg
Steven D'Aprano
That is absolutely not the case with patents. It is *supposed* to be the
case with copyrights, but in practice the courts are interpreting
"derivative work" more and more broadly these days.
As for Microsoft Shared Source licences, there are two which are approved
by the FSF, but the others are a whole different story.
You will note that both the GNU project and the Mono project warn against
reading proprietary source code before contributing. Mono even goes so
far as to say that if you have read the source code to .NET, they cannot
accept your contributions:
If you have looked at Microsoft's implementation of .NET or
their shared source code, you will not be able to contribute
to Mono.
In general, be careful when you are implementing free software
and you have access to proprietary code. We need to make sure
that we are not using someone else's copyrighted code
accidentally.
http://www.mono-project.com/Contributing
--
Steven
Grant Edwards
IANAL, but IIRC it does matter when it comes to establishing
punative damages. If you knowingly and intentionally infringe
a patent, I think you're libel for more damages than if you
accidentally re-invent something. At least that's what I was
told...
--
Grant Edwards grante Yow! Thousands of days of
at civilians ... have produced
visi.com a ... feeling for the
aesthetic modules --
J. Cliff Dyer
On Fri, 2008-10-03 at 09:15 -0500, Grant Edwards wrote:
> On 2008-10-03, greg <gr...@cosc.canterbury.ac.nz> wrote:
> > Lawrence D'Oliveiro wrote:
> >> In message <00f15d41$0$20617$c3e...@news.astraweb.com>, 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 know, whether something is deemed a derivative work is
> > judged on the basis of how similar it is to another work,
> > not whether its author had knowledge of the other work.
> > As long as you express an idea in an original way, it
> > shouldn't matter where you got the idea from.
>
> IANAL, but IIRC it does matter when it comes to establishing
> punative damages. If you knowingly and intentionally infringe
> a patent, I think you're libel for more damages than if you
> accidentally re-invent something. At least that's what I was
> told...
>
s/libel/liable/
When talking about legal matters, it's kind of an important distinction.
Grant Edwards
Of course.
> When talking about legal matters, it's kind of an important
> distinction.
Once again we see why a spell-checker is no substitue for
proof-reading.
A bit of googling finds that 35 USC 284 allows the court to
increase damages up to triple the compensatory value. Whether
or not the infringement was willful is often a primary
consideration in that decision.
http://www.invention-protection.com/ip/publications/docs/Damage_Relief_for_Patent_Infringement.html
http://www.ipwatchdog.com/willful_patent_infringement.html
http://www.law.duke.edu/journals/dltr/articles/2007DLTR0006.html
If the infringer never new the invention was patented, then the
infringement can't be willful.
--
Grant Edwards grante Yow! I'm ANN LANDERS!!
at I can SHOPLIFT!!
visi.com
Steven D'Aprano
> On 2008-10-03, greg <gr...@cosc.canterbury.ac.nz> wrote:
>> Lawrence D'Oliveiro wrote:
>>> In message <00f15d41$0$20617$c3e...@news.astraweb.com>, 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 know,
>> whether something is deemed a derivative work is judged on the basis of
>> how similar it is to another work, not whether its author had knowledge
>> of the other work. As long as you express an idea in an original way,
>> it shouldn't matter where you got the idea from.
>
> IANAL, but IIRC it does matter when it comes to establishing punative
> damages. If you knowingly and intentionally infringe a patent, I think
> you're libel for more damages than if you accidentally re-invent
> something. At least that's what I was told...
Yes. Under US Patent Law, if you intentionally infringe a patent you are
liable (not libel, which is like slander) to triple damages.
Unfortunately the meaning of "intentionally" is horribly broad: if you do
a patent search and find a patent which you don't think covers your
invention, but a court later decides that it does, that counts as
intentional infringement. But if you don't do a patent search at all, any
such infringement must be accidental.
Yes, this is incredibly broken. Economists and lawyers call it a
"perverse incentive":
"Finally, the provision for treble damages for willful infringement
actually creates a perverse incentive not to know about patents that
might be infringed. If a search is undertaken and knowledge of potential
infringement is obtained, then the willfulness provision will be
triggered and the infringer may be liable for treble damages. On the
other hand, without a search there can be no knowledge, and no willful
infringement."
http://www.law.washington.edu/lct/swp/Law/patents.html
Under Germany patent law, there is no difference in damages for
intentional, negligent or accidental infringement, hence no punitive
damages and no triple punishment for doing a patent search:
http://www.ficpi.org/library/lisbonForum/2-6_Hufnagel.ppt
--
Steven