Re: python gc performance in large apps
Robby Dermody wrote: > I have not yet run the director with COUNT_ALLOCS yet, due to a > problem dynamically loading in the kinterbasdb (Firebird SQL > interface) module. What're the specifics of the loading problem with kinterbasdb? AFAIK, kinterbasdb itself runs fine in a debug build of Python. The egenix mx extensions, which kinterbasdb uses for date/time handling unless the user specifies otherwise, do not. I've conferred with MAL on this topic and was told that egenix "doesn't support" running the extensions in a debug build. I made my own modifications to the mx extensions so that they work properly in a debug build; I could post the modified version somewhere for download if you're interested. -- http://mail.python.org/mailman/listinfo/python-list
atexit + threads = bug?
Consider the following program (underscores are used to force indentation): import atexit, threading, time def atExitFunc(): print 'atExitFunc called.' atexit.register(atExitFunc) class T(threading.Thread): def run(self): assert not self.isDaemon() print 'T before sleep.' time.sleep(1.0) print 'T after sleep.' T().start() print 'Main thread finished.' I would expect the program to print 'atExitFunc called.' after 'T after sleep.', but instead, it prints (on Windows XP with Python 2.3.5 or 2.4.2): T before sleep. Main thread finished. atExitFunc called. T after sleep. atExitFunc is called when the main thread terminates, rather than when the process exits. The atexit documentation contains several warnings, but nothing about this. Is this a bug? -- http://mail.python.org/mailman/listinfo/python-list
Re: atexit + threads = bug?
>> I would expect... > The relative order of "Main thread finished." and "T before > sleep" is purely due to timing accidents... Sure, I realize that the interactions between threads have no guaranteed order except what the programmer imposes upon them. I should have qualified my statement of expectation more carefully. > In fact, there are only two orderings you can count on here: > T before sleep < T after sleep > Main thread finished < atExitFunc called I understand your explanation and can live with the consequences, but the atexit docs sure don't prepare the reader for this. They say, "Functions thus registered are automatically executed upon normal interpreter termination." It seems like sophistry to argue that "normal interpreter termination" has occurred when there are still threads other than the main thread running. Suppose that today I promise to donate my body to science "upon my death", and tomorrow, I'm diagnosed with a gradual but inexorable illness that will kill me within ten years. I wouldn't expect to be strapped down and dissected immediately after hearing the diagnosis, on the basis that the mere prophecy of my death is tantamount to the death itself. -- http://mail.python.org/mailman/listinfo/python-list
Re: atexit + threads = bug?
[Tim Peters] > [David Rushby] >> They say, "Functions thus registered are automatically executed upon >> normal interpreter termination." It seems like sophistry to argue that >> "normal interpreter termination" has occurred when there are still >> threads other than the main thread running. > > Well, since atexit callbacks are written in Python, it's absurd on the > face of it to imagine that they run after the interpreter has torn > itself down. Of course. > It's also strained to imagine that threads have nothing to do > with shutdown... I don't imagine that. > You're welcome to suggest text you'd like better... What I'd like is for the behavior to become less surprising, so that the text could describe reasonable behavior, instead of retrofitting the text to more clearly explain (what I regard as) flawed behavior. What would be unreasonable about adding a join_nondaemonic_threads() call before the call to call_sys_exitfunc() near the beginning of Py_Finalize? Instead of _MainThread.__exitfunc having to rely on atexit.register to ensure that it gets called, join_nondaemonic_threads would call _MainThread.__exitfunc (or some functional equivalent). Both join_nondaemonic_threads and call_sys_exitfunc would execute while the interpreter "is still entirely intact", as the Py_Finalize comment says. The opening paragraph of the atexit docs could then read: "The atexit module defines a single function to register cleanup functions. Functions thus registered are automatically executed when the main thread begins the process of tearing down the interpreter, which occurs after all other non-daemonic threads have terminated and the main thread has nothing but cleanup code left to execute." This seems simple. Am I overlooking something? -- http://mail.python.org/mailman/listinfo/python-list
Re: atexit + threads = bug?
[Skip] > [David] >> This seems simple. Am I overlooking something? > A patch? <0.5 wink> I'm willing to write a patch if it stands a good chance of being accepted. So far, though, Tim has seemed resistant to the idea. Maybe he has reasons that I'm ignorant of? -- http://mail.python.org/mailman/listinfo/python-list
Re: py-ext: casting pointers to ints on 32bit and 64bit systems
Alexander Schmolck wrote:
> what's the best approach to write C(++)-extension code that has to create a
> python int from a C pointer and vice versa so that it works smoothly on 32 bit
> and 64 platforms (on which sizeof(int) != sizeof(*void)) equally work (under
> unix,mac&windows and with gcc, vc and borland)?
Do you really need to represent the pointers as integers, or do you
just need to pass them through Python and back to C? If the latter,
how about using PyCObject_FromVoidPtr/PyCObject_AsVoidPtr
(http://docs.python.org/api/cObjects.html )? PyCObject is probably
aimed squarely at the task you're doing (passing an opaque handle to a
C object from C into Python and back to C).
> I've suggested modifications along the following lines to a user who had
> problems building the module on a 64 bit system
>
> /* C++ -> py */
> Engine *ep;
> [...]
> return Py_BuildValue("l", long(ep))
>
> /* py -> C++ */
> long lHandle;
> [...]
> PyArg_ParseTuple(args, "ls:get", &lHandle, &lName)
I haven't actually done any Win64 programming, but I've read that on
that platform, sizeof(long) == 4, but sizeof(void *) == 8, so the C++
code above won't work on that platform. BTW, Visual C++ 7 and 8 have a
helpful /Wp64 switch that'll emit Win64 portability warnings.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Running a python program during idle time only
los wrote: > I'm trying to create a program similar to that of Google's desktop that > will crawl through the hard drive and index files. I have written the > program and as of now I just put the thread to sleep for 1 second after > indexing a couple of files. > > I'm wondering if anyone knows of a way that I could make so that the > program will run at full speed only runs after the computer has been > idle for a while. I've looked at the "nice" command but that's not > exactly what I want. On Windows: 1) You can use API calls in the win32file.ReadDirectoryChangesW() family to register to receive notification (event-based, not polling-based) of changes to one or more directory structures. 2) You can register to be informed X amount of time after the computer "becomes idle", as explained at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/taskschd/taskschd/idle_triggers.asp : """ An idle trigger is an event-based trigger that is fired a specific amount of time after the computer becomes idle. The computer is considered to be in an idle state when no keyboard or mouse input occurs. """ I haven't actually written any code to do this, but it appears to be accessible from Python via the win32com.taskscheduler.taskscheduler module; interface PyIScheduledWorkItem.[CreateTrigger(TASK_EVENT_TRIGGER_ON_IDLE) + SetIdleWait(...)]. There are related example programs in site-packages\win32comext\taskscheduler\test\test_addtask*.py 3) You can programmatically lower the priority of your process with win32process.SetPriorityClass(). --- So if you combine the three, you can create an indexing program that: a) Only operates when changes are actually made to the file system (no busy-wait). b) Defers all processing until the computer is "idle"; or also runs when the computer is not idle, yet yields priority to other processes; or runs under both conditions, but with a more aggressive priority when the computer is idle. -- http://mail.python.org/mailman/listinfo/python-list
Re: determine 32 or 64 bit architecture with python 2.2
On Jun 19, 4:28 pm, John Machin <[EMAIL PROTECTED]> wrote:
> On Jun 19, 9:17 pm, Kai Rosenthal <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> > how can I determine the architecture (32 or 64bit) with python 2.2 on
> > Windows or Unix (AIX, Solaris) OS, without the modul platform?
> > Thanks for your hints, Kai
>
> What happens when you fire up a 64-bit Python and type
> import sys; sys.maxint
> at it?
That's not suitable, because of the differences between LP64 and LLP64
(http://en.wikipedia.org/wiki/64-bit#64-bit_data_models ).
Try
python -c "import struct; print struct.calcsize('P')"
instead. That calculates the size of a pointer.
--
http://mail.python.org/mailman/listinfo/python-list
Re: GCC 4.1.2 installer for Python distutils compilation
On Mar 18, 5:08 am, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > This page: >http://www.develer.com/oss/GccWinBinaries > > contains a friendly Windows installer for GCC 4.1.2 (MinGW binary version), > with full support for integrating it with Python installations so that it is > used by distutils to compile Python extensions. Sweet! Even though I have access to MSVC 7.1, so I don't really need MinGW myself, it can be unnecessarily difficult to get Windows-using contributors started on a project that involves C extensions. Your contribution should improve the situation greatly. Thanks a lot. -- http://mail.python.org/mailman/listinfo/python-list
Re: GCC 4.1.2 installer for Python distutils compilation
On Mar 18, 6:22 pm, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > On 18/03/2007 13.24, DavidRushbywrote: > > > Even though I have access to MSVC 7.1, so I don't really need MinGW > > myself, [...] > > But remember that GCC 4.1.2 is almost 4 years newer than MSVC 7.1, and > I found it to produce more optimized code (especially for C++). Since it's > a free alternative, it might be worth to give it a go :) I just wrote a high-performance Windows-1251 codec in C (an optimized alternative to Python's including 'cp1251' codec). On Windows 2000 / Prescott PIV, GCC 4.1.2 does indeed produce code that is 30% faster than MSVC (this is with aggressive optimization switch tinkering on both compilers). This is for fairly simple, non- floating-point C code. -- http://mail.python.org/mailman/listinfo/python-list
Re: MS VC++ Toolkit 2003, where?
Alex Martelli wrote: > So -- does anybody know if the 2003-level Toolkit is STILL available for > download somewhere... http://www.microsoft.com/downloads/details.aspx?FamilyId=272BE09D-40BB-49FD-9CB0-4BFA122FA91B&displaylang=en -- http://mail.python.org/mailman/listinfo/python-list
Re: kinterbas and Python
Balin wrote: > Hi all, > I have some problem with packege kinterbas for Firebird db connection > this is my code: > > import kinterbasdb > > class ConnessioneDB: > def initialize(self): > kinterbasdb.init(concurrency_level=1) > con = kinterbasdb.connect(host='192.168.1.20', > database='/home/db/TEST.FDB', user='SYSDBA', password='masterkey) <--- E If that's the actual code you're using, presumably you're getting an error message like: SyntaxError: EOL while scanning single-quoted string because there's no closing quote after 'masterkey. If that's not the actual code, could you post the actual code, the actual error message, along with the versions of Python, Firebird, KInterbasDB, and your operating system? -- http://mail.python.org/mailman/listinfo/python-list
Re: IMPORTANT 2.5 API changes for C Extension Modules
Thank you for taking the time to pull the relevant links together and make this post, Neal. -- http://mail.python.org/mailman/listinfo/python-list
Re: kinterbas and Python
[EMAIL PROTECTED] wrote: > My error code is : > > concorrency level error > use kinterbas.init(concurrency_level=?) to set the concurrency level > legally... That's not the actual error message. The actual error message is: """ The concurrency level cannot be changed once it has been set. Use kinterbasdb.init(concurrency_level=?) to set the concurrency level legally. """ So, it seems that you're either trying to call kinterbasdb.init multiple times, or you're performing an operation that calls kinterbasdb.init implicitly, and later you're trying to call kinterbasdb.init explicitly. Either remove the kinterbasdb.init call entirely, or move it to a place where it is called before you perform any database operations, and won't be called again. -- http://mail.python.org/mailman/listinfo/python-list
