super() in class defs?

2011-05-25 Thread Jess Austin
I may be attempting something improper here, but maybe I'm just going about it the wrong way. I'm subclassing http.server.CGIHTTPRequestHandler, and I'm using a decorator to add functionality to several overridden methods. def do_decorate(func): . def wrapper(self): . if appropriate(): .

Re: __eq__() inconvenience when subclassing set

2009-11-02 Thread Jess Austin
On Nov 1, 1:13 am, "Gabriel Genellina" wrote: > Looks like in 3.1 this can be done with bytes+str and viceversa, even if   > bytes and str don't have a common ancestor (other than object; basestring   > doesn't exist in 3.x): > > p3> Base = bytes > p3> Other = str > p3> > p3> class Derived(Base):

Re: __eq__() inconvenience when subclassing set

2009-10-30 Thread Jess Austin
On Oct 29, 10:41 pm, "Gabriel Genellina" wrote: > We know the last test fails because the == logic fails to recognize mySet   > (on the right side) as a "more specialized" object than frozenset (on the   > left side), because set and frozenset don't have a common base type   > (although they share

Re: __eq__() inconvenience when subclassing set

2009-10-29 Thread Jess Austin
On Oct 29, 3:54 pm, Mick Krippendorf wrote: > Jess Austin wrote: > > That's nice, but it means that everyone who imports my class will have > > to import the monkeypatch of frozenset, as well.  I'm not sure I want > > that.  More ruby than python, ne? > > I t

Re: __eq__() inconvenience when subclassing set

2009-10-29 Thread Jess Austin
On Oct 28, 10:07 pm, Mick Krippendorf wrote: > You could just overwrite set and frozenset: > > class eqmixin(object): >     def __eq__(self, other): >         print "called %s.__eq__()" % self.__class__ >         if isinstance(other, (set, frozenset)): >             return True >         return su

__eq__() inconvenience when subclassing set

2009-10-28 Thread Jess Austin
I'm subclassing set, and redefining __eq__(). I'd appreciate any relevant advice. >>> class mySet(set): ... def __eq__(self, other): ... print "called mySet.__eq__()!" ... if isinstance(other, (set, frozenset)): ... return True ... return set.__eq__(self, o

Re: generators shared among threads

2006-03-09 Thread jess . austin
Bryan, You'll get the same result without the lock. I'm not sure what this indicates. It may show that the contention on the lock and the race condition on i aren't always problems. It may show that generators, at least in CPython 2.4, provide thread safety for free. It does seem to disprove m

Re: generators shared among threads

2006-03-08 Thread jess . austin
I just noticed, if you don't define maxsize in _init(), you need to override _full() as well: def _full(self): return False cheers, Jess -- http://mail.python.org/mailman/listinfo/python-list

Re: generators shared among threads

2006-03-07 Thread jess . austin
Paul wrote: >def f(): >lock = threading.Lock() >i = 0 >while True: >lock.acquire() >yield i >i += 1 >lock.release() > > but it's easy to make mistakes when implementing things like that > (I'm not even totally confident tha

Re: generators shared among threads

2006-03-07 Thread jess . austin
Alex wrote: > Last, I'm not sure I'd think of this as a reentrantQueue, so > much as a ReentrantCounter;-). Of course! It must have been late when I named this class... I think I'll go change the name in my code right now. -- http://mail.python.org/mailman/listinfo/python-list

Re: generators shared among threads

2006-03-06 Thread jess . austin
Thanks for the great advice, Alex. Here is a subclass that seems to work: from Queue import Queue from itertools import count class reentrantQueue(Queue): def _init(self, maxsize): self.maxsize = 0 self.queue = [] # so we don't have to override put() self.counter =

Re: Easy immutability in python?

2006-03-04 Thread jess . austin
I guess we think a bit differently, and we think about different problems. When I hear, "immutable container", I think "tuple". When I hear, "my own class that is an immutable container", I think, "subclass tuple, and probably override __new__ because otherwise tuple would be good enough as is".

Re: do design patterns still apply with Python?

2006-03-04 Thread jess . austin
msoulier wrote: > I find that DP junkies don't tend to keep things simple. +1 QOTW. There's something about these "political" threads that seems to bring out the best quotes. b^) -- http://mail.python.org/mailman/listinfo/python-list

generators shared among threads

2006-03-04 Thread jess . austin
hi, This seems like a difficult question to answer through testing, so I'm hoping that someone will just know... Suppose I have the following generator, g: def f() i = 0 while True: yield i i += 1 g=f() If I pass g around to various threads and I want them to always be y

Re: Easy immutability in python?

2006-03-04 Thread jess . austin
To be clear, in this simple example I gave you don't have to override anything. However, if you want to process the values you place in the container in some way before turning on immutability (which I assume you must want to do because otherwise why not just use a tuple to begin with?), then that

Re: Easy immutability in python?

2006-03-04 Thread jess . austin
Since this is a container that needs to be "immutable, like a tuple", why not just inherit from tuple? You'll need to override the __new__ method, rather than the __init__, since tuples are immutable: class a(tuple): def __new__(cls, t): return tuple.__new__(cls, t) cheers, Jess --

Re: Pulling all n-sized combinations from a list

2006-02-17 Thread jess . austin
hi, I'm not sure why this hasn't come up yet, but this seems to beg for list comprehensions, if not generator expressions. All of the following run in under 2 seconds on my old laptop: >>> alph = 'abcdefghijklmnopqrstuvwxyz' >>> len([''.join((a,b,c,d)) for a in alph for b in alph for c in alph f