Re: Exception as the primary error handling mechanism?
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 stdin, line 1, in module
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 ValueError:
print an error occurred
In
Re: Not Incrementing
On Fri, Jan 1, 2010 at 2:47 AM, Victor Subervi victorsube...@gmail.comwrote: On Thu, Dec 31, 2009 at 3:46 PM, MRAB pyt...@mrabarnett.plus.com wrote: Victor Subervi wrote: On Thu, Dec 31, 2009 at 3:01 PM, MRAB pyt...@mrabarnett.plus.commailto: pyt...@mrabarnett.plus.com wrote: Victor Subervi wrote: On Thu, Dec 31, 2009 at 1:01 PM, Dave Angel da...@ieee.org mailto:da...@ieee.org mailto:da...@ieee.org mailto:da...@ieee.org 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?
In article mailman.300.1262323578.28905.python-l...@python.org, Benjamin Kaplan benjamin.kap...@case.edu 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?
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?
On Jan 1, 12:43 am, a...@pythoncraft.com (Aahz) wrote: In article mailman.300.1262323578.28905.python-l...@python.org, Benjamin Kaplan benjamin.kap...@case.edu 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
On Dec 31 2009, 2:06 pm, Steve Howell showel...@yahoo.com 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
2009/12/31 Hari h...@pillai.co.uk: 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
On Fri, 2010-01-01 at 03:25 -0800, J Peyret wrote: On Dec 31 2009, 2:06 pm, Steve Howell showel...@yahoo.com 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
On Dec 29 2009, 6:25 am, griwes griwes.m...@gmail.com 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
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)
On 1 Jan., 02:47, Steven D'Aprano st...@remove-this- cybersource.com.au 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 st...@remove-this-cybersource.com.au 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?
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:18DIR 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?
Hidekazu IWAKI iw...@iwakihidekazu.net 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?
On Fri, 01 Jan 2010 11:34:19 +0100 Martin v. Loewis mar...@v.loewis.de 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?
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 duncan.bo...@invalid.invalidwrote: Hidekazu IWAKI iw...@iwakihidekazu.net 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?
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 mailman.300.1262323578.28905.python-l...@python.org, Benjamin Kaplan benjamin.kap...@case.edu 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?
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:18DIR 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)
On Fri, 01 Jan 2010 05:19:02 -0800, Wolfram Hinderer wrote: On 1 Jan., 02:47, Steven D'Aprano st...@remove-this- 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?
On Fri, 01 Jan 2010 00:26:09 -0500, Benjamin Kaplan wrote: On Thu, Dec 31, 2009 at 11:47 PM, Peng Yu pengyu...@gmail.com 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
On Dec 31 2009, 4:30 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au 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
On Dec 31 2009, 4:30 pm, Steven D'Aprano st...@remove-this- cybersource.com.au 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?
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 _
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?
On Fri, Jan 1, 2010 at 9:49 AM, Steven D'Aprano st...@remove-this-cybersource.com.au 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?
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 mailman.300.1262323578.28905.python-l...@python.org, Benjamin Kaplan benjamin.kap...@case.edu 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?
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
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
J Peyret wrote: On Dec 31 2009, 2:06 pm, Steve Howell showel...@yahoo.com 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
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
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? 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 _
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 stdin, line 1, in module NameError: name '_' is not defined _last_result 42 -- http://mail.python.org/mailman/listinfo/python-list
Re: Exception as the primary error handling mechanism?
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
On Fri, Jan 1, 2010 at 12:10 PM, MRAB pyt...@mrabarnett.plus.com 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
On Jan 1, 9:03 am, MRAB pyt...@mrabarnett.plus.com wrote: J Peyret wrote: On Dec 31 2009, 2:06 pm, Steve Howell showel...@yahoo.com 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 _
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 stdin, line 1, in module 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
On Fri, Jan 1, 2010 at 1:32 PM, Victor Subervi victorsube...@gmail.com wrote: On Fri, Jan 1, 2010 at 12:10 PM, MRAB pyt...@mrabarnett.plus.com 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 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
Benjamin Kaplan wrote: On Fri, Jan 1, 2010 at 1:32 PM, Victor Subervi victorsube...@gmail.com wrote: On Fri, Jan 1, 2010 at 12:10 PM, MRAB pyt...@mrabarnett.plus.com 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 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?
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
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
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
On Fri, Jan 1, 2010 at 2:02 PM, Dan Stromberg drsali...@gmail.com 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
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
On Jan 1, 6:04 am, Krishnakant hackin...@gmail.com wrote: On Fri, 2010-01-01 at 03:25 -0800, J Peyret wrote: On Dec 31 2009, 2:06 pm, Steve Howell showel...@yahoo.com 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
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
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
In article mailman.319.1262384371.28905.python-l...@python.org, Chris Rebert c...@rebertia.com wrote: On Fri, Jan 1, 2010 at 2:02 PM, Dan Stromberg drsali...@gmail.com 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?
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
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?
On Thu, Dec 31, 2009 at 11:24 PM, Chris Rebert c...@rebertia.com wrote: On Thu, Dec 31, 2009 at 8:47 PM, Peng Yu pengyu...@gmail.com 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)?
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)?
On Jan 2, 11:37 am, W. eWatson wolftra...@invalid.com 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)?
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 wolftra...@invalid.com 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)?
On Fri, Jan 1, 2010 at 8:37 PM, W. eWatson wolftra...@invalid.com 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
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
In article 3db95947-1e35-4bd1-bd4c-37df646f9...@v25g2000yqk.googlegroups.com, John Machin sjmac...@lexicon.net wrote: On Jan 2, 10:29 am, Roy Smith r...@panix.com 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
-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
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
On Fri, Jan 1, 2010 at 9:56 PM, Donn donn.in...@gmail.com 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
In article 7p2juvfu8...@mid.individual.net, Gregory Ewing greg.ew...@canterbury.ac.nz 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?
In article 4b3dcfab.3030...@v.loewis.de, Martin v. Loewis mar...@v.loewis.de 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
On Dec 31 2009, 5:13 pm, davidj411 davidj...@gmail.com 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)?
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
[issue7617] distutils.unixccompiler.UnixCCompiler.runtime_library_dir_option() should recognize ${configuration_name}-gcc
New submission from Arfrever Frehtes Taifersar Arahesis
arfrever@gmail.com:
distutils.unixccompiler.UnixCCompiler.runtime_library_dir_option()
currently only recognizes gcc or gcc-${version (e.g. gcc-4.4.2),
but it doesn't recognize ${configuration_name}-gcc (e.g. x86_64-pc-
x86_64-pc-linux-gnu-gcc-4.4.2). Python is configured with such fully
qualified configuration names in some distributions (e.g. Gentoo).
Configuration names are described in:
http://sourceware.org/autobook/autobook/autobook_17.html
http://www.gnu.org/software/autoconf/manual/html_node/Specifying-
--
assignee: tarek
components: Distutils
files: python-distutils-recognize_configuration_names.patch
keywords: patch
messages: 97114
nosy: Arfrever, tarek
severity: normal
status: open
title: distutils.unixccompiler.UnixCCompiler.runtime_library_dir_option()
should recognize ${configuration_name}-gcc
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file:
http://bugs.python.org/file15717/python-distutils-recognize_configuration_names.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7617
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7617] distutils.unixccompiler.UnixCCompiler.runtime_library_dir_option() should recognize ${configuration_name}-gcc
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment:
This bug tracker removes parts of splitted, long lines when the
previous line was ending with '-' :( .
There should be:
but it doesn't recognize ${configuration_name}-gcc
(e.g. x86_64-pc-linux-gnu-gcc) or
${configuration_name}-gcc-${version}
(e.g. x86_64-pc-linux-gnu-gcc-4.4.2).
The second URL has 2 parts:
http://www.gnu.org/software/autoconf/manual/html_node/
Specifying-Target-Triplets.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7617
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7615] unicode_escape codec does not escape quotes
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7615 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6943] setup.py fails to find headers of system libffi
Benjamin Peterson benja...@python.org added the comment: Fixed in r77212. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6491] Improve --with-dbmliborder option
Benjamin Peterson benja...@python.org added the comment: Applied in r77215. -- nosy: +benjamin.peterson resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5080] PyArg_Parse* should raise TypeError for float parsed with integer format
Mark Dickinson dicki...@gmail.com added the comment: Applied to trunk in r77218. The DeprecationWarning for the 'L' format needs to be merged to py3k. -- versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5080 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7618] optparse library documentation has an insignificant formatting issue
New submission from Artem vazovsky@gmail.com: In optparse documentation, in the end of first chapter there is an example which shows how optparse can print usage summary for user. In the last row of this example text color is accidentally changed from black to blue. Most probably the source of this issue is single quote sign which is misinterpreted by the code highlighter. -- assignee: georg.brandl components: Documentation messages: 97119 nosy: georg.brandl, vazovsky severity: normal status: open title: optparse library documentation has an insignificant formatting issue versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7618 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5080] PyArg_Parse* should raise TypeError for float parsed with integer format
Mark Dickinson dicki...@gmail.com added the comment: Merged relevant bits to py3k in r77220. -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5080 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7619] imaplib shouldn't use cause DeprecationWarnings in 2.6
New submission from djc dirk...@ochtman.nl: imaplib still calls os.popen2(), which has been deprecated in 2.6. It should probably use subprocess instead, even in 2.6, IMO. See http://bugs.gentoo.org/show_bug.cgi?id=282859 -- components: Library (Lib) messages: 97121 nosy: djc severity: normal status: open title: imaplib shouldn't use cause DeprecationWarnings in 2.6 versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7564] test_ioctl fails when run in background
Florent Xicluna la...@yahoo.fr added the comment: It fails if the test is run in background, and there's another process in foreground. Example 1: ~ $ (./python Lib/test/regrtest.py test_ioctl ) tail -f /dev/null test_ioctl test test_ioctl failed -- multiple errors occurred; run in verbose mode for details 1 test failed: test_ioctl Example 2 (a shell script): ~ $ cat run_ioctl.sh #!/bin/sh ./python Lib/test/regrtest.py -v test_ioctl test_ioctl.log tail -f test_ioctl.log -- priority: - low title: test_ioctl fails sometimes - test_ioctl fails when run in background versions: +Python 2.6, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7564] test_ioctl may fail when run in background
Changes by Florent Xicluna la...@yahoo.fr: -- title: test_ioctl fails when run in background - test_ioctl may fail when run in background ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7578] Behavior of operations on a closed file object is not documented correctly
Nick Coghlan ncogh...@gmail.com added the comment: Note that one of the reasons for the slightly wishy-washy phrasing in the docs is to give other implementations a bit more freedom in the way way they handle these error cases. Agreed that the main reason is the one Antoine gave though - the ValueError is looking at things from the point of view that the program passed in a closed file object when an open one was needed. -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7578 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7619] imaplib shouldn't use cause DeprecationWarnings in 2.6
Benjamin Peterson benja...@python.org added the comment: Fixed in r77222. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7619 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7611] shlex not posix compliant when parsing foo#bar
cadf chargodd...@gmail.com added the comment: Here's a patch addressing the behavior described. -- keywords: +patch nosy: +cadf Added file: http://bugs.python.org/file15718/shlex_posix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
