Re: Exception as the primary error handling mechanism?

[Steven D'Aprano]

On Thu, 31 Dec 2009 20:47:49 -0800, Peng Yu wrote:

> I observe that python library primarily use exception for error handling
> rather than use error code.
> 
> In the article API Design Matters by Michi Henning
> 
> Communications of the ACM
> Vol. 52 No. 5, Pages 46-56
> 10.1145/1506409.1506424
> http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
> 
> It says "Another popular design flaw—namely, throwing exceptions for
> expected outcomes—also causes inefficiencies because catching and
> handling exceptions is almost always slower than testing a return
> value."

This is very, very wrong.

Firstly, notice that the author doesn't compare the same thing. He 
compares "catching AND HANDLING" the exception (emphasis added) with 
*only* testing a return value. Of course it is faster to test a value and 
do nothing, than it is to catch an exception and then handle the 
exception. That's an unfair comparison, and that alone shows that the 
author is biased against exceptions.

But it's also wrong. If you call a function one million times, and catch 
an exception ONCE (because exceptions are rare) that is likely to be 
much, much faster than testing a return code one million times.

Before you can talk about which strategy is faster, you need to 
understand your problem. When exceptions are rare (in CPython, about one 
in ten or rarer) then try...except is faster than testing each time. The 
exact cut-off depends on how expensive the test is, and how much work 
gets done before the exception is raised. Using exceptions is only slow 
if they are common.

But the most important reason for preferring exceptions is that the 
alternatives are error-prone! Testing error codes is the anti-pattern, 
not catching exceptions.

See, for example:

http://c2.com/cgi/wiki?UseExceptionsInsteadOfErrorValues
http://c2.com/cgi/wiki?ExceptionsAreOurFriends
http://c2.com/cgi/wiki?AvoidExceptionsWheneverPossible

Despite the title of that last page, it has many excellent arguments for 
why exceptions are better than the alternatives.

(Be warned: the c2 wiki is filled with Java and C++ programmers who 
mistake the work-arounds for quirks of their language as general design 
principles. For example, because exceptions in Java are evcen more 
expensive and slow than in Python, you will find lots of Java coders 
saying "don't use exceptions" instead of "don't use exceptions IN JAVA".)

There are many problems with using error codes:

* They complicate your code. Instead of returning the result you care 
about, you have to return a status code and the return result you care 
about. Even worse is to have a single global variable to hold the status 
of the last function call!

* Nobody can agree whether the status code means the function call 
failed, or the function call succeeded.

* If the function call failed, what do you return as the result code?

* You can't be sure that the caller will remember to check the status 
code. In fact, you can be sure that the caller WILL forget sometimes! 
(This is human nature.) This leads to the frequent problem that by the 
time a caller checks the status code, the original error has been lost 
and the program is working with garbage.

* Even if you remember to check the status code, it complicates the code, 
makes it less readable, confuses the intent of the code, and often leads 
to the Arrow Anti-pattern: http://c2.com/cgi/wiki?ArrowAntiPattern

That last argument is critical. Exceptions exist to make writing correct 
code easier to write, understand and maintain.

Python uses special result codes in at least two places:

str.find(s) returns -1 if s is not in the string
re.match() returns None is the regular expression fails

Both of these are error-prone. Consider a naive way of getting the 
fractional part of a float string:

>>> s = "234.567"
>>> print s[s.find('.')+1:]
567

But see:

>>> s = "234"
>>> print s[s.find('.')+1:]
234

You need something like:

p = s.find('.')
if p == -1:
print ''
else:
print s[p+1:]



Similarly, we cannot safely do this in Python:


>>> re.match(r'\d+', '123abcd').group()
'123'
>>> re.match(r'\d+', 'abcd').group()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'NoneType' object has no attribute 'group'

You need to do this:

mo = re.match(r'\d+', '123abcd')
if mo is not None:  # or just `if mo` will work
mo.group()


Exceptions are about making it easier to have correct code. They're also 
about making it easier to have readable code. Which is easier to read, 
easier to understand and easier to debug?

x = function(1, 2, 3)
if x != -1:
y = function(x, 1, 2)
if y != -1:
z = function(y, x, 1)
if z != -1:
print "result is", z
else:
print "an error occurred"
else:
print "an error occurred"
else:
print "an error occurred"


versus:


try:
x = function(1, 2, 3)
y = function(x, 1, 2)
print "result is", function(y, x, 1)
except V

Re: Not Incrementing

[Victor Subervi]

On Fri, Jan 1, 2010 at 2:47 AM, Victor Subervi wrote:

> On Thu, Dec 31, 2009 at 3:46 PM, MRAB  wrote:
>
>> Victor Subervi wrote:
>>
>>> On Thu, Dec 31, 2009 at 3:01 PM, MRAB >> pyt...@mrabarnett.plus.com>> wrote:
>>>
>>>Victor Subervi wrote:
>>>
>>>On Thu, Dec 31, 2009 at 1:01 PM, Dave Angel >> >>
>>>>> wrote:
>>>
>>>[snip]
>>>
>>>
>>>   Incidentally, good naming would help to make the code easier to
>>>   debug.  This finalTrees and trees variables don't look to me
>>> like
>>>   you intended them to be trees at all, but lists of
>>>tab-indented data.
>>>
>>>No kidding. Many people have commented on my poor choices of
>>>names. That's one of the things on my agenda to change (with
>>>some tools that I understand are out there) once I get this
>>>program finished and working for clients.
>>>
>>>Your clients will get it _with_ its faults? You'll fix it with some
>>>tools that you _understand_ are out there, ie you haven't looked
>>>for/found them yet? Yikes! :-)
>>>
>>>
>>> How many espressos do you drink a day? Do you mainline the stuff? Relax,
>>> dude. Rome wasn't made in a day. I'll get there. Chill out, dude.
>>>
>>>  Programming is about attention to detail. It's not like poetry, with its
>> "poetic licence". Has a mistake in poetry ever caused a rocket to fail
>> (Ariane 5, flight 501)? :-)
>
>
> Heavens no! And thank goodness! Yes, as I like to say, "The devil is in the
> details...and well employed in software development!" LOL!
> beno
>

PS

Poetry is the art of writing
what goes without saying.

beno
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Aahz]

In article ,
Benjamin Kaplan   wrote:
>
>In Python, throwing exceptions for expected outcomes is considered
>very bad form [...]

Who says that?  I certainly don't.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Martin v. Loewis]

Peng Yu wrote:
> I observe that python library primarily use exception for error
> handling rather than use error code.
[...]
> It says "Another popular design flaw—namely, throwing exceptions for
> expected outcomes—also causes inefficiencies because catching and
> handling exceptions is almost always slower than testing a return
> value."
> 
> My observation is contradicted to the above statement by Henning. If
> my observation is wrong, please just ignore my question below.

Your observation is not wrong, but, as Benjamin already explained,
you are misinterpreting Michi Henning's statement. He doesn't condemn
exception handling per se, but only for the handling of *expected*
outcomes. He would consider using exceptions fine for *exceptional*
output, and that is exactly the way they are used in the Python API.

Notice that in cases where the failure may be expected, Python
also offers variants that avoid the exception:
- if you look into a dictionary, expecting that a key may not
  be there, a regular access, d[k], may give a KeyError. However,
  alternatively, you can use d.get(k, default) which raises no
  exception, and you can test "k in d" in advance.
- if you open a file, not knowing whether it will be there,
  you get an IOError. However, you can use os.path.exists in
  advance to determine whether the file is present (and create
  it if it's not).

So, in these cases, it is a choice of the user to determine whether
the error case is exceptional or not.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Jonathan Gardner]

