Is there an obvious way to do this in python?

[Bruno Desthuilliers]

H J van Rooyen wrote:
(snip)
> I would like to split this down further - see above - so for each user there is
> a sort of *pointer* to each of the kinds of transactions she can do, and these
> are shipped separately and *linked* at the client side...
> 
(snip)
>
> Now part of the reason I would like to go the transaction type route instead of
> the  "per user" route is robustness and maintainability,

Nothing prevents you from managing rights with a user -> allowed
transactions mapping...

BTW, note that "transaction" has a very definite meaning in DBMS jargon,
which is somewhat different from what you use this term for. This may
become a source of confusion...

> 
> |NOTE: This means that the client will need to have all the required
> |libraries at just the right versions. Imagine that your user decides to
> |upgrade to Python 3000 because it sounds cooler than plain old Python
> |2.4 ;) , but then they won't realize that it will break your code and
> |they might not be able to run your application anymore. So you would
> |have to know at least roughly how much control over the whole client
> |machine you will have. Will they all be regular desktops that users
> |will use day to day and then once in a while launch your application
> |then close it, or will these all be dedicated terminals like an  ATM?
> |The two are very different. You can assume complete control of all the
> |OS environment in a dedicated terminal but not in the case of a user
> |desktop.
> 
> True - have not even considered this - this would, I imagine, vary from site to
> site, and depend more on local IT policy - this is probably the strongest
> argument to date against going this route, as these machines would not be as
> tightly controlled as an ATM...
> 
> but then - If I want to use Python in the client at all, I would have to somehow
> come to terms with this - its more the normal sort of version control that would
> have to be done - after all if a user's machine is an XT running DOS - then its
> going to have to be upgraded before it can be used as a terminal...
> 
> So this is more an argument against the use of Python on the client and I don't
> like that...

Well, this is an argument against any kind of fat client whatever the
language, and one of the key reason for the growing demand for web
applications - reducing deployment problems to the minimum...


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"