Re: timing
You could use pycallgraph module Regards, Alex Abushkevich -- http://mail.python.org/mailman/listinfo/python-list
Re: pipe using python
Hi, I use RabbitMQ in such cases. Hopefully this could help you. Regards, Alex On 10/16/10, hiral wrote: > Hi, > > Like we 'named pipes', how we can achieve comminication between more > than two processes. > And how it can be scaled to remote machines? > Any idea? > > Thank you. > -- > http://mail.python.org/mailman/listinfo/python-list > -- Sent from my mobile device -- http://mail.python.org/mailman/listinfo/python-list
The code that could not be...
Though Python is the language I use the most, there are several things
that I still hate, mostly about the implementation (CPython)...
The good thing is that some of these warts are now resolved, like the
exec dict issue.
Here is another one:
The object's __dict__ can only be a dict derivative and at that none of
the Python's mapping API will be used (the dict is accessed directly).
Here is a simple example example that this problem makes impossible...
---cut---
class AttrDict(dict):
'''This implements JavaScript-like object attribute/mapping
interface.'''
def __new__(cls, *p, **n):
o = dict.__new__(cls, *p, **n)
o.__dict__ = o
return o
# this works fine in current CPython...
o = AttrDict()
o.attr = 'val'
o['other'] = 123
print o.other # -> 123
print o # -> {'attr': 'val', 'other': 123}
# now if you modify this to add some logging...
def _getitem(self, name):
print 'getting "%s".' % name
return super(AttrDict, self).__getitem__(name)
AttrDict.__getitem__ = _getitem
# this will work as expected...
o['attr'] # -> getting "attr".
# and the following will not!
o.attr # will print nothing...
--uncut--
Thus, no user defined dict-like will work correctly as the objects
namespace...
To mention several tasks that can be made trivial using this technique
are, for instance zope-like acquisitions, various ACLs, interfaces and
other namespace manipulation patterns.
I wrote a patch some time back, it appears rather stable and is being
production tested.
you can download it here:
http://pli.sourceforge.net/object_dict_interface_use_fix.patch
So, to the purpose of this post... if there is any interest for a patch
like this, anyone who would be willing to test it and/or add feedback
to the topic would be very welcome! :)
P.S. I'm not proposing this patch to the python-dev until it is
extensively tested (and not just on my usecases :) )
--
http://mail.python.org/mailman/listinfo/python-list
Re: The code that could not be...
Fredrik Lundh wrote: > Alex A. Naanou wrote: > > > To mention several tasks that can be made trivial using this technique > > are, for instance zope-like acquisitions, various ACLs, interfaces and > > other namespace manipulation patterns. > > eh ? why not use Python's OO mechanisms for this, like everyone else is > doing... > > usually, as the ammount and complexity of code grows, I try to search for simpler and more natural ways of doing things and if I have to compare a 5 line implementation will always win over a 50 line module especially if this module runs substantially slower! :) -- http://mail.python.org/mailman/listinfo/python-list
Re: The code that could not be...
Steven Bethard wrote: > Alex A. Naanou wrote: > > The object's __dict__ can only be a dict derivative and at that none of > > the Python's mapping API will be used (the dict is accessed directly). > [snip] > > I wrote a patch some time back, it appears rather stable and is being > > production tested. > > > > you can download it here: > > http://pli.sourceforge.net/object_dict_interface_use_fix.patch > > Could you post this to Python's sourceforge tracker[1]? You're likely > to get more reviewers that way. > > BTW, I too would like to see this happen -- thanks so much for providing > an implementation! > > [1] http://sourceforge.net/tracker/?group_id=5470&atid=105470 > > STeVe I do not recomend using this code yet (there are several bugs here that were found today :) ) -- http://mail.python.org/mailman/listinfo/python-list