On Jan 1, 12:43 am, a...@pythoncraft.com (Aahz) wrote:
> In article ,
> Benjamin Kaplan   wrote:
> >In Python, throwing exceptions for expected outcomes is considered
> >very bad form [...]
>
> Who says that?  I certainly don't.

Agreed.

int("asdf") is supposed to return what, exactly? Any language that
tries to return an int is horribly broken.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: twenty years ago Guido created Python

[J Peyret]

On Dec 31 2009, 2:06 pm, Steve Howell  wrote:
> FYI:
>
> http://twitter.com/gvanrossum
>
> Python is a truly awesome programming language.  Not only is Guido a
> genius language designer, but he is also a great project leader.  What
> an accomplishment.  Congratulations to everybody who has contributed
> to Python in the last two decades!

Notwithstanding all of the above, which are all true, having met
Guido, I say he is a genuinely nice human being.  Go BSD derivatives.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: pywinauto to show the dialog , menu, etc

[Simon Brunning]

2009/12/31 Hari :
> Hi
> I am using pywinauto to automate an custom program to startup and load
> process , execute etc. But cannot determine menuselect. Is there a way or
> tool which can run against the exe to show the menu, dialog box, list box
> which are contained within it.

Winspector might be worth a try: http://www.windows-spy.com/

-- 
Cheers,
Simon B.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: twenty years ago Guido created Python

[Krishnakant]

On Fri, 2010-01-01 at 03:25 -0800, J Peyret wrote:
> On Dec 31 2009, 2:06 pm, Steve Howell  wrote:
> > FYI:
> >
> > http://twitter.com/gvanrossum
> >
> > Python is a truly awesome programming language.  Not only is Guido a
> > genius language designer, but he is also a great project leader.  What
> > an accomplishment.  Congratulations to everybody who has contributed
> > to Python in the last two decades!
> 
> Notwithstanding all of the above, which are all true, having met
> Guido, I say he is a genuinely nice human being.  Go BSD derivatives.

Indeed,
python is a great programming language.
May be it was not marketted as much as languages like java or not as
much as platforms like rails.
But who cares?  I must mention here that I am totally blind and the
talking software (screen reader ) I use on GNU/Linux called Orca is also
programmed using python.

And I make web applications and off late started to use pylons (  again
centered around python).
I see that python is for 2 kind of programmers.
one which are absolute beginners to programming itself who want to learn
the scientific art of programming and the second is the extreme experts
who need the power and performance nicely balanced.

Great work!

happy hfacking.
Krishnakant.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: adding python engine into c++ application

[bobicanprogram]

On Dec 29 2009, 6:25 am, griwes  wrote:
> Hello, I am going to write an application in C++, application which
> should be easy to extend by scripts. I chose python for script
> language in this application. I'd like to have own API for python. And
> here the question arises: how do I implement a python engine within an
> application written in C++?
>
> Sory for any mistakes, english isn't my native language ;)


If you want to keep your C++ and Python as separate but interacting
modules you might want to check out the SIMPL project's (http://
www.icanprogram.com/SIMPL) Python hooks.   There is some tutorial
level code here:

http://www.icanprogram.com/06py/main.html

bob
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: multivariable assignment

[Lie Ryan]

On 1/1/2010 3:13 AM, davidj411 wrote:

I am not sure why this behavior is this way.
at beginning of script, i want to create a bunch of empty lists and
use each one for its own purpose.
however, updating one list seems to update the others.


a = b = c = []
a.append('1')
a.append('1')
a.append('1')
c

['1', '1', '1']

a

['1', '1', '1']

b

['1', '1', '1']


Every time people get confused because of how python object model works, 
I always refer them to this article: 
http://effbot.org/zone/call-by-object.htm

--
http://mail.python.org/mailman/listinfo/python-list

Re: Dangerous behavior of list(generator)

[Wolfram Hinderer]

On 1 Jan., 02:47, Steven D'Aprano  wrote:
> On Thu, 31 Dec 2009 11:34:39 -0800, Tom Machinski wrote:


> > On Wed, Dec 30, 2009 at 4:01 PM, Steven D'Aprano
> >  wrote:
> >> On Wed, 30 Dec 2009 15:18:11 -0800, Tom Machinski wrote:
> >>> Bottom line, I'm going to have to remove this pattern from my code:
>
> >>>   foo = (foo for foo in foos if foo.bar).next()
>
> >> I don't see why. What's wrong with it? Unless you embed it in a call to
> >> list, or similar, it will explicitly raise StopIteration as expected.
>
> > Exactly; this seems innocuous, but if some caller of this code uses it
> > in a list() constructor, a very subtle and dangerous bug is introduced -
> > see OP. This is the entire point of this post.
>
> Then don't use it in a list() constructor.
>
> That's a glib answer, of course. A better answer is to point out that the
> problem is not with the above expression, but with letting StopIteration
> bubble up as an error exception instead of dealing with it immediately.
> That's not what it's for, and you can't trust it not to be captured by
> something. If StopIteration represents an error condition, you need to
> deal with it immediately and convert it to an exception which isn't
> likely to disappear.
>
> > In a large, non-trivial application, you simply cannot afford the
> > assumption that no caller will ever do that. Even if you have perfect
> > memory, some of your other developers or library users may not.
>
> You shouldn't put the responsibility of dealing with the StopIteration on
> the caller, because StopIteraction is a signal not an error condition,
> and you can't tell when that signal will disappear. The responsibility
> lies on the writer of the function containing the line (that is, the
> Original Poster of this thread).
>
> So you need something like this:
>
> def my_function():
>     try:
>         foo = (foo for foo in foos if foo.bar).next()
>     except StopIteration:
>         handle_empty_foos()
>     else:
>         handle_at_least_one_foo()
>
> handle_empty_foos may be as simple as raising a new exception and letting
> that bubble up to whatever layer of the application is expected to deal
> with it.
>

> > As for what's wrong with the "if not any" solution, Benjamin Kaplan's
> > post hits the nail on its head. This is a bioinformatics application, so
> > the iterable "foos" tends to be very large, so saving half the runtime
> > makes a big difference.
>
> Possibly you haven't seen my reply to Benjamin, so I'll paraphrase:
> that's incorrect, because any() is lazy and will return as soon as it
> hits a non-false item.

Tom's point is that
if not any(foo for foo in foos if foo.bar):
foo = (foo for foo in foos if foo.bar).next()
iterates twice over (the same first few elements of) foos, which
should take about twice as long as iterating once. The lazyness of
"any" does not seem to matter here.
Of course, you're right that the iteration might or might not be the
bottleneck. On the other hand, foos might not even be reiterable.

> If the foo items are arbitrary objects which have an equal chance of
> being considered true or false, then on average it will have to look at
> half the list,

By which definition of chance? :-)

Wolfram
-- 
http://mail.python.org/mailman/listinfo/python-list

Where is "urllib2" module in windows python3.1.1?

[Hidekazu IWAKI]

Hi;
I'd like to import "urllib2" in windows python 3.1.1, but I'm not able to
do it.
So, I researched the library directory; the result is following:



2009/06/07  19:1161,749 unittest.py
2010/01/01  22:18  urllib
2007/12/06  09:48 6,318 uu.py
2008/11/30  20:4021,534 uuid.py



Although it has "urllib", it doesn't have "urllib2". I guess to download
and install the module. But I can't find "urllib2" module for windows
with google.

I wonder if it would be possible for me to give the location?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Where is "urllib2" module in windows python3.1.1?

[Duncan Booth]

