CGI vs WSGI
Dear all, what is the difference? Middleware? I'm wondering because the only variables I ever needed were PATH_INFO, REQUEST_METHOD, QUERY_STRING and maybe one more, all of which should be available from CGI, too. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Thread-safe dictionary
Hi, please consider the following code: from __future__ import with_statement class safe_dict(dict): def __init__(self, *args, **kw): self.lock = threading.Lock() dict.__init__(self, *args, **kw) def __getitem__(self, key): with self.lock: return dict.__getitem__(self, key) def __setitem__(self, key, value): with self.lock: dict.__setitem__(self, key, value) def __delitem__(self, key): with self.lock: dict.__delitem__(self, key) - would I need to override another methods e.g. update() or items() in order to remain thread-safe or is this enough? - in __getitem__, does it release the lock after returning the item? - wouldn't it be better to use threading.RLock, mutex, ... instead? Thanks a lot! -- http://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe dictionary
On May 10, 3:57 pm, Duncan Booth <[EMAIL PROTECTED]> wrote:
> IMHO you are probably best to write a thread-safe class which uses an
> ordinary dict (and has a nicely limited interface) rather than trying to
> produce a completely thread-safe dict type.
thanks, sounds good!
but that again:
from __future__ import with_statement
class safe_dict(dict):
def __init__(self):
self.lock = threading.Lock()
self.d = {}
def __getitem__(self, key):
with self.lock:
return self.d[key]
def __setitem__(self, key, value):
with self.lock:
self.d[key] = value
def __delitem__(self, key):
with self.lock:
del self.d[key]
- in __getitem__, does it release the lock after returning the item?
- wouldn't it be better to use threading.RLock, mutex, ... instead?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe dictionary
On May 10, 8:25 pm, [EMAIL PROTECTED] wrote: instead: > class safe_dict(dict): there should be: class safe_dict(object): -- http://mail.python.org/mailman/listinfo/python-list
Re: Thread-safe dictionary
On May 12, 11:40 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > - in __getitem__, does it release the lock after returning the item? > > Yes, it does. > > > - wouldn't it be better to use threading.RLock, mutex, ... instead? > > Better in what sense? Performance-wise? Semantically? Performance-wise, > the best thing would be to do > > safe_dict = dict > > because the builtin dict is already thread-safe unless user-defined > __hash__ or __eq__ methods get invoked (in which case the dictionary > still works correctly - it's only that it may get modified while > __hash__ or __eq__ is running). > > Semantically, it would be better to use a threading.RLock, if you > expect that __hash__ or __eq__ may access the dictionary recursively. > > Regards, > Martin Thank you! -- http://mail.python.org/mailman/listinfo/python-list
state machine and a global variable
Dear list, I'm writing very simple state machine library, like this: _state = None def set_state(state): global _state _state = state def get_state(): print _surface but I hate to use global variable. So, please, is there a better way of doing this? All I want is that a user has to type as little as possible, like: from state_machine import * set_state(3) get_state() I.e., nothing like: import state_machine my_machine = state_machine.new_machine() my_machine.set_state(3) my_machine.get_state() Thanks, in advance! -- http://mail.python.org/mailman/listinfo/python-list
Re: state machine and a global variable
On Dec 14, 7:35 pm, Matimus <[EMAIL PROTECTED]> wrote: > On Dec 14, 8:52 am, [EMAIL PROTECTED] wrote: > > > > > Dear list, > > I'm writing very simple state machine library, like this: > > > _state = None > > > def set_state(state): > > global _state > > _state = state > > > def get_state(): > > print _surface > > > but I hate to use global variable. So, please, is there a better way > > of doing this? All I want is that a user has to type as little as > > possible, like: > > > from state_machine import * > > set_state(3) > > get_state() > > > I.e., nothing like: > > import state_machine > > my_machine = state_machine.new_machine() > > my_machine.set_state(3) > > my_machine.get_state() > > > Thanks, in advance! > > Personally I _would_ do it the second way. That seems to be the most > appropriate way to do it. However, you can do it the second way and > still get the functionality you desire. > > [code in state_machine.py] > class StateMachine(object): > def __init__(self, state=None): > if state is None: > state = "DEFAULT_INIT_STATE" > self._state = state > > def get_state(self): > # print self._surface > return self._state > > def set_state(self, state): > self._state = state > > _sm = StateMachine() > set_state = _sm.set_state > get_state = _sm.get_state > [/code] > > Matt Thanks a lot! This is precisely what I had on my mind. -- http://mail.python.org/mailman/listinfo/python-list
Re: state machine and a global variable
On Dec 14, 11:06 pm, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] a écrit :
>
> > Dear list,
> > I'm writing very simple state machine library, like this:
>
> > _state = None
>
> > def set_state(state):
> > global _state
> > _state = state
>
> > def get_state():
> > print _surface
>
> NameError here !-)
>
>
>
> > but I hate to use global variable.
>
>
>
> > So, please, is there a better way
> > of doing this? All I want is that a user has to type as little as
> > possible, like:
>
> > from state_machine import *
> > set_state(3)
> > get_state()
>
> > I.e., nothing like:
> > import state_machine
> > my_machine = state_machine.new_machine()
> > my_machine.set_state(3)
> > my_machine.get_state()
>
> A possible solution:
>
> # state_machine.py
> class _StateMachine(object):
>def __init__(self):
> self._state = SomethingHere()
>def get_state(self):
> return self._state
>def set_state(self, xxx):
> # etc
>
> _s = _StateMachine()
> get_state = _s.get_state()
> set_state = _s.set_state()
>
I guess you meant without the parentheses:
get_state = _s.get_state
set_state = _s.set_state
> You still have a global, but at least it's a machine instance, not it's
> state !-)
>
> Now the question is: why do you think it's so important for your users
> to only see functions ? What's so wrong with:
>
> from state_machine import *
> m = get_state_machine()
> m.set_state(42)
Well, I guess I can see the advantages of using the class instances
but ... um ... the world isn't like that! :)
Consider this: how do you add up some numbers?
- "My sum is zero."
- "I add 3 to my sum."
- "I add 2 to my sum."
Or:
- "Three."
- "plus two."
Implicit context, some people call it. Sometimes it's useful to be as
precise as possible ("explicit is better than implict", right?) but
sometimes, it seems to me, it's just more natural not to repeat the
context all over again.
Thoughts?
--
http://mail.python.org/mailman/listinfo/python-list
Re: state machine and a global variable
On Dec 15, 12:02 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> On Dec 14, 2007 4:43 PM, <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Dec 14, 11:06 pm, Bruno Desthuilliers
> > <[EMAIL PROTECTED]> wrote:
> > > [EMAIL PROTECTED] a écrit :
>
> > > > Dear list,
> > > > I'm writing very simple state machine library, like this:
>
> > > > _state = None
>
> > > > def set_state(state):
> > > > global _state
> > > > _state = state
>
> > > > def get_state():
> > > > print _surface
>
> > > NameError here !-)
>
> > > > but I hate to use global variable.
>
> > >
>
> > > > So, please, is there a better way
> > > > of doing this? All I want is that a user has to type as little as
> > > > possible, like:
>
> > > > from state_machine import *
> > > > set_state(3)
> > > > get_state()
>
> > > > I.e., nothing like:
> > > > import state_machine
> > > > my_machine = state_machine.new_machine()
> > > > my_machine.set_state(3)
> > > > my_machine.get_state()
>
> > > A possible solution:
>
> > > # state_machine.py
> > > class _StateMachine(object):
> > >def __init__(self):
> > > self._state = SomethingHere()
> > >def get_state(self):
> > > return self._state
> > >def set_state(self, xxx):
> > > # etc
>
> > > _s = _StateMachine()
> > > get_state = _s.get_state()
> > > set_state = _s.set_state()
>
> > I guess you meant without the parentheses:
> > get_state = _s.get_state
> > set_state = _s.set_state
>
> > > You still have a global, but at least it's a machine instance, not it's
> > > state !-)
>
> > > Now the question is: why do you think it's so important for your users
> > > to only see functions ? What's so wrong with:
>
> > > from state_machine import *
> > > m = get_state_machine()
> > > m.set_state(42)
>
> > Well, I guess I can see the advantages of using the class instances
> > but ... um ... the world isn't like that! :)
>
> > Consider this: how do you add up some numbers?
> > - "My sum is zero."
> > - "I add 3 to my sum."
> > - "I add 2 to my sum."
>
> > Or:
> > - "Three."
> > - "plus two."
>
> > Implicit context, some people call it. Sometimes it's useful to be as
> > precise as possible ("explicit is better than implict", right?) but
> > sometimes, it seems to me, it's just more natural not to repeat the
> > context all over again.
>
> You're way too hung up on context when you should be hung up on state.
> Implicit state is bad, implicit global state is worse. You've got a
> shared global state, with an interface that's designed to dispatch on
> and mutate that state. It's basically every bad thing you can imagine
> about global state. Using an object means that the state machine is
> *local* state. Local state is good, because you've got a way to attach
> a name to it, to manipulate it explicitly, and to pass it around to
> other places.
>
> Your example presupposes two different use cases anyway, but most
> importantly what you're describing with sum is a mutation of local
> state (a local name binding), which is a very different thing than
> your state machine API.
>
> Honestly, I can't even imagine why you would want to implement a state
> machine *library* this way. If you meant "a library that has internal
> state" it makes a little more sense - I use an approach kind of like
> the one Bruno showed to handle global configuration and logging - but
> if you meant "a library for implementing state machines" you're on
> totally the wrong track.
Now, I very much *apologize*! I'm very sorry, I meant "a library that
has internal state", instead of "a library for implementing state
machines".
Basically, I agree that often the local state is much more useful. It
just seems to me that for some application it's an overkill. Like say,
for Turtle [1] (no jokes, please :) or PostScript [2].
[1] http://en.wikipedia.org/wiki/Logo_turtle
[2] http://en.wikipedia.org/wiki/PostScript
--
http://mail.python.org/mailman/listinfo/python-list
Re: state machine and a global variable
On Dec 15, 1:50 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Fri, 14 Dec 2007 23:06:28 +0100, Bruno Desthuilliers wrote:
> > Now the question is: why do you think it's so important for your users
> > to only see functions ? What's so wrong with:
>
> > from state_machine import *
> > m = get_state_machine()
> > m.set_state(42)
>
> I can't speak for the "only" part, but it is sometimes really convenient
> to have a set of *cough* convenience functions that do the simple stuff
> for you. For example:
>
> import random
> random.random()
>
> is much nicer for the simple cases than:
>
> import random
> prng = random.Random()
> prng.random()
>
> with the advantage that you can still instantiate your own instance if
> you need/want to.
>
> --
> Steven.
I agree, completely!
Ok, I think I'm going to provide both the simplified interface and the
class to instantiate. Thanks all!
Now suppose, this class looks like:
class StateMachine(object):
def __init__...
def function0...
def function1...
def function2...
...
up to many. And later in the library I would like to expose the
simplified interface as well:
_machine = StateMachine()
function0 = _machine.function0
function1 = _machine.function1
function2 = _machine.function2
...
Is there a way to do so in a programmatic way? Like:
_machine = StateMachine()
for function in {every function in _machine}:
function = _machine.function
Not that it's difficult to copy-paste some lines, I'm just curious and
maybe it would be a tiny bit easier to maintain the library.
--
http://mail.python.org/mailman/listinfo/python-list
