Re: Windows service in production?

[Adam Jorgensen]

Yeah, we run our Python App as a service under Windows.

You can look at the open-souce part of our product using
http://trac.sjsoft.com/browser
If you look into the code you should be able to find some stuff to do with
services.

Specficially, look in trunk/j5/src/j5/OS/WinService.py

On 19 August 2011 07:00, Stephen Hansen  wrote:

> On 8/15/11 9:32 PM, snorble wrote:
> > Anyone know of a Python application running as a Windows service in
> > production? I'm planning a network monitoring application that runs as
> > a service and reports back to the central server. Sort of a heartbeat
> > type agent to assist with "this server is down, go check on it" type
> > situations.
> >
> > If using Visual Studio and C# is the more reliable way, then I'll go
> > that route. I love Python, but everything I read about Python services
> > seems to have workarounds ahoy for various situations (or maybe that's
> > just Windows services in general?). And there seem to be multiple
> > layers of workarounds, since it takes py2exe (or similar) and there
> > are numerous workarounds required there, depending on which libraries
> > and functionality are being used. Overall, reading about Windows
> > services in Python is not exactly a confidence inspiring experience.
> > If I knew of a reference example of something reliably running in
> > production, I'd feel better than copying and pasting some code from a
> > guy's blog.
>
> Belatedly: I run a few quite major windows services which are installed
> at various customer sites in production, and we have no issues with it
> being a windows service.
>
> I basically only ever ran into two problems:
>
>  1. The lack of a console. Your service flat out /does not have/ a
> console, which is a slightly weird state to be in: writing to sys.stdout
> will fail. A print statement left in can crash things up -- even if in
> third-party code.
>
>Now, once you realize this is there, its easy to "fix". I end up
> doing something like this very early on in processing:
>
>class FakeFile:
>def __init__(self, fp):
>self._fp = fp
>def write(self, data):
>try:
>self._fp.write(data)
>except:
>pass
>
># repeat with flush()
>
>sys.stdout = FakeFile(sys.stdout)
>sys.stderr = FakeFile(sys.stderr)
>
>That way it'll run from a regular terminal fine and write out fine,
> but if any stray attempts to print are left in, things will pass through
> fine when its running as a service.
>
>  2. Importing modules with the same names as dlls in system32 can go
> awry. I don't know if this is still there, I last touched this part of
> our code a long, long, long time ago: but my service does some manual
> PATH / PYTHONHOME / PYTHONPATH fiddling to take care of it. Its easy
> to do.
>
> It worked fine, and was stable and once going, everything worked fine.
>
> Ultimately, I have since abandoned running things as a real service
> directly, and wrote a "Metaservice" application we use in our company
> instead. It runs as a service, and executes any random series of
> programs beneath it, creating JOB's for each so any subprocesses of they
> launch all get killed together cleanly, and handling dependencies via
> between them through various means, and stuff like that. I just got
> tired of dealing with windows stuff, so. :)
>
> --
>
>   Stephen Hansen
>   ... Also: Ixokai
>   ... Mail: me+list/python (AT) ixokai (DOT) io
>   ... Blog: http://meh.ixokai.io/
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python Windows Extensions for Mac

[Adam Jorgensen]

You mean pywin32?

They sure don't install on linux so that should give you a clue...



On 19 August 2011 22:02, johnny.venter  wrote:

>
> Hello, I am looking for the Python Windows Extensions to see if they can be
> installed on a Mac.THanks.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Weird interaction with nested functions inside a decorator-producing function and closuring of outer data...

[Adam Jorgensen]

Hi all, I'm experiencing a weird issue with closuring of parameters
and some nested functions I have inside two functions that
return decorators. I think it's best illustrated with the actual code:

# This decorator doesn't work. For some reason python refuses to
closure the *decode_args parameter into the scope of the nested
decorate and decorate_with_rest_wrapper functions
# Renaming *decode_args has no effect
def rest_wrapper(*decode_args, **deco_kwargs):
def decorate(func):
argspec = getfullargspec(func)
decode_args = [argspec.args.index(decode_arg) for decode_arg
in decode_args]
def decorate_with_rest_wrapper(func, *args, **kwargs):
if decode_args:
args = list(args)
for index in decode_args:
args[index] = json.loads(args[index],
cls=deco_kwargs.get('json_decoder'))
return Response.ResponseString(json.dumps(func(*args,
**kwargs), cls=deco_kwargs.get('json_encoder')))
return decorator(decorate_with_rest_wrapper, func)
return decorate

# If I modify rest_wrapper slightly and use the parameters from
rest_wrapper as default value args for decorate it works. Why?
def rest_wrapper(*decode_args, **deco_kwargs):
def decorate(func, decode_args=decode_args, deco_kwargs=deco_kwargs):
argspec = getfullargspec(func)
decode_args = [argspec.args.index(decode_arg) for decode_arg
in decode_args]
def decorate_with_rest_wrapper(func, *args, **kwargs):
if decode_args:
args = list(args)
for index in decode_args:
args[index] = json.loads(args[index],
cls=deco_kwargs.get('json_decoder'))
return Response.ResponseString(json.dumps(func(*args,
**kwargs), cls=deco_kwargs.get('json_encoder')))
return decorator(decorate_with_rest_wrapper, func)
return decorate


# Similarly, this decorator doesn't work. For some reason python
refuses to closure the sa_session_class_lambda parameter into the
scope of the nested decorate and decorate_with_sqlalchemy functions
# Renaming the sa_session_class_lambda parameter does not work and
neither does changing the order of the args list.
def with_sqlalchemy(sa_session_parameter_name='sa_session',
sa_session_class_lambda=None):
def decorate(func):
argspec = getfullargspec(func)
sa_session_parameter_index =
argspec.args.index(sa_session_parameter_name)
if sa_session_class_lambda is None:
if argspec.args[0] == 'self':
sa_session_class_lambda = lambda obj, *args, **kwargs:
obj.get_sa_session_class()
else:
sa_session_class_lambda = lambda *args, **kwargs:
Alchemy.get_sa_session_class()
def decorate_with_alchemy(func, *args, **kwargs):
if args[sa_session_parameter_index]:
raise Exception('%s parameter is not empty!' %
sa_session_parameter_name)
try:
sa_session_class = sa_session_class_lambda(*args, **kwargs)
sa_session = sa_session_class()
args = list(args)
args[sa_session_parameter_index] = sa_session
retval = func(*args, **kwargs)
sa_session.commit()
return retval
except Exception, e:
sa_session.rollback()
raise e
finally:
sa_session.close()
return decorator(decorate_with_alchemy, func)
return decorate

# Again, if I modify decorate and use the parameters from
with_sqlalchemy as default value args in decorate it works fine. What
gives?
def with_sqlalchemy(sa_session_parameter_name='sa_session',
sa_session_class_lambda=None):
def decorate(func,
sa_session_parameter_name=sa_session_parameter_name,
sa_session_class_lambda=sa_session_class_lambda):
argspec = getfullargspec(func)
sa_session_parameter_index =
argspec.args.index(sa_session_parameter_name)
if sa_session_class_lambda is None:
if argspec.args[0] == 'self':
sa_session_class_lambda = lambda obj, *args, **kwargs:
obj.get_sa_session_class()
else:
sa_session_class_lambda = lambda *args, **kwargs:
Alchemy.get_sa_session_class()
def decorate_with_alchemy(func, *args, **kwargs):
if args[sa_session_parameter_index]:
raise Exception('%s parameter is not empty!' %
sa_session_parameter_name)
try:
sa_session_class = sa_session_class_lambda(*args, **kwargs)
sa_session = sa_session_class()
args = list(args)
args[sa_session_parameter_index] = sa_session
retval = func(*args, **kwargs)
sa_session.commit()
return retval
except Exception, e:
sa_session.rollback()
raise e
finally:
sa_session.close()
 