Hidekazu IWAKI  wrote:

> Hi;
> I'd like to import "urllib2" in windows python 3.1.1, but I'm not able to
> do it.

Python 3 doesn't have a urllib2 module; use the urllib package instead.

See http://www.python.org/dev/peps/pep-3108/#urllib-package
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Andreas Waldenburger]

On Fri, 01 Jan 2010 11:34:19 +0100 "Martin v. Loewis"
 wrote:

> Your observation is not wrong, but, as Benjamin already explained,
> you are misinterpreting Michi Henning's statement. He doesn't condemn
> exception handling per se, but only for the handling of *expected*
> outcomes. He would consider using exceptions fine for *exceptional*
> output, and that is exactly the way they are used in the Python API.

May I point out at this point that "exceptional" does not mean
"unexpected"? You catch exceptions, not unexpectations. An exception
is rare, but not surprising. Case in point: StopIteration.

To put it differently: When you write "catch DeadParrot", you certainly
expect to get a DeadParrot once in a while -- why else would you get it
in your head to try and catch it? An unexpected exception is the one
that crashes your program.

/W

-- 
INVALID? DE!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Where is "urllib2" module in windows python3.1.1?

[IWAKI, Hidekazu]

>Python 3 doesn't have a urllib2 module; use the urllib package instead.

Thank you for your answer and the link.
Oh, sorry. It was one of the changes from .2.x to 3.x. I didn't know.
There are really important and a lot of changes.

Thank you!

On Fri, Jan 1, 2010 at 10:57 PM, Duncan Booth
wrote:

> Hidekazu IWAKI  wrote:
>
> > Hi;
> > I'd like to import "urllib2" in windows python 3.1.1, but I'm not able to
> > do it.
>
> Python 3 doesn't have a urllib2 module; use the urllib package instead.
>
> See http://www.python.org/dev/peps/pep-3108/#urllib-package
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Steven D'Aprano]

On Fri, 01 Jan 2010 02:43:21 -0800, Jonathan Gardner wrote:

> On Jan 1, 12:43 am, a...@pythoncraft.com (Aahz) wrote:
>> In article ,
>> Benjamin Kaplan   wrote:
>> >In Python, throwing exceptions for expected outcomes is considered
>> >very bad form [...]
>>
>> Who says that?  I certainly don't.
> 
> Agreed.
> 
> int("asdf") is supposed to return what, exactly? Any language that tries
> to return an int is horribly broken.


[sarcasm]
No no, the right way to deal with that is have int("asdf") return some 
arbitrary bit pattern, and expect the user to check a global variable to 
see whether the function returned a valid result or not. That's much 
better than catching an exception!
[/sarcasm]


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Where is "urllib2" module in windows python3.1.1?

[Lie Ryan]

On 1/2/2010 12:46 AM, Hidekazu IWAKI wrote:

Hi;
I'd like to import "urllib2" in windows python 3.1.1, but I'm not able to
do it.
So, I researched the library directory; the result is following:

.
.
2009/06/07  19:1161,749 unittest.py
2010/01/01  22:18   urllib
2007/12/06  09:48 6,318 uu.py
2008/11/30  20:4021,534 uuid.py
.
.

Although it has "urllib", it doesn't have "urllib2". I guess to download
and install the module. But I can't find "urllib2" module for windows
with google.

I wonder if it would be possible for me to give the location?


urllib2 is merged into urllib in python3.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Dangerous behavior of list(generator)

[Steven D'Aprano]

On Fri, 01 Jan 2010 05:19:02 -0800, Wolfram Hinderer wrote:

> On 1 Jan., 02:47, Steven D'Aprano  cybersource.com.au> wrote:
>> On Thu, 31 Dec 2009 11:34:39 -0800, Tom Machinski wrote:
[...]
>> > As for what's wrong with the "if not any" solution, Benjamin Kaplan's
>> > post hits the nail on its head. This is a bioinformatics application,
>> > so the iterable "foos" tends to be very large, so saving half the
>> > runtime makes a big difference.
>>
>> Possibly you haven't seen my reply to Benjamin, so I'll paraphrase:
>> that's incorrect, because any() is lazy and will return as soon as it
>> hits a non-false item.
> 
> Tom's point is that
> if not any(foo for foo in foos if foo.bar):
> foo = (foo for foo in foos if foo.bar).next()
> iterates twice over (the same first few elements of) foos, which should
> take about twice as long as iterating once. The lazyness of "any" does
> not seem to matter here.

That's no different from any "Look Before You Leap" idiom. If you do this:

if key in dict:
x = dict[key]

you search the dict twice, once to see if the key is there, and the 
second time to fetch the value. Whether that is better or faster than the 
alternative:

try:
x = dict[key]
except KeyError:
pass

depends on how often you expect the lookup to fail.

In any case, I would claim that Tom's argument is a classic example of 
premature optimization: by his own admission: 

'the iterable "foos" tends to be very large'

which implies that whatever happens to the foos after this test, it will 
probably be very time consuming. If it takes (for the sake of the 
argument) 10 milliseconds to process the entire iterable, who cares 
whether it takes 0.01 or 0.02 ms to check that the iterable is valid?



> Of course, you're right that the iteration might or might not be the
> bottleneck. On the other hand, foos might not even be reiterable.

If that's the case, then the existing solution potentially throws away 
the first value of foos every time the caller tests to see if it is empty.

Dealing with non-reiterable iterators can be a nuisance. In such a case, 
it may be best to avoid Look Before You Leap altogether:

empty = True
for foo in foos:
if foo.bar:
empty = False
process(foo)
if empty:
handle_error_condition()




-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Steven D'Aprano]

On Fri, 01 Jan 2010 00:26:09 -0500, Benjamin Kaplan wrote:

> On Thu, Dec 31, 2009 at 11:47 PM, Peng Yu  wrote:
>> I observe that python library primarily use exception for error
>> handling rather than use error code.
>>
>> In the article API Design Matters by Michi Henning
>>
>> Communications of the ACM
>> Vol. 52 No. 5, Pages 46-56
>> 10.1145/1506409.1506424
>> http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
>>
>> It says "Another popular design flaw—namely, throwing exceptions for
>> expected outcomes—also causes inefficiencies because catching and
>> handling exceptions is almost always slower than testing a return
>> value."
>>
>> My observation is contradicted to the above statement by Henning. If my
>> observation is wrong, please just ignore my question below.
>>
>> Otherwise, could some python expert explain to me why exception is
>> widely used for error handling in python? Is it because the efficiency
>> is not the primary goal of python?
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>>
> Read the quote again "Another popular design flaw—namely, throwing
> exceptions *for expected outcomes*"
> In Python, throwing exceptions for expected outcomes is considered very
> bad form (well, except for StopIteration but that should almost never be
> handled directly by the programmer).


Exceptions are *exceptional*, not "errors" or "unexpected". They are 
exceptional because they aren't the "normal" case, but that doesn't mean 
they are surprising or unexpected. Are you surprised that your "for x in 
range(1000)" loop comes to an end? Of course you are not -- it is 
completely expected, even though less than 1% of the iterations are the 
last loop. The end of the sequence is EXCEPTIONAL but not UNEXPECTED.

If you program without expecting that keys can sometimes be missing from 
dictionaries (KeyError), or that you might sometimes have to deal with a 
list index that is out of range (IndexError), or that the denominator in 
a division might be zero (ZeroDivisionError), then you must be writing 
really buggy code. None of these things are unexpected, but they are all 
exceptional.

The urllib2 module defines a HTTPError class, which does double-duty as 
both an exception and a valid HTTP response. If you're doing any HTTP 
programming, you better expect to deal with HTTP 301, 302 etc. codes, or 
at least trust that the library you use will transparently handle them 
for you.


> To answer why people recommend using "Easier to Ask Forgiveness than
> Permission" as opposed to "Look Before You Leap" : Because of the way
> it's implemented, Python works quite differently from most languages. An
> attribute look-up is rather expensive because it's a hash table look-up
> at run time. Wrapping a small piece of code in a try block however,
> isn't (relatively) very expensive at all in Python.

It's not just relatively inexpensive, it's absolutely inexpensive: it 
costs about as much as a pass statement in CPython, which is pretty much 
as cheap as it gets. (If anyone can demonstrate a cheaper operation 
available from pure Python, I'd love to see it.)


> It's only catching the exception that's expensive, 

True.


> but if you're catching the exception, 
> something has gone wrong anyway and performance isn't your biggest
> issue.


The second try...except clause in the urllib2 module reads:

try:
kind = int(kind)
except ValueError:
pass

In this case, the error is simply ignored. Nothing has gone wrong.


Here's an example from my own code: I have an API where you pass a 
mapping (either a dict or a list of (key, value) tuples) to a function. 
So I do this:

try:
it = obj.iteritems()
except AttributeError:
it = obj
for key, value in it:
do_stuff()



There's nothing wrong with catching exceptions.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: change an exception's message and re-raise it

[Phlip]

On Dec 31 2009, 4:30 pm, Steven D'Aprano  wrote:

> ...     1/0
> ... except ZeroDivisionError, e:
> ...     e.args = e.args + ('fe', 'fi', 'fo', 'fum')
> ...     raise

When I added print e.args it showed the old args. Maybe I was trying
too hard - this is why I said e seemed locked or something.

This started working:

new_exception = self.format_fault(e.args[0])
e.args = (new_exception,) + (e.args[1:])
raise

May I ask if args always has more than one entry? I need to bypass the
silly "'tuple' object does not support item assignment" issue...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: change an exception's message and re-raise it

[Phlip]

On Dec 31 2009, 4:30 pm, Steven D'Aprano  wrote:

> For the record you can get the exception type from type(e):
>
> raise type(e)("whatever you want")
>
> but that creates a new exception, not re-raising the old one.

Except if a type constructs with some other number of arguments,
apparently...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Lie Ryan]

On 1/1/2010 3:47 PM, Peng Yu wrote:

I observe that python library primarily use exception for error
handling rather than use error code.

In the article API Design Matters by Michi Henning

Communications of the ACM
Vol. 52 No. 5, Pages 46-56
10.1145/1506409.1506424
http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext

It says "Another popular design flaw—namely, throwing exceptions for
expected outcomes—also causes inefficiencies because catching and
handling exceptions is almost always slower than testing a return
value."

My observation is contradicted to the above statement by Henning. If
my observation is wrong, please just ignore my question below.

Otherwise, could some python expert explain to me why exception is
widely used for error handling in python?


Simple, when an exception is thrown and I don't catch it, the exception 
terminates the program immediately and I got a traceback showing the 
point of failure. When I return error value and I don't check for it, I 
passed passed errors silently and gets a traceback forty-two lines later 
when trying to use the resources I failed to acquire forty-two lines prior.


> Is it because the efficiency
> is not the primary goal of python?

Efficiency is not primary goal of python, but since python encourages 
EAFP (Easier to Ask Forgiveness than Permission); the design decisions 
chosen makes setting up a try-block much cheaper than a language 
designed over LBYL (Look Before You Leap) and return codes.

--
http://mail.python.org/mailman/listinfo/python-list

How to Suppress Interactive Assignment to "_"

[JKPeck]

The gettext module uses the convention of defining a function named
"_" that maps text into its translation.
This conflicts with the automatic interactive interpreter assignment
of expressions to a variable with that same name.

While if you are careful, you can avoid that assignment while
debugging, and you can choose a different function for gettext, this
conflict is a nuisance.  I am looking for a way to suppress the
expression assignment to _ or to change the name of the variable
assigned to.  Is this possible?  Using Python 2.6.

TIA,
Jon Peck
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Benjamin Kaplan]

