Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
Phillip J. Eby schrieb:
>At 04:33 PM 11/9/2005 -0800, Guido van Rossum wrote:
>
>
>>On 11/9/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>
>>
>>>By the way, while we're on this subject, can we make the optimization
>>>options be part of the compile() interface? Right now the distutils has to
>>>actually exec another Python process whenever you want to compile
>>>code with
>>>a different optimization level than what's currently in effect, whereas if
>>>it could pass the desired level to compile(), this wouldn't be necessary.
>>>
>>>
>>Makes sense to me; we need a patch of course.
>>
>>
>
>But before we can do that, it's not clear to me if it should be part of the
>existing "flags" argument, or whether it should be separate. Similarly,
>whether it's just going to be a level or an optimization bitmask in its own
>right might be relevant too.
>
>For the current use case, obviously, a level argument suffices, with 'None'
>meaning "whatever the command-line level was" for backward
>compatibility. And I guess we could go with that for now easily enough,
>I'd just like to know whether any of the AST or optimization mavens had
>anything they were planning in the immediate future that might affect how
>the API addition should be structured.
>
>
>
I'm using a totally different approach for the above problem. I have
implemented two functions in the sys module, that make the startup flags
accessible at runtime. This also solves some other problems I had, as
you will see in the examples below:
The first function makes most of the flags readable (I have ommited the
flags, that are documented as deprecated in the code):
sys.getrunflag(name) -> integer
Return one of the interpreter run flags. Possible names are 'Optimize',
'Verbose', 'Interactive', 'IgnoreEnvironment', 'Debug',
'DivisionWarning', 'NoSite', 'NoZipImport', 'UseClassExceptions',
'Unicode', 'Frozen', 'Tabcheck'. getrunflag('Optimize') for example
returns the current value of Py_OptimizeFlag.
The second function makes a few flags writable:
sys.setrunflag(name, value) -> integer
Set an interpreter run flag. The only flags that can be changed at
runtime are Py_VerboseFlag ('Verbose') and Py_OptimizeFlag ('Optimize').
Returns the previous value of the flag.
As you can see, I have also introduced the new flag Py_NoZipImport that
can be activated with -Z at startup. This bypasses the activation of
zipimport and is very handy, if you edit modules stored in the
filesystem, that are normally imported from a zip archive and you want
to test your modifications. With this flag, there is no need to delete,
rename or update the zip archive or to modify sys.path to ensure that
your changed modules are imported from the filesystem and not from the
zip archive.
And here are a few usable examples for the new functions:
1.) You have an application, that does a huge amount of imports and
some of them are mysterious, so you want to track them in verbose mode.
You could start python with -v or -vv, but then you get hundreds or
thousands of lines of output. Instead, you can do the following:
import sys
import ...
import ...
oldval = sys.setrunflag('Verbose', 1) # -v, use 2 for -vv
import ...
import ...
sys.setrunflag('Verbose', oldval)
import ...
import ...
Now, you get only verbose messages for the imports that you want to track.
2.) You need to generate optimized byte code (without assertions and
docstrings) from a source code, no matter how the interpreter was started:
import sys
...
source = ...
oldval = sys.setrunflag('Optimize', 2) # -OO, use 1 for -O
bytecode = compile(source, ...)
sys.setrunflag('Optimize', oldval)
...
3.) You have to build a command line for the running application (e.g.
for registration in the registry) and need to check, if you are running
a script or a frozen executable (this assumes, that your freeze tool
sets the Py_FrozenFlag):
import sys
...
if sys.getrunflag('Frozen'):
commandline = sys.executable
else:
commandline = '%s %s' % (sys.executable, sys.argv[0])
...
NOTE: My own freeze tool sib.py, which is part of the VendorID package
(www.riverbankcomputing.co.uk/vendorid) doesn't set the Py_FrozenFlag
yet. I will provide an update soon.
And now back to the original subject:
I have done nearly the same changes, that Osvaldo provided with his
patch and I would highly appreciate if this patch goes into the next
release. The main reason why I changed the import behavior was
pythonservice.exe from the win32 extensions. pythonservice.exe imports
the module that contains the service class, but because
pythonservice.exe doesn't run in optimized mode, it will only import a
.py or a .pyc file, not a .pyo file. Because we always generate bytecode
with -OO at distribution time, we either had to change the behavior of
pythonservice.exe or change the import behavior of Python.
It is essential for us to remove assertions and docstrings in our
commercial Python appl
[Python-Dev] Inconsistent behaviour in import/zipimport hooks
Ulrich Berning schrieb: [He already has a patch that does much of what is being discussed] > I have also introduced the new flag Py_NoZipImport that > can be activated with -Z at startup. This bypasses the > activation of zipimport I think -Z could be confusing; I would expect it to work more like the recent suggestion that it name a specific Zip file to use as the only (or at least the first) source of modules. I do see that the switch is handy; I'm just suggesting a different name, such as -nozip or -skip file.zip. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Event loops, PyOS_InputHook, and Tkinter - Summary attempt
There has been enough misunderstanding in this thread that the summarizers are going to have trouble. So I'm posting this draft in hopes of clarification; please correct me. (1) There is some pre-discussion attached to patches 1049855 and 1252236. Martin Loewis and Michiel de Hoon agreed that the fixes were fragile, and that a larger change should be discussed on python-dev. (2) Michiel writes visualization software; he (and others, such as the writers of matplotlib) has trouble creating a good event loop, because the GUI toolkit (especially Tkinter?) wants its own event loop to be in charge. Note that this isn't the first time this sort of problem has come up; usually it is phrased in terms of a problem with Tix, or not being able to run turtle while in IDLE. Event loops by their very nature are infinite loops; once they start, everything else is out of luck unless it gets triggered by an event or is already started. (3) Donovan Baarda suggested looking at Twisted for state of the art in event loop integration. Unfortunately, as Phillip Eby notes, it works by not using the Tkinter event loop. It decides for itself when to call dooneevent. (4) Michiel doesn't actually need Tkinter (or any other GUI framework?) for his own project, but he has to play nice with it because his users expect to be able to use other tools -- particularly IDLE -- while running his software. (5) It is possible to run Tkinter's dooneevent version as part of your own event loop (as Twisted does), but you can't really listen for its events, so you end up with a busy loop polling, and stepping into lots of "I have nothing to do" functions for every client eventloop. You can use Tkinter's loop, but once it goes to sleep waiting for input, everything sort of stalls out for a while, and even non-Tkinter events get queued instead of processed. (6) Mark Hammond suggests that it might be easier to replace the interactive portions of python based on the "code" module. matplotlib suggests using ipython instead of standard python for similar reasons. If that is really the simplest answer (and telling users which IDE to use is acceptable), then ... I think Michiel has a point. (7) One option might be to always start Tk in a new thread, rather than letting it take over the main thread. There was some concern (see patch 1049855) that Tkinter doesn't -- and shouldn't -- require threading. My thoughts are that some of the biggest problems with the event loop (waiting on a mutex) won't happen in non-threaded python, and that even dummy_thread would be an improvement over the current state (by forcing the event loop to start last). I may well be missing something, but obviously I'm not sure what that is. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
On 11/11/05, Ulrich Berning <[EMAIL PROTECTED]> wrote: > Guido, if it was intentional to separate slightly different generated > bytecode into different files and if you have good reasons for doing > this, why have I never seen a .pyoo file :-) Because -OO was an afterthought and not implemented by me. > For instance, nobody would give the output of a C compiler a different > extension when different compiler flags are used. But the usage is completely different. With C you explicitly manage when compilation happens. With Python you don't. When you first run your program with -O but it crashes, and then you run it again without -O to enable assertions, you would be very unhappy if the bytecode cached in a .pyo file would be reused! > I would appreciate to see the generation of .pyo files completely > removed in the next release. You seem to forget the realities of backwards compatibility. While there are ways to cache bytecode without having multiple extensions, we probably can't do that until Python 3.0. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter - Summary attempt
I think this is an excellent summary of the discussion so far. Probably clearer than my own posts. Thanks, Jim! --Michiel. Jim Jewett wrote: >There has been enough misunderstanding in this thread >that the summarizers are going to have trouble. So I'm >posting this draft in hopes of clarification; please correct >me. > >(1) There is some pre-discussion attached to patches >1049855 and 1252236. Martin Loewis and Michiel >de Hoon agreed that the fixes were fragile, and that a >larger change should be discussed on python-dev. > >(2) Michiel writes visualization software; he (and >others, such as the writers of matplotlib) has trouble >creating a good event loop, because the GUI toolkit >(especially Tkinter?) wants its own event loop to be in >charge. > >Note that this isn't the first time this sort of problem has >come up; usually it is phrased in terms of a problem with >Tix, or not being able to run turtle while in IDLE. > >Event loops by their very nature are infinite loops; >once they start, everything else is out of luck unless it >gets triggered by an event or is already started. > >(3) Donovan Baarda suggested looking at Twisted for >state of the art in event loop integration. Unfortunately, >as Phillip Eby notes, it works by not using the Tkinter >event loop. It decides for itself when to call dooneevent. > >(4) Michiel doesn't actually need Tkinter (or any other GUI >framework?) for his own project, but he has to play nice >with it because his users expect to be able to use other >tools -- particularly IDLE -- while running his software. > >(5) It is possible to run Tkinter's dooneevent version >as part of your own event loop (as Twisted does), but >you can't really listen for its events, so you end up with >a busy loop polling, and stepping into lots of "I have >nothing to do" functions for every client eventloop. > >You can use Tkinter's loop, but once it goes to sleep >waiting for input, everything sort of stalls out for a while, >and even non-Tkinter events get queued instead of >processed. > >(6) Mark Hammond suggests that it might be easier to >replace the interactive portions of python based on the >"code" module. matplotlib suggests using ipython >instead of standard python for similar reasons. > >If that is really the simplest answer (and telling users >which IDE to use is acceptable), then ... I think Michiel >has a point. > >(7) One option might be to always start Tk in a new >thread, rather than letting it take over the main thread. > >There was some concern (see patch 1049855) that >Tkinter doesn't -- and shouldn't -- require threading. > >My thoughts are that some of the biggest problems >with the event loop (waiting on a mutex) won't happen >in non-threaded python, and that even dummy_thread >would be an improvement over the current state (by >forcing the event loop to start last). I may well be >missing something, but obviously I'm not sure what that is. > >-jJ >___ >Python-Dev mailing list >[email protected] >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/mdehoon%40c2b2.columbia.edu > > -- Michiel de Hoon Center for Computational Biology and Bioinformatics Columbia University 1150 St Nicholas Avenue New York, NY 10032 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Martin v. Löwis wrote: >Before trying to explain the reason, please try to explain the >problem first. What is it *really* that you want to do which >you feel you currently can't do? > > Probably I should have started the discussion with this; sorry if I confused everybody. But here it is: 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 make sure that its events get handled. So I need an event loop. At the same time, the user can enter new Python commands, which also need to be handled. To achieve this, I make use of PyOS_InputHook, a pointer to a function which gets called just before going into fgets to read the next Python command. I use PyOS_InputHook to enter an event loop inside my extension module. This event loop handles the window events, and returns as soon as a new Python command is available at stdin, at which point we continue to fgets as usual. While this approach more or less works, there are two problems that I have run into: 1) What if the user decides to import Tkinter next? Tkinter notices that PyOS_InputHook is already set, and does not reset it to its own event loop. Hence, Tkinter's events are not handled. Similarly, if a user imports Tkinter before my extension module, I don't reset PyOS_InputHook, so Tkinter's events are handled but not mine. If I were to reset PyOS_InputHook to my extension module's event loop, then my events get handled but not Tkinter's. 2) On Windows, many users will use IDLE to run Python. IDLE uses two Python threads, one for the GUI and one for the user's Python commands. Each has its own PyOS_InputHook. If I import my extension module (or Tkinter, for that matter), the user-Python's PyOS_InputHook gets set to the corresponding event loop function. So far so good. However, PyOS_InputHook doesn't actually get called: Between Python commands, the GUI-Python is waiting for the user to type something, and the user-Python is waiting for the GUI-Python. While the user-Python is waiting for the GUI-Python thread, no call is made to PyOS_InputHook, therefore we don't enter an event loop, and no events get handled. Hence, neither my extension module nor Tkinter work when run from IDLE. --Michiel. -- Michiel de Hoon Center for Computational Biology and Bioinformatics Columbia University 1150 St Nicholas Avenue New York, NY 10032 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter - Summary attempt
Jim Jewett wrote: > (6) Mark Hammond suggests that it might be easier to > replace the interactive portions of python based on the > "code" module. matplotlib suggests using ipython > instead of standard python for similar reasons. > > If that is really the simplest answer (and telling users > which IDE to use is acceptable), then ... I think Michiel > has a point. really? Python comes with a module that makes it trivial to get a fully working interpreter console under any kind of UI toolkit with very little effort, and you think that proves that we need to reengineer the CPython interpreter to support arbitary event loops so you don't have to use that module? as usual, you make absolutely no sense whatsoever. (or was "..." short for "CPython's interactive mode should use the code module" ?) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Event loops, PyOS_InputHook, and Tkinter
>> (6) Mark Hammond suggests that it might be easier to >> replace the interactive portions of python based on the >> "code" module. matplotlib suggests using ipython >> instead of standard python for similar reasons. >> If that is really the simplest answer (and telling users >> which IDE to use is acceptable), then ... I think Michiel >> has a point. Fredrik Lundh wrote: > really? Python comes with a module that makes it trivial to get > a fully working interpreter console ... Using an event loop (or an external GUI) should not require forking the entire interactive mode, no matter how trivial that fork is. The subtle differences between interactive mode and IDLE already cause occasional problems; the same would be true of code.interact() if it were more widely used. Part of Michiel's pain is that users want to make their own decisions on whether to use IDLE or emacs or vt100, and they want to mix and match toolkits. They already run into unexpected freezes because of the event loop conflicts. If every extension writer also relied on their own subclasses of the interactive mode, users would be in for far more unpleasant surprises. The right answer might be to run each event loop in a separate thread. The answer might be to have a python event loop that re-dispatches single events to the other frameworks. The answer might be a way to chain PyOS_InputHook functions like atexit does for shutdown functions. The answer might be something else entirely. But I'm pretty sure that the right answer does not involve adding an additional layer of potential incompatibility. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Jim Jewett wrote: > > really? Python comes with a module that makes it trivial to get > > a fully working interpreter console ... > > Using an event loop (or an external GUI) should not require > forking the entire interactive mode, no matter how trivial that > fork is. repeating a bogus argument doesn't make it any better. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
Michiel> 1) What if the user decides to import Tkinter next? Tkinter Michiel>notices that PyOS_InputHook is already set, and does not Michiel>reset it to its own event loop. Hence, Tkinter's events are Michiel>not handled. Similarly, if a user imports Tkinter before my Michiel>extension module, I don't reset PyOS_InputHook, so Tkinter's Michiel>events are handled but not mine. If I were to reset Michiel>PyOS_InputHook to my extension module's event loop, then my Michiel>events get handled but not Tkinter's. This sounds sort of like the situation that existed with sys.exitfunc before the creation of the atexit module. Can't we develop an API similar to that so that many different event-loop-wanting packages can play nice together? (Then again, maybe I'm just being too simpleminded.) Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] indented longstrings?
Python's longstring facility is very useful, but unhappily breaks
indentation. I find myself writing code like
msg = ('From: %s\r\n'
+ 'To: %s\r\n'
+ 'Subject: Host failure report for %s\r\n'
+ 'Date: %s\r\n'
+ '\r\n'
+ '%s\r\n') % (fr, ', '.join(to), host, time.ctime(), err)
mail.sendmail(fr, to, msg)
instead of
msg = ('''From: %s
To: %s
Subject: Host failure report for %s
Date: %s
%s
''') % (fr, ', '.join(to), host, time.ctime(), err)
mail.sendmail(fr, to, msg)
while wishing for a
msg = i'''From: %s
To: %s\r\n'
Subject: Host failure report for %s
Date: %s
%s
''' % (fr, ', '.join(to), host, time.ctime(), err)
mail.sendmail(fr, to, msg.replace('\n', '\r\n'))
isn't it so much prettier?
(((an indented longstring, i''' ... ''' behaves like a regular
longstring except that indentation on the lines following the beginning
of the longstring is stripped up to the first character position of the
longstring on the first line. non-blanks before that character position
are a syntax error)))
Avi
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] (no subject)
> > >Mixing Decimal and float is nearly ALWAYS a user error. Doing it correctly >requires significant expertise in the peculiarities of floating point >representations. > So that I think user should declare floats explicitly (###.###f) - he will fall into float space only if he wish it. >So Python protects the user by throwing exceptions when >attempts are made to mix Decimal and floats. I hate it. I want to get float when I wish to get float. In that case i would like to write #f. I want to stay with decimals by default. (and I want decimals written in C) But it just an opinion of young inexperienced/unpractised man. Excuse my English. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] indented longstrings?
Avi> Python's longstring facility is very useful, but unhappily breaks
Avi> indentation. I find myself writing code like
Avi> msg = ('From: %s\r\n'
Avi>+ 'To: %s\r\n'
Avi>+ 'Subject: Host failure report for %s\r\n'
Avi>+ 'Date: %s\r\n'
Avi>+ '\r\n'
Avi>+ '%s\r\n') % (fr, ', '.join(to), host, time.ctime(), err)
Avi> mail.sendmail(fr, to, msg)
This really belongs on comp.lang.python, at least until you've exhausted the
existing possibilities and found them lacking. However, try:
msg = ('From: %s\r\n'
'To: %s\r\n'
'Subject: Host failure report for %s\r\n'
'Date: %s\r\n'
'\r\n'
'%s\r\n') % (fr, ', '.join(to), host, time.ctime(), err)
or
msg = ('''\
From: %s
To: %s
Subject: Host failure report for %s
Date: %s
%s
') % (fr, ', '.join(to), host, time.ctime(), err)
or (untested)
def istring(s):
return re.sub(r"(\r?\n)\s+", r"\1", s)
msg = """From: %s
To: %s
Subject: Host failure report for %s
Date: %s
%s
"""
msg = istring(msg) % (fr, ', '.join(to), host, time.ctime(), err)
Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Weak references: dereference notification
Gustavo J. A. M. Carneiro wrote: > The object isn't really destroyed. Simply ob_refcnt drops to zero, > then tp_dealloc is called, which is supposed to destroy it. But since I > wrote tp_dealloc, I choose not to destroy it, Be aware that a C subclass of your wrapper that overrides tp_dealloc is going to have its tp_dealloc called before yours, and will therefore be partly destroyed before you get control. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] indented longstrings?
On Nov 10, 2005, at 1:26 AM, Avi Kivity wrote: > Python's longstring facility is very useful, but unhappily breaks > indentation. I find myself writing code like http://docs.python.org/lib/module-textwrap.html -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent behaviour in import/zipimport hooks
Hi (first post here, note that English is not my native language), One thing we shoudn't forgot is that Osvaldo is porting Python to a plataform that has not so much disk space. He needs Python modules with just the essencial. I like ideias like __debug__ opcode, but in Osvaldo use case, there are limitations to expanding a Python module size. What the problem for the interpreter looks for both .pyc and .pyo? I believe zipimport way to lookup modules is more useful. -- Até mais.. João Paulo da Silva LinuxUser #355914 ICQ: 265770691 | Jabber: [EMAIL PROTECTED] PS: Guido, sorry the PVT... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
[EMAIL PROTECTED] wrote: > This sounds sort of like the situation that existed with sys.exitfunc before > the creation of the atexit module. Can't we develop an API similar to that > so that many different event-loop-wanting packages can play nice together? I can't see how that would help. If the different hooks know nothing about each other, there's no way for one to know when to give up control to the next one in the chain. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
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 your own? > For the graphics windows to remain responsive, I need to make sure that > its events get handled. So I need an event loop. How about running your event loop in a separate thread? Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
>> This sounds sort of like the situation that existed with sys.exitfunc >> before the creation of the atexit module. Can't we develop an API >> similar to that so that many different event-loop-wanting packages >> can play nice together? Greg> I can't see how that would help. If the different hooks know Greg> nothing about each other, there's no way for one to know when to Greg> give up control to the next one in the chain. 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. Then you have a uniform way to control event-driven applications. Today, a package like Michiel's has no idea what sort of event loop it will encounter. If Python provided the event loop API it would be the same no matter what widget set happened to be used. The sticking point is probably that a number of such packages presume they will always provide the main event loop and have to way to feed their sockets to another event loop controller. That might present some hurdles for the various package writers/Python wrappers. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
