Josiah Carlson wrote:
> Or heck, if you are really lazy, people can use a plot() calls, but
> until an update_plot() is called, the plot isn't updated.
I really recommend that those interested in all these issues have a look at
matplotlib. All of this has been dealt with there already, a long ti
Michiel Jan Laurens de Hoon wrote:
>>Yes, you can. Actually, Tkinter *always* runs in a separate thread
>>(separate from all other threads).
>>
> Are you sure? If Tkinter is running in a separate thread, then why does
> it need PyOS_InputHook?
Well, my statement was (somewhat deliberately) misl
Brett Cannon wrote:
> On 11/13/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Thomas Lee wrote:
>>> Implemented as you suggested and tested. I'll submit the patch to the
>>> tracker on sourceforge shortly. Are you guys still after contextual
>>> diffs as per the developer pages, or is an svn diff t
I personally like Edward Loper's idea of just running your own event
handler which deals with drawing, suspend/resume, etc...
> If, however, Python contains an event loop that takes care of events as
> well as Python commands, redrawing won't happen until Python has
> executed all plot commands
On 14-nov-2005, at 2:20, Michiel Jan Laurens de Hoon wrote:
> [EMAIL PROTECTED] wrote:
>
>> If I have a Gtk app I have to feed other (socket, callback) pairs
>> to it. It
>> takes care of adding it to the select() call. Python could
>> dictate that the
>> way to play ball is for other packa
As I understand it, you want to improve the performance of interactively
run plot commands by queuing up all the plot sub-commands, and then
drawing them all at once. Hooking into a python event loop certainly
isn't the only way to do this. Perhaps you could consider the following
approach:
Michiel Jan Laurens de Hoon wrote:
> Fernando Perez wrote:
>>Did you read my reply? ipython, based on code.py, implements a few simple
>>threading tricks (they _are_ simple, since I know next to nothing about
>>threading) and gives you interactive use of PyGTK, WXPython and PyQt
>>applications in
On Nov 13, 2005, at 8:07 PM, Greg Ewing wrote:
> Ian Bicking wrote:
>
>
>> I think a better argument for this is that dedenting a literal
>> string is
>> more of a syntactic operation than a functional one. You don't think
>> "oh, I bet I'll need to do some dedenting on line 200 of this
>> m
Fernando Perez wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>For an extension module such as
>>PyGtk, the developers may decide that PyGtk is likely to be run in
>>non-interactive mode only, for which the PyGtk mainloop is sufficient.
>>
>>
>
>Did you read my reply? ipython, based on code
Greg Ewing wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>Greg Ewing wrote:
>>
>>
>>>How about running your event loop in a separate thread?
>>>
>>>
>>I agree that this works for some extension modules, but not very well
>>for extension modules for which graphical performance is cri
Michiel Jan Laurens de Hoon wrote:
> For an extension module such as
> PyGtk, the developers may decide that PyGtk is likely to be run in
> non-interactive mode only, for which the PyGtk mainloop is sufficient.
Did you read my reply? ipython, based on code.py, implements a few simple
threading tr
Martin v. Löwis wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>But there is another solution with threads: Can we let Tkinter run in a
>>separate thread instead?
>>
>>
>
>Yes, you can. Actually, Tkinter *always* runs in a separate thread
>(separate from all other threads).
>
>
Are you
Noam Raphael wrote:
> On 11/13/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > Noam Raphael wrote:
> >
> > > callback". Then, when the interpreter is idle, it will call all the
> > > registered callbacks, one at a time, and everyone would be happy.
> >
> > Except for those who don't like busy wait
Noam Raphael wrote:
>On 11/13/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>
>>Noam Raphael wrote:
>>
>>
>>>All that is needed to make Tkinter and Michiels'
>>>code run together is a way to say "add this callback to the input
>>>hook" instead of the current "replace the current input hook wit
Michiel Jan Laurens de Hoon wrote:
> Greg Ewing wrote:
>
> > How about running your event loop in a separate thread?
>
> I agree that this works for some extension modules, but not very well
> for extension modules for which graphical performance is critical
I don't understand. If the main thre
[EMAIL PROTECTED] wrote:
>If I have a Gtk app I have to feed other (socket, callback) pairs to it. It
>takes care of adding it to the select() call. Python could dictate that the
>way to play ball is for other packages (Tkinter, PyGtk, wxPython, etc) to
>feed Python the (socket, callback) pair.
Ian Bicking wrote:
> I think a better argument for this is that dedenting a literal string is
> more of a syntactic operation than a functional one. You don't think
> "oh, I bet I'll need to do some dedenting on line 200 of this module, I
> better import textwrap".
And regardless of the need to
Greg Ewing wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>I have an extension module for scientific visualization. This extension
>>module opens one or more windows, in which plots can be made.
>>
>>
>
>What sort of windows are these? Are you using an existing
>GUI toolkit, or rolling you
Martin v. Löwis wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>The problem with threading (apart from potential portability problems)
>>is that Python doesn't let us know when it's idle. This would cause
>>excessive repainting (I can give you an explicit example if you're
>>interested).
>>
On 11/13/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Thomas Lee wrote:
> > Implemented as you suggested and tested. I'll submit the patch to the
> > tracker on sourceforge shortly. Are you guys still after contextual
> > diffs as per the developer pages, or is an svn diff the preferred way to
> >
Martin v. Löwis:
> The problem (for me, atleast) is that VC is so much more convenient to
> work with.
In my experience Visual C++ has always produced faster, more
compact code than Mingw. While this may not be true with current
releases, I'd want to ensure that the normal Python download for
There's still more clean up work to go, but the current AST is
hopefully much closer to the behaviour before it was checked in.
There are still a few small memory leaks.
After running the test suite, the total references were around 380k
(down from over 1,000k). I'm not sure exactly what the tot
> You are missing a point here: string methods were introduced
> to make switching from plain 8-bit strings to Unicode easier.
Is it the only purpose ?
I agree with the OP that using string methods is much nicer and more
convenient than having to import separate modules.
Especially, it is nice to
Noam Raphael wrote:
> Following Avi's suggestion, can I raise this thread up again? I think
> that Reinhold's .dedent() method can be a good idea after all.
>
> The idea is to add a method called "dedent" to strings. It would do
> exactly what the current textwrap.indent function does.
You are m
Thomas Lee wrote:
> Implemented as you suggested and tested. I'll submit the patch to the
> tracker on sourceforge shortly. Are you guys still after contextual
> diffs as per the developer pages, or is an svn diff the preferred way to
> submit patches now?
svn diff should be fine. Although I th
Martin v. Löwis wrote:
> [EMAIL PROTECTED] wrote:
>> Martin> I would also recommend to throw away the sandbox completely and
>> Martin> check it out from scratch. Please report whether this gives you
>> Martin> code.h.
>>
>> Yes, it does (still with my built-from-source 1.2.3).
>
> Ok.
Raymond Hettinger wrote:
> That is somewhat misleading. We already have that ability. What is
> being proposed is moving existing code to a different namespace. So the
> motivation is really something like:
>
>I want to write
>s = s.dedent()
>because it is too painful to write
Mark Hammond wrote:
> : Currently, event loops are available in Python via PyOS_InputHook, a
> : pointer to a user-defined function that is called when Python is idle
> : (waiting for user input). However, an event loop using PyOS_InputHook
> : has some inherent limitations, so I am thinking about
Michiel Jan Laurens de Hoon wrote:
> I have an extension module for scientific visualization. This extension
> module opens one or more windows, in which plots can be made. Something
> similar to the plotting capabilities of Matlab.
>
> For the graphics windows to remain responsive, I need to ma
[EMAIL PROTECTED] wrote:
> Martin> code.h should live in Include. It was originally committed to
> Martin> CVS, so it is in the subversion repository from day one; it
> Martin> should always have been there since you started using
> Martin> subversion.
>
> Sorry, I had some strange
John> Output of the svnversion command? That shows switched and locally
John> modified files, etc.
John> I'm not an svn guru, but I find that command useful, especially to
John> point out when I switched some deep directory then forgot about
John> it.
Thanks, I'll remember i
Martin> code.h should live in Include. It was originally committed to
Martin> CVS, so it is in the subversion repository from day one; it
Martin> should always have been there since you started using
Martin> subversion.
Sorry, I had some strange idea it was new with the ast branch
On Sat, 12 Nov 2005 [EMAIL PROTECTED] wrote:
[...]
> Before I wipe out Include and svn up again is there any debugging I can do
> for someone smarter in the ways of Subversion than me? Regarding my
[...]
Output of the svnversion command? That shows switched and locally
modified files, etc.
I'm
>> ../Objects/frameobject.c:6:18: code.h: No such file or directory
>>
>> Sure enough, I have no code.h in my Include directory.
Fredrik> what does
Fredrik> svn status Include/code.h
Fredrik> say? if it says
It reports nothing.
Fredrik> doing a full
Fred
Thomas Lee wrote:
> Hi all,
>
> I've been using Python for a few years and, as of a few days ago,
> finally decided to put the effort into contributing code back to the
> project.
>
> I'm attempting to implement PEP 341 (unification of try/except and
> try/finally) against HEAD. However, this
Hi all,
I've been using Python for a few years and, as of a few days ago,
finally decided to put the effort into contributing code back to the
project.
I'm attempting to implement PEP 341 (unification of try/except and
try/finally) against HEAD. However, this being my first attempt at a
chang
[EMAIL PROTECTED] wrote:
> Is there some magic required to check out new files from the repository?
> I'm trying to build on the trunk and am getting compilation errors about
> code.h not being found. If I remember correctly, this is a new file brought
> over from the ast branch. Using cvs I woul
[EMAIL PROTECTED] wrote:
> I read the developer's FAQ and the output of "svn up --help". Executing
> "svn up" or "svn info" tells me I'm already at rev 41430, which is the
> latest rev, right? Creating a fresh build subdirectory followed by
> configure and make gives me this error:
>
>../Obj
> Sorry, I didn't mean to mislead. I wrote "easily" - I guess using the
> current textwrap.dedent isn't really hard, but still, writing:
>
> import textwrap
>
>
> r = some_func(textwrap.dedent('''\
> line1
> line2'''))
>
39 matches
Mail list logo
