On Thu, Jul 11, 2013 at 11:57 AM, Johan Dahlin wrote:
> I haven't followed pyobject introspection development very closely as of
> late,
> but I can imaging that the overrides mechanism is something that could
> potentially
> slow down the import considerably. Eg, lazy class creation won't work w
On Thu, Jul 11, 2013 at 11:53 AM, Daniel Drake wrote:
> Thanks for all the bugzilla links - lots of work to do!
>
NP, if you tackle any of these please note it in the ticket.
___
python-hackers-list mailing list
python-hackers-list@gnome.org
https://ma
On Thu, Jul 11, 2013 at 3:53 PM, Daniel Drake wrote:
> On Thu, Jul 11, 2013 at 12:40 PM, Simon Feltman wrote:
>> All of this takes us back to __getattr__ being on the top of a profile
>> again. In which case we should ask why is it getting called at all? A simple
>> print statement shows without
On Thu, Jul 11, 2013 at 12:40 PM, Simon Feltman wrote:
> All of this takes us back to __getattr__ being on the top of a profile
> again. In which case we should ask why is it getting called at all? A simple
> print statement shows without a doubt every access during module load is due
> to that at
Hi Daniel,
I am not opposed to porting parts of the bindings to C for optimization
purposes. However, from my experience, coming up with better caching
strategies, using lazy evaluation, and really questioning the mechanics
from a higher level can sometime be much more effective than just porting
Hi all,
I noticed my application's memory usage is constantly growing after each
DBus call, reaching huge amounts of memory, such as more than 2GB.
I tried looking at the test_gdbus test cases, and it turns out a simple
call to test_python_calls_sync() will increase the memory usage, without
any
