Home Original page

try: finally: question

Antoon Pardon apardon at forel.vub.ac.be
Thu Jul 8 10:43:12 EDT 2004 
Op 2004-07-08, Peter Hansen schreef <peter at engcorp.com>:
> Antoon Pardon wrote:
>
>> Op 2004-07-07, Peter Hansen schreef <peter at engcorp.com>:
>> Personnaly I think that allowing += operators for unmutable
>> object will lead to subtle bugs too, because if you see
>> code like
>> 
>>   b = a
>>   a += c
>> 
>> You don't know whether a and b are still the same object or not.
>
> I agree with you on this one.  I don't like the way += etc
> works.  Also don't use it except for integers...
>
>> Well I think it really isn't that hard to define the behaviour
>> of 
>> 
>> try:
>> except expr1:
>> finaly:
>> except expr2:
>> 
>> to be the same as
>> 
>> try:
>>   try:
>>     try:
>>     except expr1:
>>   finaly:
>> except expr2:
>
> Interesting, except that this is *not* how it was implemented
> before.  Why don't you write a PEP and see if you can get your
> solution to the problem implemented?  Presenting it as a reason
> why the previous, *different* solution should have been kept
> doesn't make sense.
>
>> However I'm not going to write a PEP. 
>
> Dang.

Well I might reconsider. But I have no experience with this
whatsoever and my impression is that it is a rather involved
undertaking. In any case I doubt that it will be accepted
for the following reason: The proposal suggest that

  try:
  except expr1:
  except expr2:

would be the same as

  try:
    try:
    except expr1:
  except expr2

which isn't the case

So maybe defining behaviour that is consistent with current
behaviour wouldn't be so simple after all.


>> Maybe the python community should make up its mind and decide
>> what it wants. A language for consenting adults or protection
>> against subtle bugs.
>
> It wants to avoid subtle bugs, but unfortunately it sometimes
> makes mistakes in how it does that.
>
>> One can argue the opposite too. Why remove it, if the subtle
>> bugs can occur only in unusual cases. Let those who need it
>> and know what they are doing use it. That is what I understand
>> about a language for consenting adults.
>
> You misunderstand (IMHO) what "consenting adults" is about.
> I tried to make the point in a previous thread about subtle
> problems with threads... some types of bugs are too subtle
> to allow the consenting adults thing to hold sway.  That's
> just my opinion, though.  I'm not sure it's really shared by
> anyone else in the community.

The problem is, everybody has an other opinion about which
types of bugs are too subtle. People who want to put some
feature in the language that can limit the programmer
mostly do because they want to avoid bugs which they consider
too subtle, so how do we determine which bugs are realy
too subtle and which are not?  My impresion here is that
most people just use themselves as yardstick here and
declares those bugs that are too subtle for them as
being too subtle in general. IMO if you don't like it
when others say a feature will introduce too subtle
bugs too allow, when you feel you will be able to
cope, you shouldn't use the same argument. If you are
not comfortable with something, just avoid it and
code in a different way instead of making it impossible
for others to use.

> Threads I happen to know very well, and know many (but perhaps
> not all) of the risks involved.  I also know very many good
> programmers who don't really understand threading issues
> fully, yet.  Nobody knows how to test well for threading
> problems, so advice like "always use a Queue" is best.

Sure, but lets look at the problem of not allowing one
thread to pause, interrupt or raise an exception in
an other thread. The defense for not allowing these
things has been that they would introduce suble bugs.

However it is my feeling that not allowing them will
sometimes complicate the code unnecessary. Suppose
you have a very complicated algorithm that you want
to start in a seperate thread. Suppose that this is
in a gui program and you want to allow the user
to interrupt the process if he finds it is taking too
long. Since this is not just a while loop, you are
now obligated to springle the code with test that
check whether or not the user wants to interrupt.

If one thread could raise an exception in an other
one, this could be far easier.

I agree Queues are in general a good solution, but
sometimes they are not and cramming a situation
that doesn't fit a Queue in one anyway just increases
the mess.

> Exceptions are not generally things that are exercised by
> normal application runs, or even by most unit tests (unless
> you are doing test-driven development).  Therefore subtle
> problems with exceptions should be "disallowed" by appropriate
> language changes.

I don't agree with that logic.

> Something like += should work exactly like people expect
> it to.  The fact that it sometimes doesn't means it is a
> wart and we should reconsider it.  That probably won't happen,
> so we're stuck with it. (?)

Well I wouldn't mind if it wouldn't work exactly as I expected.
What I expect is not always correct. However I do think that
it is important that behaviour in a language is consistent.
If += would always have yielded a new object, that is something
I could have more easily lived with because after maybe a first
surprise the behaviour would be consistent and thus predictable.

> The thing that "consenting adults" usually applies to is
> either access control (private, public, etc), or types.
> Improvements in the area of types are expected in the future,
> so let's ignore that one.  Access control: this is now
> pretty well understood to be a "problem" that is more in
> the programmer's brain than in reality.  Not having it in
> the BSDM (BDSM?) style of C++ or Java doesn't lead to
> subtle bugs, and the huge number of working Python programs
> which have *no* access specifiers (or whatever they're called)
> proves the point.

But IMO it could go further. One program can signal an other.
That is an old practice that still is around. So why not
allow one thread to "signal" an other.

-- 
Antoon Pardon
More information about the Python-list mailing list