Re: Weird interaction with nested functions inside a decorator-producing function and closuring of outer data...

[Adam Jorgensen]

Thanks :-) Sorry about the size, I wasn't sure what was relevant...

On 24 August 2011 15:29, Peter Otten <__pete...@web.de> wrote:
> Adam Jorgensen wrote:
>
>> Hi all, I'm experiencing a weird issue with closuring of parameters
>> and some nested functions I have inside two functions that
>> return decorators. I think it's best illustrated with the actual code:
>
> You should have made an effort to reduce its size
>> # This decorator doesn't work. For some reason python refuses to
>> closure the *decode_args parameter into the scope of the nested
>> decorate and decorate_with_rest_wrapper functions
>> # Renaming *decode_args has no effect
>> def rest_wrapper(*decode_args, **deco_kwargs):
>>     def decorate(func):
>>         argspec = getfullargspec(func)
>>         decode_args = [argspec.args.index(decode_arg) for decode_arg
>> in decode_args]
>
> I didn't read the whole thing, but:
>
>>>> def f(a):
> ...     def g():
> ...             a = a + 42
> ...             return a
> ...     return g
> ...
>>>> f(1)()
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "", line 3, in g
> UnboundLocalError: local variable 'a' referenced before assignment
>
> Python treats variables as local if you assign a value to them anywhere in
> the function. The fix is easy, just use another name:
>
>>>> def f(a):
> ...     def g():
> ...             b = a + 42
> ...             return b
> ...     return g
> ...
>>>> f(1)()
> 43
>
> In Python 3 you can also use the nonlocal statement.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python IDE/Eclipse

[Adam Jorgensen]

I recommend PyCharm. Best Python IDE ever :-)

If you can't afford to pay for it in the long run, then PyDev is the next
best bet. I would recommend downloading the most
minimal Eclipse you can get (Usually the Eclipse RCP Runtime) and install
the necessary plugins as you go. This prevents
you from falling into the overloaded eclipse problem as quickly.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Functions vs OOP

[Adam Jorgensen]

Progranming with functions vs Progranming with objects sounds like C vs. C++
more than functional programming vs. OO programming

On 4 September 2011 04:18, William Gill  wrote:

> On 9/3/2011 9:51 PM, Terry Reedy wrote:
>
>>
>> It is possible that our doc was less than crystal clear. We are
>> constantly improving it where we can see fixable faults. If you run
>> across whatever it was and it still seems a bit muddy, post something
>> again.
>>
>>  Will do.
>
> Thanks.
>
> --
> http://mail.python.org/**mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] relaxing keyword usage restrictions

[Adam Jorgensen]

About the only keyword I can think of this being even slightly useful for
would be class and even then I think that clazz is a pretty acceptable
substitute.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What do you guys think about adding a method "to_json"

[Adam Jorgensen]

Perhaps an actual use-case would clarify the need for this?

2011/9/12 Chris Rebert 

> 2011/9/11 Juan Pablo Romero Méndez :
> > Hello,
> >
> > What do you guys think about adding a method "to_json" to dictionaries
> > and sequence types? Perhaps through a module import?
>
> Why? We already have json.dumps(); seems to cover the use case.
>
> Cheers,
> Chris
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Killing threads (was Re: Cancel or timeout a long running regular expression)

[Adam Jorgensen]

The point of the Java thread.stop() being deprecated seems to have very
little to do with undeclared exceptions being raised and a lot to do
with objects being left in a potentially damaged state.

As Ian said, it's a lot more complex than just adding try/catches. Killing a
thread in the middle of some non-atomic operation with side-effects
that propagate beyond the thread is a recipe for trouble.

In fact, while a a lot can be written about Java being a poor language the
specific article linked to about why Java deprecated thread.stop()
gives a pretty damn good explanation as to why Thread.stop() and the like
are a bad idea and what a better idea might be (Signalling that
a graceful halt should be attempted)
-- 
http://mail.python.org/mailman/listinfo/python-list