SEARCH YOUR SOLUTION HERE  

Strange Behavior: csv module & IDLE

I've noticed an oddity when running a program, using the csv module,
within IDLE. I'm new to Python so am confused by what is happening.
Here is what I'm doing:

1) Open the IDLE Shell.
2) Select File | Open...
3) Choose my file, foo.py, opening it in a window.
4) From that window, I hit F5 to run the module.

Within the program, the snippet where I use the csv module is below:

==============================
csvfile = open('foo.csv', 'w')
writer = csv.writer(csvfile)

for row in rows:
writer.writerow(row[0:3])

csvfile.close
==============================

The rows object is returned from a database query and is a list of
tuples. Now here is the strange thing. If I run this program
directly from the command line, i.e.,

D:\test> D:\python25\python foo.py

It runs fine, foo.csv is created and all is well. However, when I run
it through the IDLE shell as described above, the foo.csv file is
created but remains empty at 0 bytes. When I try to delete the file,
Windows says it is in use. The only way I can break out of this is by
restarting the IDLE shell. In other words, it appears that the shell
is hanging.

This will run through Task Scheduler, so shouldn't be a problem, but
I'm worried that I'm coding this wrong for it to be acting this way
under IDLE. Any help or explanation would be appreciated.

Best

Posted On: Wednesday 7th of November 2012 01:16:44 PM Total Views:  370
View Complete with Replies




Related Messages:

time.time() strangeness   (151 Views)
Ok, my final solution is to add the D3DCREATE_FPU_PRESERVE flag. It didn't harm performance in a noticeable way at all. I was under the impression SSE would be affected by this, too. Additionally I was under the impression that float precision would suffice for time.time(). Obviously I was blatantly wrong :-)
time.time() strangeness   (118 Views)
> Nevertheless time.time() shouldn't fail here unless DirectX is really > badly tinkering with my system. I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating the DirectX device the bug does not appear. This flag means "Direct3D defaults to single-precision round-to-nearest" (see [1]) mode. Unfortunately it is not an option to pass this flag, I need the performance boost it gives. Can somebody tell me how this interacts with python's time.time() I suppose it's some kind of double vs. float thing or some fpu asm code issue... -Matthias References: [1] http://msdn2.microsoft.com/en-us/lib...27(VS.85).aspx , Nitro schreef: >> Nevertheless time.time() shouldn't fail here unless DirectX is really >> badly tinkering with my system. > > I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating > the DirectX device the bug does not appear. This flag means "Direct3D > defaults to single-precision round-to-nearest" (see [1]) mode. > Unfortunately it is not an option to pass this flag, I need the > performance boost it gives. > > Can somebody tell me how this interacts with python's time.time() I > suppose it's some kind of double vs. float thing or some fpu asm code > issue... I got bitten by this some time ago in a project at work. At first time values in floats where wrong, but I didn't see why. Then I started seeing very strange results in other calculations, and it took me some time to find out it was because of DirectX. If you don't pass D3DCREATE_FPU_PRESERVE, DirectX puts the FPU in low-precision mode behind your back, which effects all floating point operations in your process, such as the calculation of time.time(). in the name of performance, but in my opinion that should certainly not be the default. Cheers, Roel
Re: time.time() strangeness   (204 Views)
En Tue, 26 Feb 2008 17:37:22 -0200, Nitro escribi: > today I encountered a very odd situation. I am on Windows Vista and using > Python 2.5.2. Here's a code snippet to illustrate my problem: > > # uncomment the next line to trigger the problem > # myExtensionModule.CreateDirect3D9Device() > import time > for i in range(0,100): > print time.time() > > With the line commented time.time() returns a changing value which is > what > I expect. However, when I uncomment it and create a Direct3D9 Device > [1][2] it keeps printing the very same number over and over! I had a similar problem some time ago. When a badly formatted audio file was played (on Windows XP, any player, not from Python), the C function ftime(&x) fails and fills x to all 0's from this moment on. ftime is supposed never to fail, but it does... time.time uses ftime on Windows. A possible workaround (floattime function, in timemodule.c): Change #if defined(HAVE_FTIME) struct timeb t; ftime(&t); return (double)t.time + (double)t.millitm * (double)0.001; #else /* !HAVE_FTIME */ time_t secs; time(&secs); return (double)secs; #endif /* !HAVE_FTIME */ to: time_t secs; #if defined(HAVE_FTIME) double res; struct timeb t; ftime(&t); res = (double)t.time + (double)t.millitm * (double)0.001; if (res>0) return res; #endif /* !HAVE_FTIME */ time(&secs); return (double)secs; (untested, I wrote this right now, but basically it's what I did that time). Finally the Python version was not patched, we just forbid to use that server to play MP3s As it was hard to reproduce the problem, I never got to submit a patch. > In my project > I am using twisted which uses time.time() to schedule all calls. Since > time.time() is completely screwed the whole application breaks. > I took a look at [3], but I can't see any obivous way how this all > interacts. Specifically I am not sure which API time.time() uses > internally (timeGetTime maybe). Knowing this could probably help me > debug > more. See timemodule.c, time.time maps to time_time, which calls floattime, which on Windows uses ftime. > I feel like time.time() should not break (unless the vid card > driver/directx has a major bug). Any idea what might be happening here > Replacing time.time() with time.clock() in twisted.python.runtime makes > the problem disappear. I guess because it uses QueryPerformanceCounter. Seems like a reasonable patch. -- Gabriel Genellina
Re: a strange SyntaxError   (150 Views)
--- CoolGenie wrote: > OK, sorry, this was about indents. Stupid VIM! One more piece of VIM advice. You can use "set list" to show where tabs are. I prefer to convert my own tabs to spaces automatically, but you inevitably come across code that you don't own where it's nice to see the tabs. ____________________________________________________________________________________ Looking for last minute shopping deals Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsea...egory=shopping
Re: strange syntax rules on list comprehension conditions   (165 Views)
On Jan 18, 2008 12:53 PM, Nicholas wrote: > I was quite delighted today, after extensive searches yielded nothing, to > discover how to place an else condition in a list comprehension. > Trivial mask example: > >>> [True if i [True, True, True, True, True, False, False, False, False, False] > > I then experimented to drop the else statement which yields an error > >>> [i if i>3 for i in range(10)] > Traceback ( File "", line 1 > this syntax works of course > >>> [i if i>3 else i for i in range(10)] > [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] > > Does anybody else find this lack of symmetry odd > "x if y else x" is an expression - it's the Python equivalent of C's ternary operator. The mechanism for filtering in a list comp is [x for x in y if x]. Your stumbling upon the ternary expression was a happy accident, and your confusing comes from trying to generalize the wrong operation.
Want a strange XML RPC server   (169 Views)
I would like to have a strage XML RPC server. It should use one main thread for all connections. I have some code like this (using a custom RPC server class): server_address = (LISTEN_HOST, LISTEN_PORT) # (address, port) server = mess.SecureXMLRPCServer.SecureXMLRPCServer( server_address, RequestHandler, KEYFILE,CERTFILE, allow_none=True, logger = servicelog.getLogger('SecureXMLRPCServer',filename=LOGFILENAME), logRequests=False, stop_requested = stop_requested ) rpcserver = RPCServer() # Object containing public RPC methods. server.register_instance(rpcserver) It works perfectly. Now here is the tricky part. I would like to send back events. It is implemented by an RPC callback: #1. client calls server.get_event() #2. server waits until the event happens (or until a given timeout) #3. server returns the event (if any) The clients are running on multiple threads, and the idea is that any client can send an event by calling server.send_event(event). That event will be returned to another client by the server. Since the clients are blocking (waiting for the RPC call to return), events will go from one client to another immediatelly (through the rpc server). This goes through different kinds of proxies, and can be used from different programming languages (Python and PHP clients, in my case...) The problem is that in #2, waiting for the event to happen inside the RPC server's handler method will block all other connections to the RPC server. Preferred solution: The get_event() method should run in a different thread inside the server, and return the event to its xmlrpc client from that thread. However, all other methods should use one main thread. I would like to implement this as a decorator like: class RPCServer(object): """Object containing public RPC methods.""" def method1(self,arg1): ..... def method2(self,arg1): ..... def method3(self,arg1): ..... @nonblocking def get_event1(self): try: # Wait for 10 seconds until an event is available. return self.asinharvester.queued_events1.get(True,10) except Queue.Empty: return None # Indicates that there was no queued event. @nonblocking def get_event2(self): try: # Wait for 10 seconds until an event is available. return self.asinharvester.queued_events2.get(True,10) except Queue.Empty: return None # Indicates that there was no queued event. Is this possible I have no idea how to write this "nonblocking" decorator.
Re: why ctypes+dll gives a strange result   (190 Views)
En Sun, 11 Nov 2007 08:21:25 -0300, oyster escribi: > import ctypes > mydll=ctypes.windll.LoadLibrary("mydll.dll") > > _TwoTimes=getattr(mydll,'TWOTIMES@8') > _TwoTimes.argtypes=[ctypes.c_double] > def TwoTimes(i): > return _TwoTimes(i) > > in fact, twotimes function return double*2, but when I use > print TwoTimes(10) > in python, I get 2226880 I think you should declare the result type also, if it's not an integer. _TwoTimes.restype=ctypes.c_double -- Gabriel Genellina
Python in a strange land: IronPython and ASP.NET at the next PyGTA   (256 Views)
IronPython is a native implementation of Python on the Microsoft .NET platform. The implementation is from Microsoft and the language is well supported by the Visual Studio development environment which has always been one of the Microsoft platform's strengths. Though Python is often associated with the Free and Open Source communities, consultants and developers frequently need to solve real-world problems using Python on the .NET platform. IronPython makes using Python in these situations a natural choice for the Python programmer. Our speaker for the evening is Myles Braithwaite, a local consultant and developer. He is going to give us an idea of how developing a web application using ASP.NET looks when using IronPython instead of C#, as well as his impressions of the platform. As usual, we will hold the presentation at Linux Caffe, gathering for introductions at 6:30 PM, with the formal presentation beginning at 7:00 PM. We normally head out around 8:30 PM for beer, coffee and/or ice cream. You can find directions and maps to Linux Caffe on the wiki: http://web.engcorp.com/pygta/wiki/NextMeeting Hope to see you all there, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: struct.pack behavior   (110 Views)
On 25Jun2008 22:38, Steven Clark wrote: | On Wed, Jun 25, 2008 at 7:03 PM, John Machin wrote: | > On Jun 26, 9:00 am, "Steven Clark" wrote: | >> Can anyone explain to me why | >> struct.pack('HB',1,2) gives 3 bytes, whereas struct.pack('BH',1,2) | >> gives 4 bytes | >> | > Alignment -- read the manual. | | If "the manual" is the help files for the struct module, I've read it | several times over. I understand endianness; I don't understand | alignment. Could anyone give a less cryptic / terse answer For efficiency reasons many CPUs require particular primitive data types (integers/pointers of various sizes) to be placed in memory at particular boundaries. For example, shorts ("H" above, usually two bytes and probably always so in the struct module) are often required to be on even addresses, and longer objects to be on 4 or 8 byte boundaries. This allows for much more efficient memory access on many platforms (of course the rules depend on the platform). Although RAM _appears_ to the random access to arbitrary bytes, the underlying hardware will often fetch chunks of bytes in parallel. If a number spanned the boundaries of such a chunk it would require two fetch cycles instead of one. So this is avoided for performance reasons. So, packing "HB" puts a short at offset 0 (even) and then a byte. Conversely, packing "BH" puts a byte at offset zero but puts the short at offset 2 (to be even), leaving a gap after the byte to achieve this, thus the 4 byte size of the result (byte, gap, short). This layout procedure is called "alignment". Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach the very, very top, and then it tends to slope away rather sharply.
Weird behavior with lexical scope   (114 Views)
I ran into a weird behavior with lexical scope in Python. I'm hoping someone on this forum can explain it to me. Here's the situation: I have an Outer class. In the Outer class, I define a nested class 'Inner' with a simple constructor. Outer's constructor creates an instance of Inner. The code looks like this: ========= class Outer: class Inner: def __init__(self): pass def __init__ (self): a = Inner() Outer() ========= However, the above code doesn't work. The creation of Inner() fails. The error message looks like this: File "/tmp/foo.py", line 12, in Outer() File "/tmp/foo.py", line 10, in __init__ a = Inner() NameError: global name 'Inner' is not defined This surprises me! Since the construction of Inner takes place within the lexical scope 'Outer', I assumed the interpreter would search the Outer scope and find the 'Inner' symbol. But it doesn't! If I change: a = Inner() to a = Outer.Inner() it works fine, though. So, can anyone explain to me how Python looks up symbols It doesn't seem to be searching the scopes I expected...
module import search path strangeness   (137 Views)
I have a python script (part of a django application, if it makes any difference) which is exhibiting the following behaviour: import my_module # succeeds imp.find_module("my_module") # fails, raising ImportError which is completely baffling me. According to sys.path, both should fail; the directory containing my_module is not in sys.path (though the my_module directory itself is). More puzzlingly, printing out my_module.__file__ gives: /home/tow/test/my_module/../my_module/__init__.pyc I don't really understand what the ".." is doing in there. Can someone explain what I'm missing here, it's got me stumped. Toby , On Aug 12, 4:59pm, Peter Otten wrote: > tow wrote: > > On Aug 12, 9:56am, Peter Otten wrote: > >> tow wrote: > > >> > Basically, I had thought that import and imp.find_module used exactly > >> > the same > >> > search path, but the above example shows that at least in this > >> > circumstance they > >> > don't; import is picking up additional search paths from somewhere - > >> > what am I missing > > >> Grepping through the django source finds > > >> ./trunk/django/core/management/__init__.py: > >> sys.path.append(os.path.join(project_directory, os.pardir)) > > > Hmm. It turns out that that is indeed the issue, but in a way that > > wasn't immediately obvious to me. Looking at it in more context: > > > sys.path.append(os.path.join(project_directory, os.pardir)) > > project_module = __import__(project_name, {}, {}, ['']) > > sys.path.pop() > > Ouch. > > > So, to answer my original question, the difference in search behaviour > > between "import" and "imp.find_module" is that the former might not > > look at sys.path at all if the module has already been loaded, while > > the latter will only search on the current sys.path. > > > Am I right > > Yes. 'import' looks up the file in a cache, the sys.modules dictionary, > before it falls back to the more costly alternatives. > > Peter
Weird Python startup behavior between different drives on PowerPCplatform   (145 Views)
I'm experiencing some strange behavior when starting up python on a Debian-based PowerPC platform. Normally, I operate from this platform with a root file system on an IDE flash drive (/dev/hda1). However, I'm trying to get my system to run with root on a mechanical SATA drive (/dev/sda1). Both are installed on a PowerPC board via a PMC daughter board. When running off the flash drive, the Python interpreter loads and runs just fine. However, when running from SATA, the interpreter seems to have problems with importing things like site, os, etc. I've played around with PYTHONHOME to no effect. I even went as far as setting PYTHONHOME to some off the wall location (so no stdlibs will load) and invoking Python as: host$ PYTHONHOME=/tmp python -d -v -S # installing zipimport hook import zipimport # builtin # installed zipimport hook Python 2.4.4 (#2, Apr 5 2007, 19:01:44) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 >>> i=0 File "", line 1 i=0 ^ SyntaxError: invalid syntax >>> You'll note that doing something as simple as setting "i=0" results in a syntax error. If I run the same thing on the IDE flash drive, it works: host$ PYTHONHOME=/tmp python -d -v -S # installing zipimport hook import zipimport # builtin # installed zipimport hook Python 2.4.4 (#2, Apr 5 2007, 19:01:44) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 >>> i=0 >>> Any ideas! What could possibly cause a difference of operation between running from a IDE flash drive (/dev/hda1) vs. SATA (/dev/ sda1) Other than toggling hda1 vs. sda1 in /etc/fstab, the filesystems are being built identically. Could it be that shared libraries aren't being loaded correctly or fast enough off the SATA drive vs. flash Shooting in the dark here...
Python "is" behavior   (99 Views)
I am not certain why this is the case, but... >>> a = 256 >>> b = 256 >>> a is b True >>> a = 257 >>> b = 257 >>> a is b False Can anyone explain this further Why does it happen 8-bit integer differences
gtk.gdk.Pixbuf.scale() unexpected behavior when offset != 0   (118 Views)
Hi! I'm developing a pygtk application where I need to show images zoomed in so that the user can see individual pixels. gtk.gdk.Pixbuf.scale() seemed ideal for this, but if I set offset_x and offset_y to anything other than 0, the resulting image is heavily distorted and the offset is wrong. I've searched the internet for any snippet of code that uses this function with nonzero offset, but even after several hours of searching I've still come up blank. I think this may be a bug, but since it seems so fundamental I think it's way more likely that I've misunderstood something, so I thought I'd pass this by c.l.p first. Any help is greatly appreciated. I wrote a test program to show off this behavior. Please find attached an image of David Hasselhoff with some puppies to help facilitate this demonstration. (feel free to use any image, but who doesn't like Hasselhoff and puppies) show_hasselhoff.py #------------------------------------------------------- import gtk original = gtk.gdk.pixbuf_new_from_file('hasselhoff.jpeg') w = original.get_width() h = original.get_height() interp = gtk.gdk.INTERP_NEAREST nice = gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB, False, 8, w, h) ugly = gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB, False, 8, w, h) original.scale(nice, 0, 0, w, h, 0, 0, 2, 2, interp) original.scale(ugly, 0, 0, w, h, w/2, h/2, 2, 2, interp) outtake = original.subpixbuf(w/4, h/4, w/2, w/2) expected = outtake.scale_simple(w, h, interp) w = gtk.Window() hbox = gtk.HBox() hbox.add(gtk.image_new_from_pixbuf(original)) hbox.add(gtk.image_new_from_pixbuf(nice)) hbox.add(gtk.image_new_from_pixbuf(ugly)) hbox.add(gtk.image_new_from_pixbuf(expected)) w.add(hbox) w.show_all() w.connect('destroy', gtk.main_quit) gtk.main() #------------------------------------------------------- When you run this, you should see 4 images in a window. From left to right: original, nice, ugly and expected. nice, ugly and expected are scaled/cropped copies of original, but ugly and expected are offset to show less mullet and more face. expected is what I expected ugly to turn out like judging from the pygtk docs. Things to note about ugly: * The topleft pixel of original has been stretched to the area of offset_x * offset_y. * The first offset_x - 1 top pixels of original have been scaled by a factor 2 horizontally and then stretched vertically to the height of offset_y. * Vice versa for the first offset_y - 1 leftmost pixels of original. * The remaining area of ugly is a scaled version of original(1,1,width/2-1,height/2-1). Things to note about the methods: * This behavior is constant for all interpolation methods. * This behavior is identical in gtk.gdk.Pixbuf.compose(). This can't possibly be how this is supposed to work! Have I misunderstood something, or is this a bug Cheers! /Joel Hedlund
Re: Python -v import behavior   (108 Views)
On 2008-04-30 18:42, Sean Ryan wrote: > Hi all, > (A similar question was posted by a colleague, but did not appear to reach > comp.lang.python or this list). > > I am wondering if the -v option causes the python application to be more > tolerant to module import warnings and / or errors. > > The reason is that a module is failing to import correctly (generating an > ImportError exception). Examining this closer we re-ran the script using > the -v option. to find that "Unsatisfied symbol" errors we being displayed > during import (cx_Oracle 4.3.1, python 2.5.1, HP-UX 11, oracle 9.2). > However, the module is usable from the python prompt (when using -v) > displayed, i.e. dir (cx_Oracle) works correctly, as does database > interaction. Without the -v option the script is halted due to the > ImportError exception. > > My questions are: > 1. Is there a way to mimic the seemingly more tolerant import behavior of > python -v without producing the verbose output > 2. Is the behavior described above expected and documented The -v option only causes Python to print more information to stderr explaining where it is looking for modules. You should be seeing any dynamic loader messages in both cases, ie. when running with or without -v. While it is possible that cx_Oracle does some extra processing when running Python in -v mode, this is rather unlikely. Note that the best way to track down "unsatified symbol" errors is to inspect the dependencies of the modules and other shared libs involved. Running an strace (or similar system trace utility) will also help to identify the problem, since this lists the shared libs the process tries to load when starting up and also during import of Python modules. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 01 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611
Strange loop behavior   (92 Views)
, I wrote a program that reads data from a file and puts it in a string, the problem is that it loops infinitely and that's not wanted, here is the code : d = repr(f.read(DEFAULT_BUFFER_SIZE)) while d != "": file_str.write(d) d = repr(f.read(DEFAULT_BUFFER_SIZE)) I also tried writing the while's condition like so : len(d) > 0, but that doesn't change anything. I tried step-by-step debugging using PyDev(eclipse plugin) and I noticed this, once the while was read once, it is never re-read, basically, the looping does happen, but just in between the two lines in the loop's body/block, it never goes on the while and thus never verifies the condition and thus loops forever. I had been using psyco (a sort of JIT for python) and so I uninstalled it and restarted eclipse and I still get the same thing. This looks like some bug, but I may be wrong, does anybody understand what's going on here
Re: Strange loop behavior   (100 Views)
Gabriel Rossetti wrote: > , > > I wrote a program that reads data from a file and puts it in a string, > the problem is that it loops infinitely and that's not wanted, here is > the code : > > d = repr(f.read(DEFAULT_BUFFER_SIZE)) > while d != "": > file_str.write(d) > d = repr(f.read(DEFAULT_BUFFER_SIZE)) > > I also tried writing the while's condition like so : len(d) > 0, but > that doesn't change anything. I tried step-by-step debugging using > PyDev(eclipse plugin) and I noticed this, once the while was read once, > it is never re-read, basically, the looping does happen, but just in > between the two lines in the loop's body/block, it never goes on the > while and thus never verifies the condition and thus loops forever. I > had been using psyco (a sort of JIT for python) and so I uninstalled it > and restarted eclipse and I still get the same thing. This looks like > some bug, but I may be wrong, does anybody understand what's going on here > >
wx.EVT_RIGHT_UP strangeness?   (140 Views)
I am playing with wxPython 2.8.7.1 on OS X 10.4.11 with MacPython 2.5 When running the demo program, the ShapeWindow demo does not close the window on right click. It turns out that the wx.EVT_RIGHT_UP does not fire. I discovered that one way to get it to fire is to bind the wx.EVT_RIGHT_DOWN event also. Thus adding the following two lines solves the problem: in __init__ add: self.Bind(wx.EVT_RIGHT_DOWN, self.OnRightDown) secondly add: def OnRightDown(self, evt): pass Everything then works ok. My question is: Is this how it is supposed to work, and if not, am I the only one with this problem
Can someone explain this unexpected raw_input behavior?   (134 Views)
It's often useful for debugging to print something to stderr, and to route the error output to a file using '2>filename' on the command line. However, when I try that with a python script, all prompt output from raw_input goes to stderr. Consider the following test program: === Start test.py === import sys def main(): print " world" raw_input("Press ENTER") print "Goodbye world" if __name__ == "__main__": main() === End test.py === If I run it with the command line 'python2.5 test.py', I get the following output: world Press ENTER
wx.EVT_RIGHT_UP strangeness?   (108 Views)
I'm playing with wxPython 2.8.7.1 on OS X 10.4.11 with MacPython 2.5 I ran the demo program found what may be a bug with the right mouse button up event. The demo is ShapedWindow.py. Everthing thing seems to work fine except that right clicking does not close the window. Tracing the program shows that the event never fires. Upon closer scrutiny I discovered if you bind the wx.EVT_RIGHT_DOWN event, the wx.EVT_RIGHT_UP now fires. I tried this in a couple programs and the behavior is consistent. Is this the way it is supposed to work If not, am I the only one with this problem