🌐 Mailman 3 April 2003 - Python-list - python.org

Re: else: w/o except: - why not?
by David Eppstein April 1, 2003

April 1, 2003

In article <mailman.1049211247.3694.python-list(a)python.org>, Michael Chermside <mcherm(a)mcherm.com> wrote: > I think that a "bare except" is useful in only two ways. The first > is like a "finally" clause that's skipped if everything works. [...snip...] > The other situation is running "untrusted plug-in" code of some > sort. I have a bare except wrapped around the main event loop of some python gui code. It provides an opportunity to log the problem and give the user a chance to clean up instead of just immediately crashing. Doesn't seem to fit into either of your two uses, but I think it's a legit use. -- David Eppstein http://www.ics.uci.edu/~eppstein/ Univ. of California, Irvine, School of Information & Computer Science

1 0

Re: else: w/o except: - why not?
by claird＠lairds.com April 1, 2003

April 1, 2003

In article <mailman.1049211247.3694.python-list(a)python.org>, Michael Chermside <mcherm(a)mcherm.com> wrote: . . . >I can't speak for Tim, but my OWN opinion is precisely in alignment >with what you have written. > >I think that a "bare except" is useful in only two ways. The first >is like a "finally" clause that's skipped if everything works. In >other words, the following bits of code is (almost[1]) equivalent to >your second example: > > everythingWorked = False > try: > f1() > everythingWorked = True > finally: > if not everythingWorked: > f2() > >This doesn't come up much, but it's occasionally useful, and your >version (using bare except with a raise) is a little prettier. > >The other situation is running "untrusted plug-in" code of some >sort. Something like this: > > try: > randomCodeSomebodyUploaded() > except: > logProblem() > >But really, that hardly EVER comes up. I wish that guido had made >it harder to spell "bare except" because these situations seem so >unusual. The next best solution is to just avoid it unless you're >SURE you need it. . . . Thanks, Michael. I'm rather obsessive on exceptions; I think programmers generally misunderstand them and neglect their importance. Very, VERY few programming texts do them justice; one ele- ment of my enthusiasm for Alex's books <URL: http:// www.unixreview.com/documents/s=7822/ur0303j/ > is that he speaks like an adult about them. Unless you've made a disciplined survey of the extant literature, you won't realize how rare this is. I'm working on a couple of articles of my own to shift the balance a bit. I disagree with you on the frequency of "running 'untrusted plug-in' code", or perhaps I misunderstand what you mean. Briefly, I mistrust a LOT of code. Even when I'm using well-known, mature extensions, my aim is to have at least top-level error-handlers that catch *everything*. Are we on the same subject? -- Cameron Laird <Cameron(a)Lairds.com> Business: http://www.Phaseit.net Personal: http://phaseit.net/claird/home.html

1 0

Re: Trying to run Boa Constructor on Windows
by jennyw＠colorfulexpressions.com April 1, 2003

April 1, 2003

Cliff Wells <LogiplexSoftware(a)earthlink.net> wrote in message news:<mailman.1049154948.9372.python-list(a)python.org>... > Get the latest wxPython (2.4.0.7, IIRC) and get Boa Constructor from > CVS. There's been a lot of changes the last couple of weeks for both > packages. In the end, that's what I ended up doing. I was originally hesitant to get stuff off CVS because I thought it might be unstable, but it seems to be working well. Thanks! Jen

1 0

Re: else: w/o except: - why not?
by Michael Chermside April 1, 2003

April 1, 2003

Tim Peters writes: > ...a bare except is bad practice... Cameron Laird writes: > I want to be clear about the judgment that "a bare except is bad > practice". Are you talking about any unqualified except? Is > try: > f1() > except ZeroDivisionError: > f2() > except: > f3() > an instance of "a bare except" in the sense that you intend here? > And, for you, does > try: > f1() > except: > f2() > raise > become *not* bad practice? I can't speak for Tim, but my OWN opinion is precisely in alignment with what you have written. I think that a "bare except" is useful in only two ways. The first is like a "finally" clause that's skipped if everything works. In other words, the following bits of code is (almost[1]) equivalent to your second example: everythingWorked = False try: f1() everythingWorked = True finally: if not everythingWorked: f2() This doesn't come up much, but it's occasionally useful, and your version (using bare except with a raise) is a little prettier. The other situation is running "untrusted plug-in" code of some sort. Something like this: try: randomCodeSomebodyUploaded() except: logProblem() But really, that hardly EVER comes up. I wish that guido had made it harder to spell "bare except" because these situations seem so unusual. The next best solution is to just avoid it unless you're SURE you need it. -- Michael Chermside

