[Python-Dev] OT pet peeve (was: Re: str.dedent)
> 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'''))
>
> Seems harder to me than simply
>
> r = some_func('''\
> line1
> line2'''.dedent())
>
> This example brings up another reason why "dedent" us a method is a
> good idea: It is a common convention to indent things according to the
> last opening bracket. "dedent" as a function makes the indentation
> grow in at least 7 characters, and in 16 characters if you don't do
> "from textwrap import dedent".
It's a common convention, but a rather ugly one. It makes harder breaking
lines at 78-80 chars, and using long enough identifiers.
I find it more useful to go straight to the next line, indenting the usual
four spaces (and also separating nested stuff):
r = some_func(
textwrap.dedent(
'''\
line1
line2'''))
This style uses up more vertical space, but I find it also gives code a
clearer overall shape.
--
Nicola Larosa - [EMAIL PROTECTED]
Use of threads can be very deceptive. [...] in almost all cases they
also make debugging, testing, and maintenance vastly more difficult
and sometimes impossible.
http://java.sun.com/products/jfc/tsc/articles/threads/threads1.html#why
___
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] Is some magic required to check out new files from svn?
[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: > >../Objects/frameobject.c:6:18: code.h: No such file or directory > > Sure enough, I have no code.h in my Include directory. what does svn status Include/code.h say? if it says !Include/code.h what happens if you do svn revert Include/code.h ? doing a full svn status and looking for ! entries will tell you if more files are missing. ___ 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] Is some magic required to check out new files from svn?
[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 would have executed something like > "cvs up -dPA ." if I found I was missing something (usually a new directory) > and wanted to make sure I was in sync with the trunk. code.h should live in Include. It was originally committed to CVS, so it is in the subversion repository from day one; it should always have been there since you started using subversion. Do you have code.h mentioned in Include/.svn/entries? > This is getting kinda frustrating. I haven't got a lot of confidence in > Subversion at this point. I can understand that. However, you should get confidence from that fact that nobody else is seeing these problems :-) I recommend to use pre-built binaries, e.g. the ones from http://metissian.com/projects/macosx/subversion/ I would also recommend to throw away the sandbox completely and check it out from scratch. Please report whether this gives you code.h. Regards, Martin ___ 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] Implementation of PEP 341
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 change to the syntax there's been a bit of a learning curve. I've modified Grammar/Grammer to use the new try_stmt grammar, updated Parser/Python.asdl to accept a stmt* finalbody for TryExcept instances and modified Python/ast.c to handle the changes to Python.asdl - generating an AST for the finalbody. All that remains as far as I can see is to modify Python/compile.c to generate the necessary code and update Modules/parsermodule.c to accommodate the changes to the grammar. (If anybody has further input as to what needs to be done here, I'm all ears!) The difficulty I'm having is in Python/compile.c: currently there are two functions which generate the code for the two existing try_stmt paths. compiler_try_finally doesn't need any changes as far as I can see. compiler_try_except, however, now needs to generate code to handle TryExcept.finalbody (which I added to Parser/Python.asdl). This sounds easy enough, but the following is causing me difficulty: /* BEGIN */ ADDOP_JREL(c, SETUP_EXCEPT, except); compiler_use_next_block(c, body); if (!compiler_push_fblock(c, EXCEPT, body)) return 0; VISIT_SEQ(c, stmt, s->v.TryExcept.body); ADDOP(c, POP_BLOCK); compiler_pop_fblock(c, EXCEPT, body); /* END */ A couple of things confuse me here: 1. What's the purpose of the push_fblock/pop_fblock calls? 2. Do I need to add "ADDOP_JREL(c, SETUP_FINALLY, end);" before/after SETUP_EXCEPT? Or will this conflict with the SETUP_EXCEPT op? I don't know enough about the internals of SETUP_EXCEPT/SETUP_FINALLY to know what to do here. Also, in compiler_try_finally we see this code: /* BEGIN */ ADDOP_JREL(c, SETUP_FINALLY, end); compiler_use_next_block(c, body); if (!compiler_push_fblock(c, FINALLY_TRY, body)) return 0; VISIT_SEQ(c, stmt, s->v.TryFinally.body); ADDOP(c, POP_BLOCK); compiler_pop_fblock(c, FINALLY_TRY, body); ADDOP_O(c, LOAD_CONST, Py_None, consts); /* END */ Why the LOAD_CONST Py_None? Does this serve any purpose? some sort of weird pseudo return value? Or does it have a semantic purpose that I'll have to reproduce in compiler_try_except? Cheers, and thanks for any help you can provide :) Tom ___ 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] Implementation of PEP 341
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 being my first attempt at a > change to the syntax there's been a bit of a learning curve. Thanks for having a go at this. > I've modified Grammar/Grammer to use the new try_stmt grammar, updated > Parser/Python.asdl to accept a stmt* finalbody for TryExcept instances > and modified Python/ast.c to handle the changes to Python.asdl - > generating an AST for the finalbody. Consider leaving the AST definition alone, and simply changing the frontend parser to process: try: BLOCK1 except: BLOCK2 finally: BLOCK3 almost precisely as if it were written: try: try: BLOCK1 except: BLOCK2 finally: BLOCK3 That is, generate a TryExcept inside a TryFinally at the AST level, rather than trying to give TryExcept the ability to handle a finally block directly. Specifically, if you've determined that a finally clause is present in the extended statement in Python/ast.c, do something like: inner_seq = asdl_seq_new(1) asdl_seq_SET(inner_seq, 0, TryExcept(body_seq, handlers, else_seq, LINENO(n)) return TryFinally(inner_seq, finally_seq, LINENO(n)) body_seq and else_seq actually have meaningful names like suite_seq1 and suite_seq2 in the current code ;) Semantics-wise, this is exactly the behaviour we want, and making it pure syntactic sugar means the backend doesn't need to care about the new syntax at all. It also significantly lessens the risk of the change causing any problems in the compilation of normal try-except blocks. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] Is some magic required to check out new files from svn?
>> ../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 Fredrik> svn status Fredrik> and looking for ! entries will tell you if more files are missing. The full svn status output is % svn status ! . ! Python Just for the heck of it, I tried "svn revert Include/code.h" and got Skipped 'Include/code.h' code.h is not mentioned in Include/.svn/entries. 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] Is some magic required to check out new files from svn?
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 not an svn guru, but I find that command useful, especially to point out when I switched some deep directory then forgot about it. John ___ 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] Is some magic required to check out new files from svn?
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. Martin> Do you have code.h mentioned in Include/.svn/entries? Nope. Martin> I recommend to use pre-built binaries, e.g. the ones from Martin> http://metissian.com/projects/macosx/subversion/ That was where I got the 1.2.0 version I was having trouble with originally. I built 1.2.3 from source. I'll give the prebuilt 1.2.3 a try. 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). 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] Is some magic required to check out new files from svn?
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 it for next time... 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] Is some magic required to check out new files from svn?
[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 idea it was new with the ast branch. It was, yes. However, the conversion to subversion happened after the ast branch was checked in. > 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. I am now convinced (also because of the other information you reported) that you indeed had continued to use one of the test conversion repositories from before the switchover. That would explain all the problems you see. Regards, Martin ___ 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. 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. My recommendation: create a thread for the graphics window, which runs the event loop of the graphics window. That way, you are completely independent of any other event loops that may happen. It is also independent of the operating system (as long as the thread module is available). Regards, Martin ___ 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
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 how to improve > : event loop support in Python. > > Either we have an unusual definition of "event loop" (as many many other > toolkits have implemented event loops without PyOS_InputHook), or the > requirement is for an event loop that plays nicely with the "interactive > loop" in Python.exe. I would guess there is an unusual definition of an "event loop". It is probably that inside the hook, a "process_some_events()" function is invoked, which loops until some event queue is empty; this is not the usual infinite-loop-until-user-terminates-program. For this to work, you need a guarantee that the hook is invoked frequently. Again, I still think running the loop (as a true event loop) in a separate thread would probably solve the problem. Regards, Martin ___ 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] str.dedent
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 >s = textwrap.dedent(s) >From technical point of view, there is nothing wrong with placing this functionality in textwrap. But from usability point of view using textwrap.dedent is like importing some stuff for doing string concatenation or integer addition. In textwrap module this function placed in section "Loosely (!) related functionality". When Python beginner try to find "Pythonic" way for dealing with dedenting (And she know, in Python "there should be one -- and preferably only one -- obvious way to do it"), it is very unlikely that she think "Which module may contain standard string dedenting? Yes, of course textwrap! I'm sure I'll find necessary function there!" > String methods should be limited to generic string manipulations. > String applications should be in other namespaces. That is why we don't > have str.md5(), str.crc32(), str.ziplib(), etc. I think, dedenting must be classified as "generic string manipulations". The need in string dedenting results from meaningful indentation and widespread use of text editors with folding support. Multiline strings without leading whitespaces breaks correct folding in some editors. Best regards, Alexandermailto:[EMAIL PROTECTED] ___ 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] Is some magic required to check out new files from svn?
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. I am now convinced (also because of the other information you > reported) that you indeed had continued to use one of the test > conversion repositories from before the switchover. That would explain > all the problems you see. FWIW, I haven't been following Skip's subversion woes closely, but the behaviour he reported seems to match the symptoms I got when I tried to update my test sandbox after the official changeover (I blew the sandbox away completely as soon as I got checksum errors, though, so I didn't see any of the later strangeness). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] Implementation of PEP 341
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 thought Brett had actually updated those pages after the move to svn. . . > Thanks very much for all your help, Nick. It was extremely informative. I think we can chalk up a respectable win for the AST-based compiler - the trick I suggested wouldn't really have been practical without the AST layer between the parser and the compiler. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] str.dedent
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 missing a point here: string methods were introduced to make switching from plain 8-bit strings to Unicode easier. As such they are only needed in cases where an algorithm has to work on the resp. internals differently or where direct access to the internals makes a huge difference in terms of performance. In your use case, the algorithm is independent of the data type interals and can be defined solely by using existing string method APIs. > The motivation > is to be able to write multilined strings easily without damaging the > visual indentation of the source code, like this: > > def foo(): > msg = '''\ > From: %s > To: %s\r\n' > Subject: Host failure report for %s > Date: %s > > %s > '''.dedent() % (fr, ', '.join(to), host, time.ctime(), err) > > Writing multilined strings without spaces in the beginning of lines > makes functions harder to read, since although the Python parser is > happy with it, it breaks the visual indentation. This is really a minor compiler/parser issue and not one which warrants adding another string method. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 13 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2005-10-17: Released mxODBC.Zope.DA 1.0.9http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] str.dedent
> 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 just type help(str) in the interactive prompt and get the list of supported methods. Also, these methods are living in the namespace of the supported objects. It feels very natural, and goes hand in hand with Python's object-oriented nature. (just my 2 cents - I am not arguing for or against the specific case of dedent, by the way) Regards Antoine. ___ 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] ast status, memory leaks, etc
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 total refs were just before AST was checked in, but I believe it was over 340k. So there are likely some more ref leaks that should be investigated. It would be good to know the exact number before AST was checked in and now, minus any new tests. There is one memory reference error in test_coding: Invalid read of size 1 at 0x41304E: tok_nextc (tokenizer.c:876) by 0x413874: PyTokenizer_Get (tokenizer.c:1099) by 0x411962: parsetok (parsetok.c:124) by 0x498D1F: PyParser_ASTFromFile (pythonrun.c:1292) by 0x48D79A: load_source_module (import.c:777) by 0x48E90F: load_module (import.c:1665) by 0x48ED61: import_submodule (import.c:2259) by 0x48EF60: load_next (import.c:2079) by 0x48F44D: import_module_ex (import.c:1921) by 0x48F715: PyImport_ImportModuleEx (import.c:1955) by 0x46D090: builtin___import__ (bltinmodule.c:44) Address 0x1863E8F6 is 2 bytes before a block of size 8192 free'd at 0x11B1BA8A: free (vg_replace_malloc.c:235) by 0x4127DB: decoding_fgets (tokenizer.c:167) by 0x412F1F: tok_nextc (tokenizer.c:823) by 0x413874: PyTokenizer_Get (tokenizer.c:1099) by 0x411962: parsetok (parsetok.c:124) by 0x498D1F: PyParser_ASTFromFile (pythonrun.c:1292) by 0x48D79A: load_source_module (import.c:777) by 0x48E90F: load_module (import.c:1665) by 0x48ED61: import_submodule (import.c:2259) by 0x48EF60: load_next (import.c:2079) by 0x48F44D: import_module_ex (import.c:1921) by 0x48F715: PyImport_ImportModuleEx (import.c:1955) by 0x46D090: builtin___import__ (bltinmodule.c:44) I had a patch for this somewhere, I'll try to find it. However, I only fixed this exact error, there was another path that could still be problematic. Most of the memory leaks show up when we are forking in: test_fork1 test_pty test_subprocess Here's what I have so far. There are probably some more. It would be great if someone could try to find and fix these leaks. n -- 16 bytes in 1 blocks are definitely lost in loss record 25 of 599 at 0x11B1AF13: malloc (vg_replace_malloc.c:149) by 0x4CA102: alias (Python-ast.c:1066) by 0x4CD918: alias_for_import_name (ast.c:2199) by 0x4D0C4E: ast_for_stmt (ast.c:2244) by 0x4D15E3: PyAST_FromNode (ast.c:234) by 0x499078: Py_CompileStringFlags (pythonrun.c:1275) by 0x46D6DF: builtin_compile (bltinmodule.c:457) 56 bytes in 1 blocks are definitely lost in loss record 87 of 599 at 0x11B1AF13: malloc (vg_replace_malloc.c:149) by 0x4C9C92: Name (Python-ast.c:860) by 0x4CE4BA: ast_for_expr (ast.c:1222) by 0x4D1021: ast_for_stmt (ast.c:1900) by 0x4D15E3: PyAST_FromNode (ast.c:234) by 0x499078: Py_CompileStringFlags (pythonrun.c:1275) by 0x46D6DF: builtin_compile (bltinmodule.c:457) 112 bytes in 2 blocks are definitely lost in loss record 198 of 674 at 0x11B1AF13: malloc (vg_replace_malloc.c:149) by 0x4C9C92: Name (Python-ast.c:860) by 0x4CE4BA: ast_for_expr (ast.c:1222) by 0x4D1021: ast_for_stmt (ast.c:1900) by 0x4D16D5: PyAST_FromNode (ast.c:275) by 0x499078: Py_CompileStringFlags (pythonrun.c:1275) by 0x46D6DF: builtin_compile (bltinmodule.c:457) 56 bytes in 1 blocks are definitely lost in loss record 89 of 599 at 0x11B1AF13: malloc (vg_replace_malloc.c:149) by 0x4C9C92: Name (Python-ast.c:860) by 0x4CF3AF: ast_for_arguments (ast.c:650) by 0x4D1BFF: ast_for_funcdef (ast.c:830) by 0x4D15E3: PyAST_FromNode (ast.c:234) by 0x499161: PyRun_StringFlags (pythonrun.c:1275) by 0x47B1B2: PyEval_EvalFrameEx (ceval.c:4221) by 0x47: PyEval_EvalCodeEx (ceval.c:2739) by 0x47ABCC: PyEval_EvalFrameEx (ceval.c:3657) by 0x47: PyEval_EvalCodeEx (ceval.c:2739) by 0x4C27F8: function_call (funcobject.c:550) 112 bytes in 2 blocks are definitely lost in loss record 189 of 651 at 0x11B1AF13: malloc (vg_replace_malloc.c:149) by 0x4C9C92: Name (Python-ast.c:860) by 0x4CE4BA: ast_for_expr (ast.c:1222) by 0x4D02F7: ast_for_stmt (ast.c:2028) by 0x4D16D5: PyAST_FromNode (ast.c:275) by 0x499078: Py_CompileStringFlags (pythonrun.c:1275) by 0x46D6DF: builtin_compile (bltinmodule.c:457) 56 bytes in 1 blocks are definitely lost in loss record 118 of 651 at 0x11B1AF13: malloc (vg_replace_malloc.c:149) by 0x4C9A41: Num (Python-ast.c:751) by 0x4CE578: ast_for_expr (ast.c:1237) by 0x4CF4ED: ast_for_arguments (ast.c:629) by 0x4D1BFF: ast_for_funcdef (ast.c:830) by 0x4D15E3: PyAST_FromNode (ast.c:234) by 0x499161: PyRun_StringFlags (pythonrun.c:1275) by 0x47B1B2: PyEval_EvalFrameEx (ceval.c:4221) by 0x47: PyEval_EvalCodeEx (ceval.c:2739) by 0x47ABCC: PyEval_EvalFrameEx (
Re: [Python-Dev] Building Python with Visual C++ 2005 ExpressEdition
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 Windows didn't become slower. Visual C++ 2005 includes profile guided optimization (although this is not included in the Express Edition) and it would be interesting to see how much of a difference this makes. Microsoft was willing to give some copies of VS to Python developers before so I expect they'd be willing to give some copies of VS Professional or Team System. Tim Delaney: > There was a considerable amount of angst with the 2.4 release that can be > blamed solely on the CRT change (and hence different DLLs to link to). And > with them deprecating ISO standard functions ... One solution to CRT change is to drop direct linking of modules to the CRT and vector them through the core DLL. The core PythonXX.DLL would expose an array of functions (malloc, strdup, getcwd, ...) that would be called by all modules indirectly. Then, it no longer matters which compiler version or compiler you build extension modules with. Its quite a lot of work to do this as each CRT call site needs to change or a well thought through macro scheme be developed. Paul Moore: > The project file conversions seemed to go fine, and the debug builds > were OK, although the deprecation warnings for all the "insecure" CRT > functions was a pain. It might be worth adding > _CRT_SECURE_NO_DEPRECATE to the project defines somehow. I haven't tried to build Python with VC++ 2005 yet, but other code has also required _CRT_NONSTDC_NO_DEPRECATE for some of the file system calls. Neil ___ 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] Implementation of PEP 341
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 > > submit patches now? > > svn diff should be fine. Although I thought Brett had actually updated those > pages after the move to svn. . . > I did. But the docs just need to be revamped. But I can't start on that work until people tell me if they prefer FAQ-style (question listing all steps and then a question covering each step) or essay-style (bulleted list and then a definition/paragraph on each step) for bug/patch guidelines. > > Thanks very much for all your help, Nick. It was extremely informative. > > I think we can chalk up a respectable win for the AST-based compiler - the > trick I suggested wouldn't really have been practical without the AST layer > between the parser and the compiler. > Yeah, this is a total win for the AST compiler. I would not have wanted to attempt this with the old CST compiler. -Brett ___ 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: >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). >> >> >I don't understand how these are connected: why do you need to know >when Python is idle for multi-threaded applications, and why does not >knowing that it is idle cause massive repainting? > >Not sure whether an explicit example would help, though; one would >probably need to understand a lot of details of your application. Giving >a simplified version of the example might help (which would do 'print >"Repainting"' instead of actually repainting). > > As an example, consider a function plot(y,x) that plots a graph of y as a function of x. If I use threading, and Python doesn't let us know when it's idle, then the plot function needs to invalidate the window to trigger repainting. Otherwise, the event loop doesn't realize that there is something new to plot. Now if I want to draw two graphs: def f(): x = arange(1000)*0.01 y = sin(x) plot(y,x) plot(2*y,x) and I execute f(), then after the first plot(y,x), I get a graph of y vs. x with x between 0 and 10 and y between -1 and 1. After the second plot, the y-axis runs from -2 to 2, and we need to draw (y,x) as well as (2*y,x). So the first repainting was in vain. 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 -- so no repainting in vain here. I agree with you though that threads are a good solution for extension modules for which a standard event loop is not suitable, and for which graphics performance is not essential -- such as Tkinter (see my next post). --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
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 your own? > > Rolling my own. There's not much GUI to my window, basically it's just a window where I draw stuff. >>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? > > I agree that this works for some extension modules, but not very well for extension modules for which graphical performance is critical (see my reply to Martin). Secondly, I think that by thinking this through, we can come up with a suitable event loop framework for Python (probably similar to what Skip is proposing) that works without having to resort to threads. So we give users a choice: use the event loop if possible or preferable, and use a thread otherwise. --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] str.dedent
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 import, there's a feeling that it's something that ought to be done at compile time, or even parse time. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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: >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. > > This is essentially how Tcl does it (and which, btw, is currently being used in Tkinter): Tcl has the functions *Tcl_CreateFileHandler/**Tcl_DeleteFileHandler*, which allow a user to add a file descriptor to the list of file descriptors to select() on, and to specify a callback function to the function to be called when the file descriptor is signaled. A similar API in Python would give users a clean way to hook into the event loop, independent of which other packages are hooked into the event loop. // >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. > > This may not be such a serious problem. Being able to hook into Python's event loop is important only if users want to be able to use the extension module in interactive mode. 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. Having an event loop API in Python won't hurt them. --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
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 thread is idle, your thread should get all the time it wants. I'd actually expect this to give better interactive response, since you aren't doing busy-wait pauses all the time -- the thread can wake up as soon as an event arrives for it. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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
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 with this >>>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 waiting. >> >> >I'm not sure I understand what you meant. If you meant that it will >work slowly - a lot of people (including me) are using Tkinter without >a mainloop from the interactive shell, and don't feel the difference. >It uses exactly the method I described. > > This depends on what kind of extension module you run. I agree, for Tkinter you probably won't notice the difference -- although you are still wasting processor cycles. However, if graphics performance is important, busy-waiting is not ideal. --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
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 waiting. > > I'm not sure I understand what you meant. If you meant that it will > work slowly - a lot of people (including me) are using Tkinter without > a mainloop from the interactive shell, and don't feel the difference. Busy waiting is less efficient and less responsive than a solution which is able to avoid it. In many cases there will be little noticeable difference, but there will be some people who don't like it because it's not really the "right" solution to this sort of problem. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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: >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 sure? If Tkinter is running in a separate thread, then why does it need PyOS_InputHook? Maybe I'm misunderstanding the code in _tkinter.c, but it appears that the call to Tcl_DoOneEvent and the main interpreter (the one that reads the user commands from stdin) are in the same thread. Anyway, if we can run Tkinter's event loop in a thread separate from the main interpreter, then we can avoid all interference with other event loops, and also improve Tkinter's behavior itself: 1) Since this event loop doesn't need to check stdin any more, we can avoid the busy-wait-sleep loop by calling Tcl_DoOneEvent without the TCL_DONT_WAIT flag, and hence get better performance. 2) With the event loop in a separate thread, we can use Tkinter from IDLE also. --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
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 tricks (they _are_ simple, since I know next to nothing about threading) and gives you interactive use of PyGTK, WXPython and PyQt applications in a manner similar to Tkinter. Meaning, you can from the command line make a window, change its title, add buttons to it, etc, all the while your interactive prompt remains responsive as well as the GUI. With that support, matplotlib can be used to do scientific plotting with any of these toolkits and no blocking of any kind (cross-thread signal handling is another story, but you didn't ask about that). As I said, there may be something in your problem that I don't understand. But it is certainly possible, today, to have a non-blocking Qt/WX/GTK-based scientific plotting application with interactive input. The ipython/matplotlib combo has done precisely that for over a year (well, Qt support was added this April). Cheers, f ___ 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
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 critical >> >> > >I don't understand. If the main thread is idle, your thread >should get all the time it wants. > >I'd actually expect this to give better interactive response, >since you aren't doing busy-wait pauses all the time -- the >thread can wake up as soon as an event arrives for it. > > This is exactly the problem. Drawing one picture may consist of many Python commands to draw the individual elements (for example, several graphs overlaying each other). We don't know where in the window each element will end up until we have the list of elements complete. For example, the axis may change (see my example to Martin). Or, if we're drawing a 3D picture, then one element may obscure another. Now, if we have our plotting extension module in a separate thread, the window will be repainted each time a new element is added. Imagine a picture of 1000 elements: we'd have to draw 1+2+...+1000 times. So this is tricky: we want repainting to start as soon as possible, but not sooner. Being able to hook into Python's event loop allows us to do so. --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
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.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 a manner similar to Tkinter. > That may be, and I think that's a good thing, but it's not up to me to decide if PyGtk should support interactive use. The PyGtk developers decide whether they want to decide to spend time on that, and they may decide not to, no matter how simple it may be. --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] str.dedent
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 >> module, I >> better import textwrap". >> > > And regardless of the need to import, there's a feeling > that it's something that ought to be done at compile > time, or even parse time. ITYM you mean "If only python were lisp". (macros, or even reader macros) James ___ 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: > 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 a manner similar to Tkinter. >> > That may be, and I think that's a good thing, but it's not up to me to > decide if PyGtk should support interactive use. The PyGtk developers > decide whether they want to decide to spend time on that, and they may > decide not to, no matter how simple it may be. OK, I must really not be making myself very clear. I am not saying anything aobut the pygtk developers: what I said is that this can be done by the application writer, trivially, today. There's nothing you need from the authors of GTK. Don't take my word for it, look at the code: 1. You can download ipython, it's a trivial pure-python install. Grab matplotlib and see for yourself (which also addresses the repaint issues you mentioned). You can test the gui support without mpl as well. 2. If you don't want to download/install ipython, just look at the code that implements these features: http://projects.scipy.org/ipython/ipython/file/ipython/trunk/IPython/Shell.py 3. If you really want to see how simple this is, you can run this single, standalone script: http://ipython.scipy.org/tmp/pyint-gtk.py I wrote this when I was trying to understand the necessary threading tricks for GTK, it's a little multithreaded GTK shell based on code.py. 230 lines of code total, including readline support and (optional) matplotlib support. Once this was running, the ideas in it were folded into the more complex ipython codebase. At this point, I should probably stop posting on this thread. I think this is drifting off-topic for python-dev, and I am perhaps misunderstanding the essence of your problem for some reason. All I can say is that many people are doing scientific interactive plotting with ipython/mpl and all the major GUI toolkits, and they seem pretty happy about it. Best, f ___ 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
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: - The plot event loop is in a separate thread, accepting messages from the interactive thread. - These messages can contain plot commands; and they can also contain two new commands: - suspend -- stop plotting, and start saving commands in a queue. - resume -- execute all commands in the queue (with whatever increased efficiency tricks you're using) Then you can either just add functions to generate these messages, and call them at appropriate places; or set PyOS_InputHook to wrap each interactive call with a suspend/resume pair. But note that putting an event loop in a separate thread will be problematic if you want any of the events to generate callbacks into user code -- this could cause all sorts of nasty race-conditions! Using a separate thread for an event loop only seems practical to me if the event loop will never call back into user code (or if you're willing to put the burden on your users of making sure everything is thread safe). -Edward ___ 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
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 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. >> >> > This is essentially how Tcl does it (and which, btw, is currently > being > used in Tkinter): > Tcl has the functions *Tcl_CreateFileHandler/**Tcl_DeleteFileHandler*, > which allow a user to add a file descriptor to the list of file > descriptors to select() on, and to specify a callback function to the > function to be called when the file descriptor is signaled. A similar > API in Python would give users a clean way to hook into the event > loop, > independent of which other packages are hooked into the event loop. ... except when the GUI you're using doesn't expose (or even use) a file descriptor that you can use with select. Not all the world is Linux. BTW. I find using the term 'event loop' for the interactive mode very confusing. Ronald ___ 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
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 -- so no repainting in vain here. ...but even without posting and reading events as stated above, one could check for plot events every 1/100th a second. If there is an update, and it has been 10/100 seconds since that undrawn event happened, redraw. Tune that 10 up/down to alter responsiveness characteristics. 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. There are many reasonable solutions to your problem, not all of which involve changing Python's event loop. - Josiah ___ 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] Revamping the bug/patch guidelines (was Re: Implementation of PEP 341)
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 the preferred way to >>> submit patches now? >> svn diff should be fine. Although I thought Brett had actually updated those >> pages after the move to svn. . . >> > > I did. But the docs just need to be revamped. But I can't start on > that work until people tell me if they prefer FAQ-style (question > listing all steps and then a question covering each step) or > essay-style (bulleted list and then a definition/paragraph on each > step) for bug/patch guidelines. I'd prefer essay-style for the guidelines themselves, with appropriate pointers to the guidelines from the dev FAQ. However, I also think either approach will work, so I suggest going with whichever you find easier to write :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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: >>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) misleading. That separate thread might be the main thread (and, in many cases, is). The main thread is still a "separate" thread (separate from all others). Regards, Martin ___ 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
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 time ago, in detail. The solutions may not be perfect, but they do work for a fairly wide range of uses, including the interactive case. There may be a good reason why mpl's approach is insufficient, but I think that the discussion here would be more productive if that were stated precisely and explicitly. Up to this point, all the requirements I've been able to understand clearly work just fine with ipython/mpl (though I may well have missed the key issue, I'm sure). Cheers, f ___ 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
