Function metadata (like Java annotations) in Python
Hi, I'm trying to attach some attributes to functions and methods, similar to Java annotations and .NET attributes. I also want to use a convenient decorator for it, something along the lines of @attr(name="xander", age=10) def foo(): ... Assigning attributes to the function will work, as will assigning keys and values to a dictionary in an attribute. But if there are more decorators in the way, this could fail: @onedec @attr(...) @twodec def foo(): ... Given 'foo' now, how do I find the attributes? Assigning to a global attribute registry (some interpreter-global dictionary), although less desirable, might have been acceptable, but then how do I identify the function after it's been wrapped in more decorators? Also, it may be nice to have the following work as well: @attr(name="Xander") @attr(age=10) @somedec @attr(hobby="knitting") def foo(): ... Any thoughts? Am I rehashing something old that my search skills didn't uncover? Thanks! Ori. -- http://mail.python.org/mailman/listinfo/python-list
Re: Function metadata (like Java annotations) in Python
Thanks bearophile,
I prefer not to use docstrings for metadata.
1. Not interfering with the other accepted docstring uses may be
difficult (doctests, epydoc)
2. It's impractical for attributes generated by code:
@attr(reference_profile_stats=pstats.Stats("foo.profile"))
def foo():
...
Regards,
Ori.
[EMAIL PROTECTED] wrote:
> oripel:
>
> Maybe this is a silly suggestion, the docstring is already overloaded,
> but it may be used for this too:
>
> def foo():
> """
> ...
> ...
> @ATTR name="Xander"
> @ATTR age=10
> @ATTR hobby="knitting"
> """
> ...
>
> (Or somethins similar without the @). Later you can retrive the
> attributes from the docstring, for example using a verbose RE like:
> r"\s* @ATTR \s+ (\w*) \s* = \s* (.*)"
> And you use it to create a dict of attributes.
> The decorators you apply to foo() must keep its docstring too.
>
> Bye,
> bearophile
--
http://mail.python.org/mailman/listinfo/python-list
Re: Function metadata (like Java annotations) in Python
Thanks! Now I see it's accepted to assume nice decorators that update __dict__. At least until __decorates__ or something similar is added... fumanchu wrote: > oripel wrote: > > I'm trying to attach some attributes to functions and methods, similar > > to Java annotations and .NET attributes. > > ... > > Assigning attributes to the function will work, as will assigning keys > > and values to a dictionary in an attribute. But if there are more > > decorators in the way, this could fail: > > > > @onedec > > @attr(...) > > @twodec > > def foo(): > > ... > > > > Given 'foo' now, how do I find the attributes? > > ... > > Any thoughts? Am I rehashing something old that my search skills didn't > > uncover? > > There are past discussions about this; google for "python-dev decorator > metadata". For example: > http://thread.gmane.org/gmane.comp.python.devel/77506/focus=77507 > > > Robert Brewer > System Architect > Amor Ministries > [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Function metadata (like Java annotations) in Python
Thanks Paddy - you're showing normal use of function attributes. They're still hidden when wrapped by an uncooperative decorator. Paddy wrote: > oripel wrote: > > Hi, > > > > I'm trying to attach some attributes to functions and methods, similar > > to Java annotations and .NET attributes. > > I also want to use a convenient decorator for it, something along the > > lines of > > > > @attr(name="xander", age=10) > > def foo(): > > ... > > > > Assigning attributes to the function will work, as will assigning keys > > and values to a dictionary in an attribute. But if there are more > > decorators in the way, this could fail: > > > > @onedec > > @attr(...) > > @twodec > > def foo(): > > ... > > > > Given 'foo' now, how do I find the attributes? > > > > Assigning to a global attribute registry (some interpreter-global > > dictionary), although less desirable, might have been acceptable, but > > then how do I identify the function after it's been wrapped in more > > decorators? > > > > Also, it may be nice to have the following work as well: > > > > @attr(name="Xander") > > @attr(age=10) > > @somedec > > @attr(hobby="knitting") > > def foo(): > > ... > > > > > > Any thoughts? Am I rehashing something old that my search skills didn't > > uncover? > > > > Thanks! > > Ori. > > I wrote up my investigation into function attributes and decorators on > my blog: > > http://paddy3118.blogspot.com/2006/05/python-function-attributes.html > http://paddy3118.blogspot.com/2006/05/function-attributes-assigned-by.html > > What do you think? > > - Paddy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Function metadata (like Java annotations) in Python
Thanks, In Python 2.5 there are also functools.wraps and functools.update_wrapper: http://docs.python.org/dev/whatsnew/pep-309.html George Sakkis wrote: > oripel wrote: > > Thanks Paddy - you're showing normal use of function attributes. > > They're still hidden when wrapped by an uncooperative decorator. > > The decorator module may be helpful in defining cooperative decorators: > http://www.phyast.pitt.edu/~micheles/python/documentation.html > > George -- http://mail.python.org/mailman/listinfo/python-list
Re: get the en of a program running in background
Module 'subprocess' may be a better fit for you than fork+exec. Here's an example with a signal handler (1) use subprocess, don't fork and exec (2) maybe this will help: --- import signal, subprocess # define the signal handler def logsignal(signum, frame): print "Caught signal" # register the signal handler for SIGCHLD signal.signal(signal.SIGCHLD, logsignal) # run the subprocess in the background subprocess.Popen(["sleep", "3"]) # Do more stuff --- The signal handler will be called when the child process ends. Just register your own handler. You only need to register the handler once. If you need this for a single run only, or need different behavior for different subprocesses, have your signal handler re-register the old handler (see the docs for module 'signal'). A note about the example: if you run it as is, the parent process will end before the child process does. Add a call to 'os.wait()' to have it wait for the child. In your GUI you probably won't want it. Hope this helps. awalter1 wrote: > Hi, > I develop a graphical user interface (with pyGTK) where a click on a > button shall launch a program P in background. I want to get the end of > this program P but I don't want that my HMI be freezed while P is > running. > I try to use fork examplesI found on the web, but it seems to not run > as expected. > I am not familiar with these techniques in unix as well as python. > But I suppose that my needs are usual, despite that I don't find > anything on the web ... > Is someone can give me a standard way to call a background program, > wait its end, with an IHM still active ? > > Thank a lot for any idea. -- http://mail.python.org/mailman/listinfo/python-list
ANN: Testoob 1.15 released
Testoob is the advanced Python test runner and testing framework that spices up any existing unittest test suite. Home: http://code.google.com/p/testoob Version 1.15 (Oct. 2009) adds better Python 2.6, IronPython, and Jython support, as well as test coverage improvements, better color support, and some new options and bugfixes. *nix and Windows are fully supported. Installation options: * 'easy_install -U testoob' * One of the packages at http://code.google.com/p/testoob/downloads/list This version wouldn't have been possible without the help of Ronnie van 't Westeinde. -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: Testoob 1.15 released
On Oct 14, 5:59 pm, Jorgen Grahn wrote: > But this sentence on the home page > > The documentation is sadly outdated, but may be > a starting point: > > made me stop looking. As far as I can tell, you cannot even find out > what's so advanced about it (or why "advanced" is a good thing) > without starting to use it. A brief comparison with module unittest > (which I am rather unhappy with) would have been nice, too. Those are good points Jorgen, thanks. The briefest summary I would give is: (a) You can run your unittest suites unmodified (so it's easy to try out) (b) The test running options have the potential to whet your appetite: % testoob -h Usage = testoob [options] [test1 [test2 [...]]] examples: testoob - run default set of tests testoob MyTestSuite - run suite 'MyTestSuite' testoob MyTestCase.testSomething - run MyTestCase.testSomething testoob MyTestCase - run all 'test*' test methods in MyTestCase Options === --version show program's version number and exit --help, -hshow this help message and exit --bgcolor=WHENWhat's the background color of the terminal. This is used to determine a readable warning color. Choices are ['auto', 'light', 'dark'], default is 'auto' --color-mode=WHEN When should output be in color? Choices are ['never', 'always', 'auto'], default is 'auto' --glob=PATTERNFiltering glob pattern --html=FILE output results in HTML --immediate, -i Immediate feedback about exceptions --list, -lList the test classes and methods found --list-formatted=FORMATTERLike option '-l', just formatted (e.g. csv). --pbarShow a progress bar --pdf=FILEoutput results in PDF (requires ReportLab) --processes=NUM_PROCESSES Run in multiple processes, use Pyro if available --processes_pyro=NUM_PROCESSES Run in multiple processes, requires Pyro --processes_old=NUM_PROCESSES Run in multiple processes, old implementation --randomize-order Randomize the test order --randomize-seed=SEED Seed for randomizing the test order, implies --randomize-order --regex=REGEX Filtering regular expression --repeat=NUM_TIMESRepeat each test --silent, -s no output to terminal --timed-repeat=SECONDSRepeat each test, for a limited time --time-each-test Report the total time for each test --xml=FILEoutput results in XML --quiet, -q Minimal output --verbose, -v Verbose output --vassert Make asserts verbose --interval=SECONDSAdd interval between tests --timeout=SECONDS Fail test if passes timeout --timeout-with-threads=SECONDS Fail test if passes timeout, implemented with threads --stop-on-failStop tests on first failure --debug Run pdb on tests that fail --threads=NUM_THREADS Run in a threadpool --capture Capture the output of the test, and show it only if test fails --coverage=AMOUNT Test the coverage of the tested code, choices are: ['silent', 'slim', 'normal', 'massive', 'xml'] --test-method-glob=PATTERNCollect test methods based on a glob pattern --test-method-regex=REGEX Collect test methods based on a regular expression --profiler=PROFILER Profile the tests with a profiler, choices are: ['hotshot', 'profile'] --profdata=FILE Target file for profiling information, default is 'testoob.stats' --rerun-on-fail Used with --debug, rerun a failing test when debugging it > /Jorgen - orip -- http://mail.python.org/mailman/listinfo/python-list