1 0

Re: Terminal-based text editor with color syntax hilighting
by Thomas Dickey April 1, 2003

April 1, 2003

Sean 'Shaleh' Perry <shalehperry(a)attbi.com> wrote: > On Monday 31 March 2003 19:39, Dave Benjamin wrote: >> Hey folks, >> >> I often write Python over a terminal session, and I really enjoy working >> with color syntax hilighting, so my editor of choise for the past year or >> so has been Jed. I've heard that it's possible to get color hilighting to >> work with Emacs, but so far I've been unable to get that working. (Note: >> I'm talking about an SSH session, not an XTerm. Text only.) ssh is an application that might run in an xterm >> I think Jed is a nice editor, and it's very fast, but I'm wondering if >> there are any other editors that support this feature. Does anyone know? >> >> Thanks, >> Dave > new gnu emacs (around 8 months old I think) and vim (a super vi clone) both > support color coding. actually XEmacs has done color for a few years. For vi-clones, elvis and vile both do color as well. -- Thomas E. Dickey <dickey(a)radix.net> <dickey(a)herndon4.his.com> http://dickey.his.com ftp://dickey.his.com

2 1

Catching webbrowser error in RedHat
by Lance April 1, 2003

April 1, 2003

Hi All, I'm running Python 2.2 under RedHat8. I use webbrowser to open an html file in a browser window. This is my code: try: webbrowser.open(fname) except: print "ERROR: "+fname+" not found." 1. A Redhat "splash" screen shows for a few seconds prior to my desired screen when try block is successful. Can this splash screen be disabled? 2. If the try block is not successful, the Redhat splash screen shows, followed by an ugly system message box saying that the file could not be found. I want only the message in my except clause to display, not the system message. Any suggestions for dealing with this issue will be greatly appreciated. It appears that the splash screen problem does not exist in Mandrake. Thanks, Lance

5 5

Re: Is Python overhyped (just like Java)?
by Roy Smith April 1, 2003

April 1, 2003