On Fri, Jan 1, 2010 at 9:49 AM, Steven D'Aprano
 wrote:
>
> Exceptions are *exceptional*, not "errors" or "unexpected". They are
> exceptional because they aren't the "normal" case, but that doesn't mean
> they are surprising or unexpected. Are you surprised that your "for x in
> range(1000)" loop comes to an end? Of course you are not -- it is
> completely expected, even though less than 1% of the iterations are the
> last loop. The end of the sequence is EXCEPTIONAL but not UNEXPECTED.
>

Sorry if my word choice was confusing- I was trying to point out that
in Python, you don't test errors for your typical conditions, but for
ones that you know still exist but don't plan on occurring often.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Mel]

Steven D'Aprano wrote:

> On Fri, 01 Jan 2010 02:43:21 -0800, Jonathan Gardner wrote:
> 
>> On Jan 1, 12:43 am, a...@pythoncraft.com (Aahz) wrote:
>>> In article ,
>>> Benjamin Kaplan   wrote:
>>> >In Python, throwing exceptions for expected outcomes is considered
>>> >very bad form [...]
>>>
>>> Who says that?  I certainly don't.
>> 
>> Agreed.
>> 
>> int("asdf") is supposed to return what, exactly? Any language that tries
>> to return an int is horribly broken.
> 
> 
> [sarcasm]
> No no, the right way to deal with that is have int("asdf") return some
> arbitrary bit pattern, and expect the user to check a global variable to
> see whether the function returned a valid result or not. That's much
> better than catching an exception!
> [/sarcasm]

Or the other way around, as in C (I suspect the original ACM article assumed 
C.)  Look at the legion of C library subroutines that return only 0 for good 
or -1 for bad, and do all their real work in side-effects (through pointers 
as function arguments.)  Python is a big improvement: use the function 
return values for the payload, and push the out-of-band "omyghod" response 
into an Exception.

Mel.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Steven D'Aprano]

On Fri, 01 Jan 2010 11:02:28 -0500, Benjamin Kaplan wrote:

> I was trying to point out that in
> Python, you don't test errors for your typical conditions, but for ones
> that you know still exist but don't plan on occurring often.

I'm sorry, but that makes no sense to me at all. I don't understand what 
you are trying to say.


You do understand that exceptions aren't just for errors? They are raised 
under specific circumstances. Whether that circumstance is an error or 
not is entirely up to the caller.


try:
n = mylist.index('fault')
except ValueError:
print "All is good, no fault detected"
else:
print "Your data contains a fault in position", n



People get hung up on the idea that exceptions == errors, but they 
aren't. They *may* be errors, and that is one common use, but that 
depends entirely on the caller.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

MySQL Error

[Victor Subervi]

Hi;
I'm trying to avoid the mortal sin of blank excepts. I intentionally threw
this error:

Traceback (most recent call last):
  File "/var/www/html/angrynates.com/cart/createAssociations2.py", line 137,
in ?
createAssociations2()
  File "/var/www/html/angrynates.com/cart/createAssociations2.py", line 108,
in createAssociations2
cursor.execute(sql)
  File "/usr/lib64/python2.4/site-packages/MySQLdb/cursors.py", line 163, in
execute
self.errorhandler(self, exc, value)
  File "/usr/lib64/python2.4/site-packages/MySQLdb/connections.py", line 35,
in defaulterrorhandler
raise errorclass, errorvalue
ProgrammingError: (1146, "Table 'test.productsAssociations' doesn't exist")

