Re: Thread lag
Piet van Oostrum wrote: >> Asterix (A) a écrit: > >> A> Hi, >> A> Here is a small class I use in my GTK application, to do some job in a >> A> thread.: > >> A> class ThreadInterface: >> A>def __init__(self, func, func_args, callback, callback_args): >> A> '''Call a function in a thread and then call callback''' >> A> def thread_function(func, func_args, callback, callback_args): >> A> print 'func start' >> A> output = func(*func_args) >> A> gobject.idle_add(callback, output, *callback_args) >> A> Thread(target=thread_function, args=(func, func_args, callback, >> A> callback_args)).start() >> A> print 'thread called' > >> A> Here is the way I call the class: > >> A> def decrypt_thread(encmsg, keyID): >> A># Do things >> A>return val1, val2) > >> A> def _on_message_decrypted(output, val): >> A># blabla > >> A> ThreadInterface(decrypt_thread, [encmsg, keyID], _on_message_decrypted, >> A> [val]) > > >> A> But between the time "thread called" is printed and the time "func >> A> start" is printed, there is sometimes (it vary a lot) several seconds. > >> A> How could it be? Why thread is not started instantly? How can I improve >> A> that? > > I don't know if it is related to our problem but I guess it is. > > It appears that GTK and Python threads are incompatible UNLESS you call > gtk.gdk.threads_init() before gtk.main(). This has something to do with > releasing the GIL, which gtk optimizes away if it hasn't been told that > your application uses threads. Hehe, great! That was it! Thank you -- Yann -- http://mail.python.org/mailman/listinfo/python-list
Re: [Py2exe-users] installer for py2exe files?
Gabriel Rossetti wrote: > Hello everyone, > > I am wanting to create an installer for my project. I first use py2exe > to create win32 executables and then would like to have an easy to use > (for the end user) installer. I would need the installer to launch a > script (a python script also turned into an exec) after the install is > done, or even better yet, incorperate the script's tasks in the > installation process (configure files, check for open ports, etc.). Does > anyone have an idea, recommendation or has had a similar situation before? > > Thanks! > Gabriel Have a look at NSIS, it's an opensource project -- Yann -- http://mail.python.org/mailman/listinfo/python-list
Re: Icon in a gtk.Entry
[EMAIL PROTECTED] wrote: > > Hello all, > > I have two thing I wish to accomplish, First, put an icon in a gtk.Entry as > in many search boxes. Second put a gtk.Checkbox in a gtk.ComboboxEntry. On > the later I thought I could get a handle to the Combobox tree and then add a > column and then column span column 1 back into column 0 , thus a > gtk.ToggelRender would be visible in column 0. But I had no luck getting a > handle to the Combobox tree. For the first one, look at libsexy: http://www.chipx86.com/wiki/Libsexy For using a ToggleRenderer, look at pygtk tuto: http://pygtk.org/pygtk2tutorial/sec-CellRenderers.html#sec-ActivatableToggleCells -- Yann -- http://mail.python.org/mailman/listinfo/python-list
Re: creating .pyo with make
Diez B. Roggisch wrote: > Yann Leboulanger schrieb: >> Diez B. Roggisch wrote: >>> Yann Leboulanger schrieb: >>>> Yann Leboulanger wrote: >>>>> Hi, >>>>> >>>>> I use autoconf / automake to manage my python project, and I'l like >>>>> make / make install to create / install .pyo files instead of .py >>>>> files. >>>>> >>>>> Is there something I should add to my Makefile.am files to do that? >>>>> Or should I do all that myself with py_compile module? >>>>> >>>>> Are there some examples somewhere with autotools? >>>>> >>>>> Thanks for your help >>>> >>>> Hehe replying to myself. It seems I just have to replace >>>> project_DATA = $(srcdir)/*.py >>>> by >>>> project_PYTHON = $(srcdir)/*.py >>>> >>>> Then when I do make install, it installs .py, .pyc and .pyo. >>>> Would it be possible to install only .pyo? Is it a good idea? >>> >>> There might be the occasional code that relies on doc-strings to work >>> - seldomly, but possible. Which are obmitted by .pyo, but not of pyc. >>> >>> Apart from that, having only pyc-files (or pyo for that matter) >>> sucks. Just today I had to delve into a ZOPE-application, setting >>> breakpoints and getting things done. It would have been impossible or >>> at least much more inconvenient to debug if I hadn't had the sources >>> available (and put at a place where they actually get invoked from >>> the interpreter, not lying around unrelated) >>> >>> Diez >> >> Source are available i ntarballs, but when I do make install I don't >> care to install .py files. .pyo are enough to run the application. > > As I said - not installing them will make debugging for someone who > knows how to deal with it just more inconvenient. And if you plan to > release the code anyway - don't bother separating pyc/pyo from the py. > That's a point of view I understand, but some prefer smaller installation size. Now it installs .py, .pyc, and .pyo, so 3 times bigger. -- Yann -- http://mail.python.org/mailman/listinfo/python-list
Re: creating .pyo with make
Diez B. Roggisch wrote: > Yann Leboulanger schrieb: >> Yann Leboulanger wrote: >>> Hi, >>> >>> I use autoconf / automake to manage my python project, and I'l like >>> make / make install to create / install .pyo files instead of .py files. >>> >>> Is there something I should add to my Makefile.am files to do that? >>> Or should I do all that myself with py_compile module? >>> >>> Are there some examples somewhere with autotools? >>> >>> Thanks for your help >> >> Hehe replying to myself. It seems I just have to replace >> project_DATA = $(srcdir)/*.py >> by >> project_PYTHON = $(srcdir)/*.py >> >> Then when I do make install, it installs .py, .pyc and .pyo. >> Would it be possible to install only .pyo? Is it a good idea? > > There might be the occasional code that relies on doc-strings to work - > seldomly, but possible. Which are obmitted by .pyo, but not of pyc. > > Apart from that, having only pyc-files (or pyo for that matter) sucks. > Just today I had to delve into a ZOPE-application, setting breakpoints > and getting things done. It would have been impossible or at least much > more inconvenient to debug if I hadn't had the sources available (and > put at a place where they actually get invoked from the interpreter, not > lying around unrelated) > > Diez Source are available i ntarballs, but when I do make install I don't care to install .py files. .pyo are enough to run the application. -- Yann -- http://mail.python.org/mailman/listinfo/python-list
Re: creating .pyo with make
Yann Leboulanger wrote: > Hi, > > I use autoconf / automake to manage my python project, and I'l like make > / make install to create / install .pyo files instead of .py files. > > Is there something I should add to my Makefile.am files to do that? Or > should I do all that myself with py_compile module? > > Are there some examples somewhere with autotools? > > Thanks for your help Hehe replying to myself. It seems I just have to replace project_DATA = $(srcdir)/*.py by project_PYTHON = $(srcdir)/*.py Then when I do make install, it installs .py, .pyc and .pyo. Would it be possible to install only .pyo? Is it a good idea? -- Yann -- http://mail.python.org/mailman/listinfo/python-list
creating .pyo with make
Hi, I use autoconf / automake to manage my python project, and I'l like make / make install to create / install .pyo files instead of .py files. Is there something I should add to my Makefile.am files to do that? Or should I do all that myself with py_compile module? Are there some examples somewhere with autotools? Thanks for your help -- Yann -- http://mail.python.org/mailman/listinfo/python-list
Re: PyGTK, Glade, and ComboBoxEntry.append_text()
Greg Johnston wrote: > Hey all, > > I'm a relative newbie to Python (switched over from Scheme fairly > recently) but I've been using PyGTK and Glade to create an interface, > which is a combo I'm very impressed with. > > There is, however, one thing I've been wondering about. It doesn't > seem possible to modify ComboBoxEntry choice options on the fly--at > least with append_text(), etc--because they were not created with > gtk.combo_box_entry_new_text(). Basically, I'm wondering if there's > any way around this. > > Thank you, > Greg Johnston PyGTK mailing list: http://pygtk.org/feedback.html -- http://mail.python.org/mailman/listinfo/python-list
dbus bindings under Windows
Are there any python dbus bindings under windows ? -- http://mail.python.org/mailman/listinfo/python-list
Re: os.access() under windows
Martin v. Löwis wrote: > Just in case it's not clear what Tim is getting at: > > if a folder is marked read-only on Windows, it doesn't mean > that you can only read from it. The read-only bit is a legacy > thing, anyway, since you are supposed to use ACLs to mark > a folder as read-only (by only granting write access to those > who are supposed to write) > > As the read-only bit is otherwise unused, Explorer uses it > to mark folders as being special, such a My Documents. > So by redirecting My Documents, you set the read-only bit > on the folder, causing access() to claim that write access > is not granted. > > It would be possible to fix this specific case, by always > returning True for directories; and perhaps I'll do that for > 2.5.2. > > A more general issue is whether the ACL should also be > taken into account. This would involve calling things like > OpenThreadToken, MapGenericMask, and AccessCheck. These are > all functions from the NT security API, and unavailable > on Win9x - which is the likely reason why the MS CRT did > not use them, either. Providing a proper access() implementation > for NT+ then only becomes possible for 2.6 (where W9x > is no longer supported). > Great, thanks for those information! > P.S. I would never guessed that "move My Documents to test" > doesn't mean "drag-and-drop My Documents into test", but > "redirect My Documents to the test folder". Right, sorry :/ -- Yann -- http://mail.python.org/mailman/listinfo/python-list
Re: os.access() under windows
Tim Golden a écrit : > Well, that's not the case for files: if you set your > file's readonly attribute to True, then os.access (W_OK) > will return False and you won't be able to write to the > file: > The only issue (at least, the only one we're discussing here) is: > If os.W_OK on a directory returns True, that won't stop you writing > into that directory. > > > To be precise: open () on a file within that directory doesn't fail. Yep sorry I was a bit too expeditive :) > Personally, I sympathise with you here. Python comes from a Unix > background and, unsurprisingly, it offers all the major Unix > system calls. Since Windows historically offered a Posix layer > which mapped them to *something*[1], the developers simply called > those under the covers. And the basic policy was: whatever Windows > passes back to Python, Python passes on to you. > > Later (mid-2006, I think) some or all of these Posix-layer functions > were replaced by native Win32 APIs. At that point, it arguably became > Python's responsibility to define semantics. But it's a fuzzy sort of > area. I think a doc patch which said something like: "Calls > FileGetAttribute[A|W] and compares against FILE_READONLY_ATTRIBUTE" > might meet the case, although a bit of a cop-out. > Ok thanks for all those information, I'll remove the call to os.access() on folders for windows in my application. -- Yann -- http://mail.python.org/mailman/listinfo/python-list
Re: os.access() under windows
Tim Golden a écrit : > > I'm happy to contribute a doc patch if I can imagine what > exactly to write. > "Don't use it under windows, always consider it's True"? Maybe it would be a good idea to remove support for windows for this function, or make it always return True? Current behaviour is worth that nothing, access() return False but open() doesn't fail ... -- Yann -- http://mail.python.org/mailman/listinfo/python-list
Re: os.access() under windows
Martin v. Löwis a écrit :
>> I create a folder test under e:
>>
>> then os.access('e:\\test', os.W_OK) returns True. Everything's ok.
>>
>> Now I move My Documents to this e:\test folder
>>
>> Then os.access('e:\\test', os.W_OK) returns False !!
>
> This description is, unfortunately, too imprecise to allow reproducing
> that effect. What precisely do you mean by "I move My Documents to
> this e:\test folder"?
>
I Right click on "My Documents" folder, and change the path to e:\test
there.
So that "My documents" folder points to e:\test
--
http://mail.python.org/mailman/listinfo/python-list
Re: os.access() under windows
David Tweet wrote:
> To answer indirectly, usually the EAFP (easier to ask forgiveness than
> permission) approach works better for this kind of thing.
>
> try:
> f = open('e:\\test\\test', 'a')
> f.write('abc')
> f.close()
> except IOError:
> print "couldn't write test file, continuing..."
>
> On Dec 1, 2007 1:48 AM, Yann Leboulanger <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Under Windows XP os.access has a strange behaviour:
>>
>> I create a folder test under e:
>>
>> then os.access('e:\\test', os.W_OK) returns True. Everything's ok.
>>
>> Now I move My Documents to this e:\test folder
>>
>> Then os.access('e:\\test', os.W_OK) returns False !!
>>
>> but this works:
>> f = open('e:\\test\\test', 'a')
>> f.write('abc')
>> f.close()
>>
>> So why os.access returns False ?
>>
>> --
>> Yann
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
>
yep but the test file I try to create to know if I can write there may
be a folder for exemple, and the open() will fail.
So this can be considered as a bug in os module?
--
http://mail.python.org/mailman/listinfo/python-list
os.access() under windows
Hi,
Under Windows XP os.access has a strange behaviour:
I create a folder test under e:
then os.access('e:\\test', os.W_OK) returns True. Everything's ok.
Now I move My Documents to this e:\test folder
Then os.access('e:\\test', os.W_OK) returns False !!
but this works:
f = open('e:\\test\\test', 'a')
f.write('abc')
f.close()
So why os.access returns False ?
--
Yann
--
http://mail.python.org/mailman/listinfo/python-list