"Ajay na" <ajay_637(a)hotmail.com> wrote: > Nope...I'm not trolling...I want someone to give a solid and intelligent > argument about why I should switch from C++ to Python! In general, development time is a lot faster in Python, and execution speed is a lot faster in C++. How much? Hard to say, but an order of magnitide in both cases might not be a bad first guess. For an amazingly large amount of what most people do, execution speed is just not a significant factor. For an amazingly large amount of what most people do, development time is. Doesn't it make sense to use something which is optimized for development time? Try this. Count the number of times in the past month your boss has asked you, "is it done yet?". Now, count the number of times he's asked, "how come it runs so slow?". If "is it done yet?" won, you're probably a good candidate for Python. C++ programs also tend to be optimized in the wrong ways. The low-level nature of the language encourages people to worry about low-level stuff that saves a few CPU cycles here or there. At the same time, sea of low-level details you have to worry about like memory management and const correctness tends to obscure the bigger issues like algorithmic complexity. STL makes some strides towards getting people to use efficient algorithms, but it adds a whole layer of complexity of its own. Python hides all the low-level stuff and lets you concentrate on the problem you are trying to solve. This might even lead to Python apps running faster than C++ apps. In a fixed amount of development time, you get to think more about design and algorithms and less about memory leaks, dangling pointers, const correctness, and whether you need to write a copy constructor or not. Python is also an interpreted language. The advantage of this during development and debugging are often grossly under-estimated. I just make a trivial change to a single source file in a project I'm working on and times how long it took to run make. It took 1 minute, 41 seconds. The vast majority of that time was make itself, recursing up and down the directory tree to discover that nothing else had changed. Had the change been to a core header file, I might have been waiting for 15 minutes while make recompiled the whole world. With Python, I would have been able to test my change in a matter of seconds. When I'm developing in Python, I'm always firing up an interpreter and trying out some code snippet. It's so fast, it doesn't even break the flow of what I was thinking of. I do it all the time when I can't remember what methods a particular object or data type has. For example, I just did: roy% time python Python 2.2 (#1, 07/14/02, 23:25:09) [GCC Apple cpp-precomp 6.14] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> d = {} >>> dir(d) ['__class__', '__cmp__', '__contains__', '__delattr__', '__delitem__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__gt__', '__hash__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__ne__', '__new__', '__reduce__', '__repr__', '__setattr__', '__setitem__', '__str__', 'clear', 'copy', 'get', 'has_key', 'items', 'iteritems', 'iterkeys', 'itervalues', 'keys', 'popitem', 'setdefault', 'update', 'values'] >>> ^D 0.050u 0.090s 0:07.32 1.9% 0+0k 21+2io 0pf+0w That's 7 seconds to remind myself what methods dictionaries have. That's a lot faster than looking it up in a manual (or even on-line). Quick, does an STL map<> support equal_range()? How long will it take you to look that up? I bet it's more than 7 seconds. These example may not sound like much, but they add up when you consider how many times a day you do things like this.

4 3

What a Deal << 2GB and 1GB >> USB Flash Memory Drive
by lorabanks April 1, 2003

April 1, 2003

Great Deals on USB Flash Memory Drive >>>>> Price: 2GB - $779 >>>>> Price: 1GB - $389 with and with Free Shipping *%$ http://www.ebestshoppers.com #%&

2 1

Re: Implementing a "classmethod" in an extension type
by Thomas Heller April 1, 2003

April 1, 2003

"Mark Franklin" <mfranklin(a)tcsi.com> writes: > Hi, > > I've got an built-in extension type, implemented in C. I want to be able to implement the equivalent of a "classmethod" in that type. > > I thought I might be able to do something like this, which fairly closely mimics what you do in Python: > > PyTypeObject myType = { > // initialised in the usual way. It's tp_methods field includes a method definition for "MyMethod"....... > }; > > PyObject *method = PyObject_GetAttrString(myType, "MyMethod"); > // method is a PyMethodDescrObject > PyObject *classMethod = PyClassMethod_New(method); > PyObject_SetAttrString(myType, "MyMethod", classMethod); > Py_DECREF(method); > > PyType_Ready(myType); > > > However, when I do this I get a TypeError exception from the PyObject_SetAttrString call: "can't set attributes of built-in/extension type 'MyType' ". > > So, how do I get the class method into the type object? > > > Thanks, > Mark In Python 2.3, there is a METH_CLASS flag. Unfortunately not in 2.2. Here are the relevant snippets that I use - it is from http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ctypes/ctypes/source/_ctypes… and it compiles with Python 2.2 as well as 2.3. HTH, Thomas #include "Python.h" #ifndef METH_CLASS #define METH_CLASS 0x0010 /* from Python 2.3 */ #define NO_METH_CLASS #endif ... /* * If this is a real C classmethod (Python 2.3 and later), * it has METH_O style. So the type is in the first argument, * and the arg in the second. * * We fake this in Python 2.2, where METH_CLASS is not present, * and 'args' is a tuple containing the type as first member. */ static PyObject * CString_from_param(PyObject *cls, PyObject *args) { PyObject *value; #ifdef NO_METH_CLASS PyObject *ignore; if (!PyArg_ParseTuple(args, "OO", &ignore, &value)) return NULL; #else value = args; #endif ... } static PyMethodDef CString_methods[] = { #ifdef NO_METH_CLASS /* Python 2.2 */ { "from_param", CString_from_param, METH_VARARGS | METH_CLASS, #else { "from_param", CString_from_param, METH_O | METH_CLASS, #endif from_param_doc }, { NULL, NULL }, }; ... if (PyType_Ready(&CString_Type) < 0) return; #ifdef NO_METH_CLASS DoClassMethods(&CString_Type); #endif PyModule_AddObject(m, "c_string", (PyObject *)&CString_Type);

1 0

Breaking out of a while loop with a key press?
by Richard April 1, 2003

April 1, 2003

Hi, Can anyone suggest a simple way of detecting a key press and existing the program? I have a program which at the moment uses a while True: statement. However this is not ideal as I have to close down the console window to exist the program. Can anyone tell me the proper way of doing this? So that a CTRL-C, for example, can quit the program correctly? Cheers Richard

7 9