However, "ProgrammingError" is not an error. How do I discover the real
error, so I can write the appropriate except statement?
TIA,
beno

-- 
The Logos has come to bear
http://logos.13gems.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: twenty years ago Guido created Python

[MRAB]

J Peyret wrote:

On Dec 31 2009, 2:06 pm, Steve Howell  wrote:

FYI:

http://twitter.com/gvanrossum

Python is a truly awesome programming language.  Not only is Guido a
genius language designer, but he is also a great project leader.  What
an accomplishment.  Congratulations to everybody who has contributed
to Python in the last two decades!


Notwithstanding all of the above, which are all true, having met
Guido, I say he is a genuinely nice human being.


And anyone who says he isn't will be put into the comfy chair! :-)
--
http://mail.python.org/mailman/listinfo/python-list

Re: MySQL Error

[Carsten Haese]

Victor Subervi wrote:
> However, "ProgrammingError" is not an error. How do I discover the real
> error, so I can write the appropriate except statement?

You're not making any sense. How did you determine that ProgrammingError
is not an error or that it's not the "real error"? Show us the code you
ran, the output you expected, and the output it produced instead.

Blind guess: You're using "except ProgrammingError" when you should be
using "except MySQLdb.ProgrammingError". If this guess is incorrect, see
above.

--
Carsten Haese
http://informixdb.sourceforge.net

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MySQL Error

[MRAB]

Victor Subervi wrote:

Hi;
I'm trying to avoid the mortal sin of blank excepts. I intentionally 
threw this error:


Traceback (most recent call last):
  File "/var/www/html/angrynates.com/cart/createAssociations2.py 
", line 137, in ?

createAssociations2()
  File "/var/www/html/angrynates.com/cart/createAssociations2.py 
", line 108, in 
createAssociations2

cursor.execute(sql)
  File "/usr/lib64/python2.4/site-packages/MySQLdb/cursors.py", line 
163, in execute

self.errorhandler(self, exc, value)
  File "/usr/lib64/python2.4/site-packages/MySQLdb/connections.py", line 
35, in defaulterrorhandler

raise errorclass, errorvalue
ProgrammingError: (1146, "Table 'test.productsAssociations' doesn't exist")

However, "ProgrammingError" is not an error. How do I discover the real 
error, so I can write the appropriate except statement?



What makes you think it isn't?

As the traceback says, "Table 'test.productsAssociations' doesn't
exist", and that's the cause.
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to Suppress Interactive Assignment to "_"

[Peter Otten]

JKPeck wrote:

> The gettext module uses the convention of defining a function named
> "_" that maps text into its translation.
> This conflicts with the automatic interactive interpreter assignment
> of expressions to a variable with that same name.
> 
> While if you are careful, you can avoid that assignment while
> debugging, and you can choose a different function for gettext, this
> conflict is a nuisance.  I am looking for a way to suppress the
> expression assignment to _ or to change the name of the variable
> assigned to.  Is this possible?  Using Python 2.6.


$ cat displayhook.py
import sys
import __builtin__ as builtin

def displayhook(obj):
if obj is not None:
builtin._last_result = obj
print repr(obj)

sys.displayhook = displayhook
$ python -i displayhook.py
>>> 42
42
>>> _
Traceback (most recent call last):
  File "", line 1, in 
NameError: name '_' is not defined
>>> _last_result
42

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Martin v. Loewis]

> You do understand that exceptions aren't just for errors? They are raised 
> under specific circumstances. Whether that circumstance is an error or 
> not is entirely up to the caller.

I think that's a fairly narrow definition of the word error, and
probably also the source of confusion in this thread.

ISTM that there is a long tradition of giving different meaning to
the word "error" in computing. For example, the Unix man pages
list various conditions as "errors" purely by their outcome, and
completely ignoring on whether the caller would consider the result
erroneous - ISTM that a system call reports an "error" iff it is
"unsuccessful".

By that (common) usage of "error", it is a condition determined by
the callee, not the caller (i.e. callee could not successfully
complete the operation). In that sense, it is indeed equivalent
to Python's usage of exceptions, which are also determined by the
callee, and typically also in cases where successful completion is
not possible. Whether these cases are "exceptional" in the word
sense (i.e. deviating from the norm) would have to be decided by
the application, again (which would set the norm).

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MySQL Error

[Victor Subervi]

On Fri, Jan 1, 2010 at 12:10 PM, MRAB  wrote:

> Victor Subervi wrote:
>
>> Hi;
>> I'm trying to avoid the mortal sin of blank excepts. I intentionally threw
>> this error:
>>
>> Traceback (most recent call last):
>>  File "/var/www/html/angrynates.com/cart/createAssociations2.py <
>> http://angrynates.com/cart/createAssociations2.py>", line 137, in ?
>>createAssociations2()
>>  File "/var/www/html/angrynates.com/cart/createAssociations2.py <
>> http://angrynates.com/cart/createAssociations2.py>", line 108, in
>> createAssociations2
>>
>>cursor.execute(sql)
>>  File "/usr/lib64/python2.4/site-packages/MySQLdb/cursors.py", line 163,
>> in execute
>>self.errorhandler(self, exc, value)
>>  File "/usr/lib64/python2.4/site-packages/MySQLdb/connections.py", line
>> 35, in defaulterrorhandler
>>raise errorclass, errorvalue
>> ProgrammingError: (1146, "Table 'test.productsAssociations' doesn't
>> exist")
>>
>> However, "ProgrammingError" is not an error. How do I discover the real
>> error, so I can write the appropriate except statement?
>>
>>  What makes you think it isn't?
>

Because I've tried
except ProgrammingError:
  pass
before and *that* threw an error. So I didnt' try again.
beno
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: twenty years ago Guido created Python

[Steve Howell]

On Jan 1, 9:03 am, MRAB  wrote:
> J Peyret wrote:
> > On Dec 31 2009, 2:06 pm, Steve Howell  wrote:
> >> FYI:
>
> >>http://twitter.com/gvanrossum
>
> >> Python is a truly awesome programming language.  Not only is Guido a
> >> genius language designer, but he is also a great project leader.  What
> >> an accomplishment.  Congratulations to everybody who has contributed
> >> to Python in the last two decades!
>
> > Notwithstanding all of the above, which are all true, having met
> > Guido, I say he is a genuinely nice human being.
>
> And anyone who says he isn't will be put into the comfy chair! :-)

And poked with the soft cushions!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to Suppress Interactive Assignment to "_"

[JKPeck]

On Jan 1, 10:06 am, Peter Otten <__pete...@web.de> wrote:
> JKPeck wrote:
> > The gettext module uses the convention of defining a function named
> > "_" that maps text into its translation.
> > This conflicts with the automatic interactive interpreter assignment
> > of expressions to a variable with that same name.
>
> > While if you are careful, you can avoid that assignment while
> > debugging, and you can choose a different function for gettext, this
> > conflict is a nuisance.  I am looking for a way to suppress the
> > expression assignment to _ or to change the name of the variable
> > assigned to.  Is this possible?  Using Python 2.6.
>
> $ cat displayhook.py
> import sys
> import __builtin__ as builtin
>
> def displayhook(obj):
>     if obj is not None:
>         builtin._last_result = obj
>         print repr(obj)
>
> sys.displayhook = displayhook
> $ python -i displayhook.py>>> 42
> 42
> >>> _
>
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name '_' is not defined>>> _last_result
>
> 42

Thanks.  It's just what I needed.
-Jon Peck
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MySQL Error

[Benjamin Kaplan]

On Fri, Jan 1, 2010 at 1:32 PM, Victor Subervi  wrote:
> On Fri, Jan 1, 2010 at 12:10 PM, MRAB  wrote:
>>
>> Victor Subervi wrote:
>>>
>>> Hi;
>>> I'm trying to avoid the mortal sin of blank excepts. I intentionally
>>> threw this error:
>>>
>>> Traceback (most recent call last):
>>>  File "/var/www/html/angrynates.com/cart/createAssociations2.py
>>> ", line 137, in ?
>>>    createAssociations2()
>>>  File "/var/www/html/angrynates.com/cart/createAssociations2.py
>>> ", line 108, in
>>> createAssociations2
>>>    cursor.execute(sql)
>>>  File "/usr/lib64/python2.4/site-packages/MySQLdb/cursors.py", line 163,
>>> in execute
>>>    self.errorhandler(self, exc, value)
>>>  File "/usr/lib64/python2.4/site-packages/MySQLdb/connections.py", line
>>> 35, in defaulterrorhandler
>>>    raise errorclass, errorvalue
>>> ProgrammingError: (1146, "Table 'test.productsAssociations' doesn't
>>> exist")
>>>
>>> However, "ProgrammingError" is not an error. How do I discover the real
>>> error, so I can write the appropriate except statement?
>>>
>> What makes you think it isn't?
>
> Because I've tried
> except ProgrammingError:
>   pass
> before and *that* threw an error. So I didnt' try again.
> beno

Just because it's not in the current namespace doesn't mean it's not
an error. From PEP 249 (the db api v2) :

  ProgrammingError

Exception raised for programming errors, e.g. table not
found or already exists, syntax error in the SQL
statement, wrong number of parameters specified, etc.  It
must be a subclass of DatabaseError.





>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: MySQL Error

[MRAB]

Benjamin Kaplan wrote:

On Fri, Jan 1, 2010 at 1:32 PM, Victor Subervi  wrote:

On Fri, Jan 1, 2010 at 12:10 PM, MRAB  wrote:

Victor Subervi wrote:

Hi;
I'm trying to avoid the mortal sin of blank excepts. I intentionally
threw this error:

Traceback (most recent call last):
 File "/var/www/html/angrynates.com/cart/createAssociations2.py
", line 137, in ?
   createAssociations2()
 File "/var/www/html/angrynates.com/cart/createAssociations2.py
", line 108, in
createAssociations2
   cursor.execute(sql)
 File "/usr/lib64/python2.4/site-packages/MySQLdb/cursors.py", line 163,
in execute
   self.errorhandler(self, exc, value)
 File "/usr/lib64/python2.4/site-packages/MySQLdb/connections.py", line
35, in defaulterrorhandler
   raise errorclass, errorvalue
ProgrammingError: (1146, "Table 'test.productsAssociations' doesn't
exist")

However, "ProgrammingError" is not an error. How do I discover the real
error, so I can write the appropriate except statement?


What makes you think it isn't?

Because I've tried
except ProgrammingError:
  pass
before and *that* threw an error. So I didnt' try again.
beno


Just because it's not in the current namespace doesn't mean it's not
an error. From PEP 249 (the db api v2) :

  ProgrammingError

Exception raised for programming errors, e.g. table not
found or already exists, syntax error in the SQL
statement, wrong number of parameters specified, etc.  It
must be a subclass of DatabaseError.


You shouldn't just that it threw an error and give up, you should look
at what the error was, in this case a NameError, which means that it
doesn't know that name. Why? Because it's defined in the MySQL module
that you imported, but you didn't import the name ProgrammingError.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?

[python]

Waldemar,

Thank your for sharing your technique - works great with 32-bit Python
2.6.4.

Has anyone tried this with a 64-bit version of Python?

Malcolm
-- 
http://mail.python.org/mailman/listinfo/python-list

Safe file I/O to shared file (or SQLite) from multi-threaded web server

[python]

I'm looking for the best practice way for a multi-threaded python web
server application to read/write to a shared file or a SQLite database.

What do I need to do (if anything) to make sure my writes to a regular
file on disk or to a SQLite database are atomic in nature when multiple
clients post data to my application simultaneously?

Do I need to use a Queue type data structure and then run a background
thread that monitors my Queue for data which it (and it alone) removes
and copies to the destination file or SQLite datatbase?

Note: In my specific case, the web server will be based on CherryPy 3.1
but I think this type of question is relevant across other Python based
web server frameworks as well.

Thank you,
Malcolm
-- 
http://mail.python.org/mailman/listinfo/python-list

Significant whitespace

[Dan Stromberg]

I put together a page about significant whitespace (and the lack thereof).

You're invited to check it out:

http://stromberg.dnsalias.org/~dstromberg/significant-whitespace.html


--
http://mail.python.org/mailman/listinfo/python-list

Re: Significant whitespace

[Chris Rebert]

On Fri, Jan 1, 2010 at 2:02 PM, Dan Stromberg  wrote:
> I put together a page about significant whitespace (and the lack thereof).
>
> You're invited to check it out:
>
> http://stromberg.dnsalias.org/~dstromberg/significant-whitespace.html

For those of us who weren't around during the heyday of FORTRAN, can
anyone describe this apparently much-reviled significant whitespace
feature that continues to make some programmers unjustly fearful about
Python's use of indentation?

Thanks in advance.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Safe file I/O to shared file (or SQLite) from multi-threaded web server

[Diez B. Roggisch]

pyt...@bdurham.com schrieb:

I'm looking for the best practice way for a multi-threaded python web
server application to read/write to a shared file or a SQLite database.

What do I need to do (if anything) to make sure my writes to a regular
file on disk or to a SQLite database are atomic in nature when multiple
clients post data to my application simultaneously?

Do I need to use a Queue type data structure and then run a background
thread that monitors my Queue for data which it (and it alone) removes
and copies to the destination file or SQLite datatbase?

Note: In my specific case, the web server will be based on CherryPy 3.1
but I think this type of question is relevant across other Python based
web server frameworks as well.


AFAIK, sqlite ensures process-serialization via locking, and threads 
synchronize themselves as well.


So you shouldn't need to worry at all.

Diez
--
http://mail.python.org/mailman/listinfo/python-list

Re: twenty years ago Guido created Python

[dennis]

On Jan 1, 6:04 am, Krishnakant  wrote:
> On Fri, 2010-01-01 at 03:25 -0800, J Peyret wrote:
> > On Dec 31 2009, 2:06 pm, Steve Howell  wrote:
> > > FYI:
>
> > >http://twitter.com/gvanrossum
>
> > > Python is a truly awesome programming language.  Not only is Guido a
> > > genius language designer, but he is also a great project leader.  What
> > > an accomplishment.  Congratulations to everybody who has contributed
> > > to Python in the last two decades!
>
> > Notwithstanding all of the above, which are all true, having met
> > Guido, I say he is a genuinely nice human being.  Go BSD derivatives.
>
> Indeed,
> python is a great programming language.
> May be it was not marketted as much as languages like java or not as
> much as platforms like rails.
> But who cares?  I must mention here that I am totally blind and the
> talking software (screen reader ) I use on GNU/Linux called Orca is also
> programmed using python.
>
> And I make web applications and off late started to use pylons (  again
> centered around python).
> I see that python is for 2 kind of programmers.
> one which are absolute beginners to programming itself who want to learn
> the scientific art of programming and the second is the extreme experts
> who need the power and performance nicely balanced.
>
> Great work!
>
> happy hfacking.
> Krishnakant.

That's incredible.
-- 
http://mail.python.org/mailman/listinfo/python-list

Trying to run a sudo command from script

[Kent Tenney]

Howdy,

A script running as a regular user sometimes wants
to run sudo commands.

It gets the password with getpass.
pw = getpass.getpass()

I've fiddled a bunch with stuff like
proc = subprocess.Popen('sudo touch /etc/foo'.split(), stdin=subprocess.PIPE)
proc.communicate(input=pw)

getting assorted errors with all variations I try.

Googling says use pexpect, but I'd prefer a stdlib solution.

Any help appreciated.

Thanks,
Kent
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Trying to run a sudo command from script

[Diez B. Roggisch]

Kent Tenney schrieb:

Howdy,

A script running as a regular user sometimes wants
to run sudo commands.

It gets the password with getpass.
pw = getpass.getpass()

I've fiddled a bunch with stuff like
proc = subprocess.Popen('sudo touch /etc/foo'.split(), stdin=subprocess.PIPE)
proc.communicate(input=pw)

getting assorted errors with all variations I try.

Googling says use pexpect, but I'd prefer a stdlib solution.


pexpect is pure python, and it's needed. There is no easy way around the 
issue, so if you insist on not using pexpect, you re-invent the wheel 
and write the exact same code - just more error-prone, because of 
wheel-reinvention


Diez
--
http://mail.python.org/mailman/listinfo/python-list

Re: Significant whitespace

[Roy Smith]

In article ,
 Chris Rebert  wrote:

> On Fri, Jan 1, 2010 at 2:02 PM, Dan Stromberg  wrote:
> > I put together a page about significant whitespace (and the lack thereof).
> >
> > You're invited to check it out:
> >
> > http://stromberg.dnsalias.org/~dstromberg/significant-whitespace.html
> 
> For those of us who weren't around during the heyday of FORTRAN, can
> anyone describe this apparently much-reviled significant whitespace
> feature that continues to make some programmers unjustly fearful about
> Python's use of indentation?

 I know it's bad form to cite yourself, but I think I said it pretty well 
(oh my) 12 years ago:

http://www.python.org/doc/humor/#bad-habits

To address your question more directly, here's a couple of ways Fortran 
treated whitespace which would surprise the current crop of 
Java/PHP/Python/Ruby programmers:

1) Line numbers (i.e. the things you could GOTO to) were in column 2-7 
(column 1 was reserved for a comment indicator).  This is not quite 
significant whitespace, it's more like significant indentation.

2) Whitespace was not required in many places.  For example, the following 
two statements (this will only make sense in a fixed-width font) are 
identical:

   DO 10 I = 1, 10
   DO10I=1,10

People make fun of Fortran these days, but it was a staggeringly important 
advance in software development compared to what came before (i.e. 
assembler).  The move from assembler to Fortran was a far more significant 
advance than the move from, say, Perl to Python.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?

[Jonathan Hartley]

> the method involves editing python26.dll in order to remove
> dependency references and then dropping msvcr90.dll in the same
> directory as the py2exe produced executable.

Clever idea Waldemar, thanks for that, but for the moment, using the
dll as a win32 assembly (ie. with a manifest file, as described by
others earlier in this thread) seems to work just as well.


>> > You'll need to include Microsoft.VC90.CRT.manifest and msvcr90.dll.

So, for the record, I have included these two files in a directory
called 'Microsoft.VC90.CRT', which is in the same dir as my
executable, and that makes everything work, even on my 'bare bones'
windows XP virtual machine.

The end result is a small game some friends and I put together for the
PyWeek competition a few months ago. If anyone wants to see exactly
how the resulting dll and manifest look, you can download the Windows
binary under the 'featured downloads' from here:
http://code.google.com/p/brokenspell/

I appreciate David Bolen's comment that an installer isn't that hard
to put together: Acknowledged, but for the moment I still seem to be
getting away without needing one.

Best regards,

  Jonathan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Significant whitespace

[Steven D'Aprano]

On Fri, 01 Jan 2010 14:19:28 -0800, Chris Rebert wrote:

> For those of us who weren't around during the heyday of FORTRAN, can
> anyone describe this apparently much-reviled significant whitespace
> feature that continues to make some programmers unjustly fearful about
> Python's use of indentation?


I'm not a Fortran expert, but I understand that whitespace was optional 
within lines unless needed to make something unambiguous.

In Python terms, imagine if we could write

foriinrange(10):

instead of the usual 

for i in range(10):

Since the colon makes it unambiguous that it is some sort of block 
construct, and it starts with "for", it must be a for loop. Pretty 
horrible, yes?


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Peng Yu]

On Thu, Dec 31, 2009 at 11:24 PM, Chris Rebert  wrote:
> On Thu, Dec 31, 2009 at 8:47 PM, Peng Yu  wrote:
>> I observe that python library primarily use exception for error
>> handling rather than use error code.
>>
>> In the article API Design Matters by Michi Henning
>>
>> Communications of the ACM
>> Vol. 52 No. 5, Pages 46-56
>> 10.1145/1506409.1506424
>> http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
>>
>> It says "Another popular design flaw—namely, throwing exceptions for
>> expected outcomes—also causes inefficiencies because catching and
>> handling exceptions is almost always slower than testing a return
>> value."
>>
>> My observation is contradicted to the above statement by Henning. If
>> my observation is wrong, please just ignore my question below.
>>
>> Otherwise, could some python expert explain to me why exception is
>> widely used for error handling in python? Is it because the efficiency
>> is not the primary goal of python?
>
> Correct; programmer efficiency is a more important goal for Python instead.
> Python is ~60-100x slower than C;[1] if someone is worried by the
> inefficiency caused by exceptions, then they're using completely the
> wrong language.

Could somebody let me know how the python calls and exceptions are
dispatched? Is there a reference for it?
-- 
http://mail.python.org/mailman/listinfo/python-list

Potential Conflicts by Installing Two Versions of Python (Windows)?

[W. eWatson]

I suspect that if one installs v2.4 and 2.5, or any two versions, that 
one will dominate, or there will be a conflict.  I suppose it would not 
be possible to choose which one should be used. Comments?

--
http://mail.python.org/mailman/listinfo/python-list

Re: Potential Conflicts by Installing Two Versions of Python (Windows)?

[alex23]

On Jan 2, 11:37 am, "W. eWatson"  wrote:
> I suspect that if one installs v2.4 and 2.5, or any two versions, that
> one will dominate, or there will be a conflict.  I suppose it would not
> be possible to choose which one should be used. Comments?

I suspect that you're not the first person to ask this question. I
suppose it would not be possible to search the group and find previous
advice given on this subject.

http://u.nu/4ape4

Is phrasing it as an implicit shortcoming of Python supposed to spur
others to comment? Perhaps that's the problem you're having searching:
try keywords that represent what you're looking for, not what you're
naively expecting.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Potential Conflicts by Installing Two Versions of Python (Windows)?

[Benjamin Kaplan]

The convention (more used among Unix variants but I guess the same
thing applies to Windows if you're setting the system path) is that
running "python" from the command line will give you the most recently
installed one. If you want to specify a version, it would be
"python24" or "python25". Each version of Python is installed in it's
own directory and maintains its own path so there aren't any problems
with stdlib conflicts.

As far as Windows file associations go, I suppose the most recent
install would dominate though you could always reset the associations
yourself.

On Fri, Jan 1, 2010 at 8:37 PM, W. eWatson  wrote:
> I suspect that if one installs v2.4 and 2.5, or any two versions, that one
> will dominate, or there will be a conflict.  I suppose it would not be
> possible to choose which one should be used. Comments?
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Potential Conflicts by Installing Two Versions of Python (Windows)?

[Benjamin Kaplan]

On Fri, Jan 1, 2010 at 8:37 PM, W. eWatson  wrote:
> I suspect that if one installs v2.4 and 2.5, or any two versions, that one
> will dominate, or there will be a conflict.  I suppose it would not be
> possible to choose which one should be used. Comments?
> --
> http://mail.python.org/mailman/listinfo/python-list
>

The convention (more used among Unix variants but I guess the same
thing applies to Windows if you're setting the system path) is that
running "python" from the command line will give you the most recently
installed one. If you want to specify a version, it would be
"python24" or "python25". Each version of Python is installed in it's
own directory and maintains its own path so there aren't any problems
with stdlib conflicts.

As far as Windows file associations go, I suppose the most recent
install would dominate though you could always reset the associations
yourself.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Significant whitespace

[MRAB]

Dan Stromberg wrote:


I put together a page about significant whitespace (and the lack thereof).

You're invited to check it out:

http://stromberg.dnsalias.org/~dstromberg/significant-whitespace.html


You might also want to mention that programmers tend to indent anyway
for clarity.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Significant whitespace

[Roy Smith]

In article 
<3db95947-1e35-4bd1-bd4c-37df646f9...@v25g2000yqk.googlegroups.com>,
 John Machin  wrote:

> On Jan 2, 10:29 am, Roy Smith  wrote:
> 
> >
> > To address your question more directly, here's a couple of ways Fortran
> > treated whitespace which would surprise the current crop of
> > Java/PHP/Python/Ruby programmers:
> >
> > 1) Line numbers (i.e. the things you could GOTO to) were in column 2-7
> > (column 1 was reserved for a comment indicator).  This is not quite
> > significant whitespace, it's more like significant indentation.
> 
> That would also surprise former FORTRAN programmers (who rarely
> referred to the language as "Fortran"). A comment was signified by a C
> in col 1. Otherwise cols 1-5 were used for statement labels (the
> things you could GOTO), col 6 for a statement continuation indicator,
> cols 7-72 for statement text, and cols 73-80 for card sequence numbers.

My apologies, you are correct.  The long disused neural pathways have 
started to degrade.  Trust me, I really did write FORTRAN.  On punch cards 
even.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Safe file I/O to shared file (or SQLite) from multi-threaded web server

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Diez B. Roggisch wrote:
> AFAIK, sqlite ensures process-serialization via locking, and threads
> synchronize themselves as well.

SQLite versions prior to 3.5 did not support using the same connection or
cursors in different threads.  (You needed to allocate, use, and close all
in the same thread.)  Since then SQLite objects can be used in any thread
you want at any time.  The SQLite error handling API is not threadsafe and
requires a lock to be held otherwise you can get incorrect errors or worst
case program crashes.  The sqlite3/pysqlite code does not hold that lock
(API introduced in SQLite 3.6.5) so you are only safe if you continue to
only use objects in the same thread.  If you use APSW then you can use any
SQLite object at any time in any thread (it holds the lock amongst other
things).

> So you shouldn't need to worry at all.

The main gotcha is that SQLite uses file locking and the default behaviour
when unable to get a lock is to immediately return an error.  SQLite does
have an API to specify how long it should wait to acquire the lock (it keeps
retrying until the time expires).

sqlite3/pysqlite only lets you specify this maximum time when opening the
connection and defaults to 5 seconds.  On a busy server this may be too
short so you'll end up getting busy errors.  (Remember that writes require
at least two disk syncs and that the default behaviour for Linux is to flush
all outstanding writes not just for the file requested.)

If you use APSW then you get default SQLite behaviour and two APIs - one
lets you set/change the timeout period and the other lets you install your
own busy handler which can do whatever it wants in order to prod things along.

(Disclosure: I am the author of APSW.)

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks+17QACgkQmOOfHg372QSiCwCgpr6fSOr6UcUUZqTDoFA4RBcK
zb8An21zZCr30AQ7VGP/Q/CsQ3z+2EVs
=55MC
-END PGP SIGNATURE-

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Significant whitespace

[Donn]

On Saturday 02 January 2010 00:02:36 Dan Stromberg wrote:
> I put together a page about significant whitespace (and the lack thereof).
The only thing about Python's style that worries me is that it can't be 
compressed like javascript can*, and perhaps that will prevent it becoming a 
browser-side language one day. How I'd love to code PyQuery instead of JQuery!

* Or am I wrong?
\d
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Significant whitespace

[Chris Rebert]

On Fri, Jan 1, 2010 at 9:56 PM, Donn  wrote:
> On Saturday 02 January 2010 00:02:36 Dan Stromberg wrote:
>> I put together a page about significant whitespace (and the lack thereof).
> The only thing about Python's style that worries me is that it can't be
> compressed like javascript can*, and perhaps that will prevent it becoming a
> browser-side language one day. How I'd love to code PyQuery instead of JQuery!
>
> * Or am I wrong?

Not to my knowledge, but CPython's bytecode format could be used to
similar effect.

However, the larger and much more daunting obstacle to client-side
Python would be that it's not sandboxed or secured like JavaScript is,
although there are some people working on it.

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Raw string substitution problem

[Aahz]

In article <7p2juvfu8...@mid.individual.net>,
Gregory Ewing   wrote:
>MRAB wrote:
>>
>> In simple cases you might be replacing with the same string every time,
>> but other cases you might want the replacement to contain substrings
>> captured by the regex.
>
>But you can give it a function that has access to the match object and
>can produce whatever replacement string it wants.

Assuming I remember correctly, the function capability came after the
replacement capability.  I think that breaking replacement would be a
Bad Idea.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Exception as the primary error handling mechanism?

[Aahz]

In article <4b3dcfab.3030...@v.loewis.de>,
Martin v. Loewis  wrote:
>
>Notice that in cases where the failure may be expected, Python
>also offers variants that avoid the exception:
>- if you look into a dictionary, expecting that a key may not
>  be there, a regular access, d[k], may give a KeyError. However,
>  alternatively, you can use d.get(k, default) which raises no
>  exception, and you can test "k in d" in advance.
>- if you open a file, not knowing whether it will be there,
>  you get an IOError. However, you can use os.path.exists in
>  advance to determine whether the file is present (and create
>  it if it's not).

But you *still* need to catch IOError: someone might delete the file
after the test.  Figuring out how to deal with race conditions is one of
the main reasons Alex Martelli advocates EAFP over LBYL.

Of course, in the real world, you often end up wanting to do it both
ways.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: multivariable assignment

[Rainer Grimm]

On Dec 31 2009, 5:13 pm, davidj411  wrote:
> I am not sure why this behavior is this way.
> at beginning of script, i want to create a bunch of empty lists and
> use each one for its own purpose.
> however, updating one list seems to update the others.
>
> >>> a = b = c = []
> >>> a.append('1')
> >>> a.append('1')
> >>> a.append('1')
> >>> c
> ['1', '1', '1']
> >>> a
> ['1', '1', '1']
> >>> b
>
> ['1', '1', '1']
a, b and c are the same objects.
You can check the object identity by
>>> a = b = c = []
>>> print id(a),id(b),id(c)
3083044140 3083044140 3083044140
>>> a is b is c
True

Greetings
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Potential Conflicts by Installing Two Versions of Python (Windows)?

[Terry Reedy]

On 1/1/2010 8:57 PM, Benjamin Kaplan wrote:


As far as Windows file associations go, I suppose the most recent
install would dominate though you could always reset the associations
yourself.


The Windows installer asks whether one wants the about-to-be-installed 
version to capture the associations or not.


--
http://mail.python.org/mailman/listinfo/python-list