Re: Standard IPC for Python?
On Jan 13, 2:37 pm, Philip Semanchuk wrote: > On Jan 13, 2009, at 2:01 PM, Laszlo Nagy wrote: > > > > >> I realize that lack of Windows support is a big minus for both of > >> these modules. As I said, any help getting either posix_ipc or > >> sysv_ipc working under Windows would be much appreciated. It sounds > >> like you have access to the platform and incentive to see it > >> working, so dig in if you like. > > Maybe I can help with windows. I just need to figure out what to > > use: pipes or windows sockets? > > >http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx > > I was suggesting getting posix_ipc or sysv_ipc to compile against a > compatibility library (Cygwin?) under Windows. It sounds like you're > proposing something totally different, no? It's not really correct to call Cygwin a compatibility library. It's more of a separate system. In any case, the current version (1.5.25) does not support sem_unlink or shm_unlink so posix_ipc does not build. Cygwin 1.7, currently under test, will support these. I haven't tried it yet. I expect it will work OOTB. -- http://mail.python.org/mailman/listinfo/python-list
Re: Standard IPC for Python?
On Jan 13, 5:08 pm, Philip Semanchuk wrote: > On Jan 13, 2009, at 4:31 PM, drobi...@gmail.com wrote: > > > On Jan 13, 2:37 pm, Philip Semanchuk wrote: > >> I was suggesting getting posix_ipc or sysv_ipc to compile against a > >> compatibility library (Cygwin?) under Windows. It sounds like you're > >> proposing something totally different, no? > > > It's not really correct to call Cygwin a compatibility library. It's > > more of a separate system. > > Thanks for the education; I'm obviously not very familiar with it. > > > In any case, the current version (1.5.25) does not support sem_unlink > > or shm_unlink so posix_ipc does not build. Cygwin 1.7, currently under > > test, will support these. I haven't tried it yet. I expect it will > > work OOTB. > > Thanks for the report. Strange that it supports the functions to open > but not close semaphores. IN any case, I'd be very happy if posix_ipc > or sysv_ipc would work with few or no modifications under Cygwin. > > Cheers > Philip I just downloaded cygwin 1.7 and posix_ipc builds successfully. The demo appears to work. -- http://mail.python.org/mailman/listinfo/python-list
Re: LGPL license for Qt 4.5
On Jan 14, 7:57 am, sturlamolden wrote: > According to a Norwegian publication, Nokia will release Qt under LGPL > as of version 4.5. > > If I had stocks in Riverbank Computing ltd., I would sell them now... > > For the rest of us, this is fantastic news. > > http://digi.no/php/art.php?id=800922 http://www.qtsoftware.com/about/licensing Not sure what this means for PyQt -- http://mail.python.org/mailman/listinfo/python-list
Re: Who's on First, IDLE or pythonWin? Dialog Problem?
On Feb 11, 2:51 pm, Steve Holden wrote:
> W. eWatson wrote:
> > Steve Holden wrote:
> >> W. eWatson wrote:
> >>> My program in IDLE bombed with:
> >>> ==
> >>> Exception in Tkinter callback
> >>> Traceback (most recent call last):
> >>> File "C:\Python25\lib\lib-tk\Tkinter.py", line 1403, in __call__
> >>> return self.func(*args)
> >>> File
> >>> "C:\Sandia_Meteors\New_Sentinel_Development\Sentuser_Utilities_Related\sentuser\sentuserNC25-Dev4.py",
>
> >>> line 552, in OperationalSettings
> >>> dialog = OperationalSettingsDialog( self.master, set_loc_dict )
> >>> File
> >>> "C:\Sandia_Meteors\New_Sentinel_Development\Sentuser_Utilities_Related\sentuser\sentuserNC25-Dev4.py",
>
> >>> line 81, in __init__
> >>> tkSimpleDialog.Dialog.__init__(self, parent)
> >>> File "C:\Python25\lib\lib-tk\tkSimpleDialog.py", line 69, in __init__
> >>> self.wait_visibility() # window needs to be visible for the grab
> >>> File "C:\Python25\lib\lib-tk\Tkinter.py", line 415, in wait_visibility
> >>> self.tk.call('tkwait', 'visibility', window._w)
> >>> TclError: window ".34672232" was deleted before its visibility changed
> >>> ===
> >>> It runs fine in pythonWin performing the same entry operation. Open a
> >>> menu, select an item to open a dialog, select a select button in the
> >>> dialog, press OK to leave the dialog. Boom, as above.
>
> >>> (This does not mean pythonWin doesn't have problems of its own. ) If I
> >>> just execute the code (double click on the py file, the console shows no
> >>> problems. IDLE is unhappy.
>
> >>> Another side to this is that I use WinMerge to find differences between
> >>> my last saved copy and the current copy. I found the current copy had
> >>> two lines where a abc.get() was changed to abc.get. This was undoubtedly
> >>> from briefly using the pyWin editor, when I mis-hit some keys. Yet pyWin
> >>> had no trouble executing the program. My guess is that while briefly
> >>> editing there, I hit some odd combination of keys that produced,
> >>> perhaps, an invisible character that pyWin ignores.
>
> >>> Not the 34672232 window is a dialog that I closed by pressing OK. I
> >>> would again guess, that, if there is a problem, it occurs in the code
> >>> that destroys the dialog.
>
> >> Well you have to remember that you are trying to run a windowed GUI
> >> under the control of another windows GUI, so it isn't surprising that
> >> you hit trouble.
>
> >> With IDLE the issue will be that IDLE already created a main window
> >> before your program started running. With PythonWin you are using two
> >> different toolkits, so it isn't really surprising that breaks down -
> >> there will be two entirely separate main loops competing with each other.
>
> > Not quite. I take down IDLE when I run pyWin, and vice versa.
>
> The two separate loops being PyWin (which uses MFC) and your program
> (which uses Tkinter). You just can't mix GUIs in the same process like
> that, sorry.
>
> regards
> Stedve
> --
> Steve Holden +1 571 484 6266 +1 800 494 3119
> Holden Web LLC http://www.holdenweb.com/
Deja-vu!
http://mail.python.org/pipermail/python-list/2001-March/076069.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: Looking for the best way to translate an idiom
On Dec 14, 11:19 am, Paul Moore wrote: > I'm translating some code from another language (Lua) which has > multiple function return values. So, In Lua, it's possible to define a > function > > function f() > return 1,2,3 > end > > which returns 3 values. These can then be used/assigned by the caller: > > a,b,c = f() > > So far, much like Python, but the key difference is that in Lua, > excess arguments are ignored - so you can do > > a = f() > or even > a = f() + 1 > > where in the latter, a is 2 (as addition only needs 1 argument, so the > extra ones are discarded). > > This results in the code which I'm trying to translate having > functions which return multiple arguments, the first of which is the > "main" result, and the following values are "extra" results > (specifically, the position at which a match is found, followed by the > "captured" values of the match). > > I'm trying to find a natural equivalent in Python. So far, I've > considered the following: > > - return a tuple (pos, captures). This is messy, because you end up > far too often unpacking the tuple and throwing away the second value > - return an object with pos and captures attributes. This is better, > as you can do match(...).pos to get the position alone, but it doesn't > really feel "pythonic" (all those calls with .pos at the end...) > - have 2 calls, one to return just the position, one to return both. > This feels awkward, because of the 2 method names to remember. > > To make things worse, Lua indexes strings from 1, so it can use a > position of 0 to mean "no match" - so that a simple "did it match?" > test looks like if (match())... - where in Python I need if > (matchpos(...) != -1)... (Although if I return a match object, I can > override __nonzero__ to allow me to use the simpler Lua form). > > Can anyone suggest a good idiom for this situation? At the moment, I'm > returning a match object (the second option) which seems like the > least bad of the choices (and it mirrors how the re module works, > which is somewhat useful). But I'd like to know what others think. If > you were using a pattern matching library, what interface would you > prefer? > > I suspect my intuition isn't accurate here, as most of the use I've > made of the library is in writing tests, which isn't typical use :-( > > Thanks for any assistance. > > Paul I'm baffled by this discussion. What's wrong with a, dontcare, dontcare2 = f() a = a + 1 Simple, clear, and correct. -- http://mail.python.org/mailman/listinfo/python-list
Re: PyFits for Windows?
On Mar 29, 9:39 am, "W. eWatson" wrote: > John Yeung wrote: > > On Mar 28, 4:03 pm, Michiel Overtoom wrote: > >> W. eWatson wrote: > >>> It looks like PyFits downloads are for Linux. > >>> Isn't there anything available for Win (xp)? > >> To install it, unpack the tar file and > >> type: python setup.py install" > > >> It looks like PyFits is platform-independent. > > > Perhaps the original poster is referring to the tar file, which isn't > > natively supported by Windows and possibly isn't understood by WinZip > > either (not sure about that one). I recommend downloading and > > installing 7-Zip, which is free and handles more formats. It will let > > you extract the contents, which you can then install normally with the > > setup script as shown above. > > > John > > Yes, I keep getting to a tar file with Google and just going to the STSci > site. I use IZarc. Maybe it handles tar files. I'll give it a try. > > -- > W. eWatson > > (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) > Obz Site: 39° 15' 7" N, 121° 2' 32" W, 2700 feet > > Web Page: A windows tar can be found at: http://gnuwin32.sourceforge.net/packages/gtar.htm (personally, I use cygwin) -- http://mail.python.org/mailman/listinfo/python-list
Re: unpack the source tarball on Windows
On Mar 30, 7:10 pm, Mensanator wrote: > I'm looking for the Turtle Graphics Demos (apparently not included in > the Windows install). > > So I downloaded the bzipped source tarball. > > I've got Cygwin installed and assume it has the needed utilities. > > What would I type at the Cygwin prompt to unpack this puppy? I'm not familiar with the Turtle Graphics Demo so I'm just guessing at the name of the tarball. You'll use something like this: bzip2 -cd TurtleGraphicsDemo.tar.gz | tar xf - -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 382: Namespace Packages
On Apr 2, 5:59 pm, Ben Finney wrote: > Kay Schluehr writes: > > Wow. You python-dev guys are really jumping the shark. Isn't your > > Rube Goldberg "import machinery" already complex enough for you? > > Thanks for your constructive criticism, and your considerate quote > trimming. Ben, you should use google groups. No trimming necessary. -- http://mail.python.org/mailman/listinfo/python-list
Re: Cannot find text in *.py files with Windows Explorer?
On Apr 4, 12:21 am, John Doe wrote: > Anybody have a solution for Windows (XP) Explorer search not finding > ordinary text in *.py files? > > Thanks. Googling turns up this. http://www.pcmag.com/article2/0,4149,1206399,00.asp I haven't tried it myself. -- http://mail.python.org/mailman/listinfo/python-list
