dynamic form application
hello guys. i tryng to create a form builder application with a database backend. like wufoo.com im stuck,how do i use jquery to create dynamic forms,and how is the database designed for the actual forms and the data gathered using those forms i'd like to use rdbms preferebly postgres. regards eddy -- https://mail.python.org/mailman/listinfo/python-list
Re: Appending traceback from exception in child thread
On May 16, 4:02 am, "Gabriel Genellina" wrote: > You could use the 3-argument form of the raise > statement:http://docs.python.org/reference/simple_stmts.html#the-raise-statement Ah! When did that get there? :) > There is a problem: remember that the traceback object keeps a reference > to all previous frames -- that means, all local variables along the whole > stack of called functions are kept alive until you delete the traceback > object. And depending on your application, that might involve thousand of > objects "artificially" alive for an undeterminate period of time... Yes, that may be problematic, I'll have to experiment. Thanks to everyone's help here, I have plenty of alternatives if it turns out to be problematic. Your comments are all greatly appreciated -- thanks! Kind regards, Edd -- http://mail.python.org/mailman/listinfo/python-list
Appending traceback from exception in child thread
Hi folks, I have a some threadpool code that works like this : tp = ThreadPool(number_of_threads) futures = [tp.future(t) for t in tasks] # each task is callable for f in futures: print f.value() # <-- may propagate an exception The idea being that a Future object represents a value that may or may not have been computed yet and the .value() method will block until that value is ready. As the comment on the last line indicates, looking at the .value() of a Future may give the return value of the associated task, or it may also propagate an exception that was raised in a child thread. Inside the implementation I store caught exceptions with code that looks something like: try: self.return_value = self.task() except: self.exception = sys.exc_info()[1] The problem I have is that when an exception is propagated in to the parent thread by re-raising it, the part of the traceback from the child thread is lost. So if the program dies due to such an exception, I can't see what caused it by examining the printed traceback. To solve this problem, I could of course grab the traceback in the child thread and create some kind of custom exception that stashes the trace inside. This could then be caught on the fringes of my code in order to combine the tracebacks of parent and child together before printing it. But I was wondering if there might be a nicer way that keeps the original exception object. Perhaps something akin to gluing the tracebacks together at the point where the exception is re-raised? Kind regards, Edd -- http://mail.python.org/mailman/listinfo/python-list
Re: An object that creates (nested) attributes automatically on assignment
On Apr 11, 12:54 pm, Steven D'Aprano wrote: > Ah, now it is more clear. > > Okay, let's try this: > > >>> class C(object): > > ... def __getattr__(self, name): > ... # Only called if self.name doesn't exist. > ... inst = self.__class__() > ... setattr(self, name, inst) > ... return inst Ha! Perfect! I knew it should be simpler. Thanks very much! Kind regards, Edd -- http://mail.python.org/mailman/listinfo/python-list
Re: An object that creates (nested) attributes automatically on assignment
Hi Steven,
Thank you for your response!
On Apr 11, 4:22 am, Steven D'Aprano wrote:
> On Fri, 10 Apr 2009 19:04:38 -0700, Edd wrote:
> > Hi folks,
>
> > I'd like to use Python itself as the configuration language for my
> > Python application. I'd like the user to be able to write something like
> > this in their config file(s):
>
> > cfg.laser.on = True
> > cfg.laser.colour = 'blue'
> > cfg.discombobulated.vegetables = ['carrots', 'broccoli'] # ...
>
> > To this end, I've created a class that appears to allow instance
> > variables to be created on the fly.
>
> Um, don't all classes allow that?
>
> >>> class MyClass(): pass
> ...
> >>> instance = MyClass()
>
> Or do you mean instance *attributes*? Again, apart from built-in types
> and classes that use __slots__, all classes allow that.
>
> >>> instance.parrot = 'Norwegian Blue'
Yes I probably mean instance attributes. Forgive me, I am not
particularly sure of the terminology. But your MyClass example, won't
quite do what I want, as I'd like to be able to define instance
attributes on top of instance attributes by assignment:
>>> class MyClass(): pass
...
>>> instance = MyClass()
>>> instance.lasers.armed = True
Traceback (most recent call last):
File "", line 1, in
AttributeError: MyClass instance has no attribute 'laser'
>>>
> > In other words, I can to the
> > following to read a config file:
>
> > cfg = Config()
> > execfile(filename, {'cfg', cfg}, {})
>
> That's okay so long as you trust the user not to put malicious, or buggy,
> code in your config file. Personally, I think config files should be more
> tolerant of errors than a programming language.
That's certainly a valid remark, but this will be a tool for
programmers. I am hoping that the user will make use of the power in
moderation. Often, it really will be useful to allow functions to be
defined in the config files, for example.
> > However, I think my implementation of the Config class is a little
> > crappy. I'd really appreciate the critical eye of a pro. Here's the
> > sauce:
>
> For starters, where is your documentation? No doc strings, not even any
> comments! No, I tell a lie... *one* obscure comment that doesn't really
> explain much.
Yes, you're quite right. I was about to add some doc strings, but I
didn't think the implementation was good enough. That's somewhat
backwards, though, right?! Especially considering I'm asking for
improvements. Anyway, I had hoped that the example usage at the end
would show what the purpose of the class is.
>
> > class Config(object):
> > def __init__(self, sealed=False):
> > def seal():
> > for v in self._attribs.values():
> > if isinstance(v, self.__class__): v.seal()
> > del self.__dict__['seal']
>
> > d = {'_attribs': {}, '_a2p': None}
> > if not sealed: d['seal'] = seal
>
> > self.__dict__.update(d)
>
> I'm going to try to guess what the above does. When you initialise an
> instance, you can tell the instance to be "sealed" or unsealed. I'm not
> sure what the difference is, or why you would choose one over the other.
> Sealed instances seem to be exactly the same as unsealed instances,
> except they have a seal() method (actually a closure). The seal method,
> when called, recursively seals any embedded Config instances inside the
> current instance, then deletes itself.
>
> Arghhh!!! Self-modifying code!!! Unclean, unclean!!!
Quite!
> I'm not sure why seal() is necessary -- it seems to me that if present,
> all it does is delete itself. So why not just leave it out altogether?
As I said in the original post, such Config objects will be made
available to other kinds of user-written script and it's important
that the Config not change between the execution of one script and the
next. The seal() mechanism was an attempt to help the user from
*accidentally* doing this and then having to try to diagnose the
problem and understand how changing the config might have broken the
invariants of the software. I guess a big "DON'T CHANGE THE CONFIG IN
YOUR SCRIPTS" message in the manual, might be sufficient, though :)
> You also have a rather complicated way of adding instance attributes.
> Instead of
>
> d = {'_attribs': {}, '_a2p': None}
> self.__dict__.update(d)
>
> why not just do the more obvious:
>
> self
[rfc] An object that creates (nested) attributes automatically on assignment
Hi folks,
I'd like to use Python itself as the configuration language for my
Python application. I'd like the user to be able to write something
like this in their config file(s):
cfg.laser.on = True
cfg.laser.colour = 'blue'
cfg.discombobulated.vegetables = ['carrots', 'broccoli']
# ...
To this end, I've created a class that appears to allow instance
variables to be created on the fly. In other words, I can to the
following to read a config file:
cfg = Config()
execfile(filename, {'cfg', cfg}, {})
However, I think my implementation of the Config class is a little
crappy. I'd really appreciate the critical eye of a pro. Here's the
sauce:
class Config(object):
def __init__(self, sealed=False):
def seal():
for v in self._attribs.values():
if isinstance(v, self.__class__): v.seal()
del self.__dict__['seal']
d = {'_attribs': {}, '_a2p': None}
if not sealed: d['seal'] = seal
self.__dict__.update(d)
def __getattr__(self, key):
if not key in self._attribs:
d = Config(sealed='seal' not in self.__dict__)
def add2parent():
self._attribs[key] = d
if self._a2p:
self._a2p()
self._a2p = None
# if anything is assigned to an attribute of d,
# make sure that d is recorded as an attribute of this
Config
d._a2p = add2parent
return d
else:
return self._attribs[key]
def __setattr__(self, key, value):
if key in self.__dict__:
self.__dict__[key] = value
else:
if not 'seal' in self.__dict__:
clsname = self.__class__.__name__
raise AttributeError("'%s' object attribute '%s'
is read-only (object is sealed)" % (clsname, key))
self.__dict__['_attribs'][key] = value
if self._a2p:
self._a2p()
self._a2p = None
def __delattr__(self, key):
if key in self.__dict__:
clsname = self.__class__.__name__
raise AttributeError("can't delete '%s' object
attribute '%s' as it is used for book-keeping!" % (clsname, key))
else:
if key in self._attribs:
del self._attribs[key]
def __bool__(self):
return bool(self._attribs)
def __nonzero__(self):
return bool(self._attribs)
if __name__ == '__main__':
cfg = Config()
cfg.a = 1
cfg.b.c = 2
cfg.d.e.f.g.h = [1, 2, 3]
print cfg.a
print cfg.b.c
print cfg.d.e.f.g.h
del cfg.b.c
print cfg.b.c
try:
del cfg.d.e._attribs
except AttributeError, ex:
print ex
cfg.seal()
try:
cfg.k.l.z = []
except AttributeError, ex:
print ex
Once the config is loaded, it will be passed down to other user-
written scripts and it's important that these scripts don't
accidentally change the config. So the idea is that I'll call cfg.seal
() to prevent any further changes before passing it on to these other
scripts. Beyond the general fiddliness of the code, I think the way
seal() currently works is particularly pants.
I considered using a simpler approach:
def mkdd(): return defaultdict(mkdd)
cfg = mkdd()
execfile(filename, {'cfg': cfg}, {})
But I quite like the way the '.' separators quite naturally (IMO)
indicate a hierarchy of settings.
Comments and suggestions welcome!
Kind regards,
Edd
--
http://mail.python.org/mailman/listinfo/python-list
Re: Odd behavior regarding a list
Hi there, First of all, thanks to everyone for replying. This has been a great help. On Mar 26, 4:21 pm, Steven D'Aprano wrote: > On Thu, 26 Mar 2009 08:36:49 -0700, Edd Barrett wrote: > > My question is: why has 'parent_struct_sig' changed? I was under the > > impression the assignment operator copies, not references. > > You are mistaken. Firstly, Python does not have an assignment operator. > Assignment (technically, name binding) is not an operator in Python. You > can't over-ride it. > > Secondly, assignment in Python *never* copies. Ever. The only time a copy > is made is when you explicitly ask for a copy. This explains it. > > e.g. to copy a list L, use one of: > > list(L) > > L[:] Great :) > A few more comments, based on your code. > > > def __classdef_integer(self): > > Double-underscore name mangling is often more trouble than it is worth. > Unless you really need it, not just think you will need it, it is > generally considered poor style. It was an attempt at encapsulation. I didn't want my parser to call internals willy-nilly. Is there a better way? > > ... > > > # cache parent struct sig for later (when casting ptrs) > > If you're actually casting pointers in your code, I don't know what > language you're using, but it isn't Python! Python is not C, you don't > have direct access to pointers. I don't know what you're doing, perhaps > the comment is misleading? This is not reffering to anything python :P I will be casting some pointer types in LLVM assembler. Python is going to generate this code. > > ... > > > sys.exit(1) > > You do realise that this line tells your program to exit? Seems like a > strange thing to include in a method. I'm just debugging this part of code. Obviously this is removed now. > Hope some of this is helpful. Very! Many thanks. -- Edd -- http://mail.python.org/mailman/listinfo/python-list
Odd behavior regarding a list
Hi there,
My first post here, so hello :)
Just a little background, I am writing my dissertation, which is a JIT
compiler based upon LLVM and it's python bindings, along with the
aperiot LL(1) parser.
I have some code here, which is not behaving as I would expect. Could
someone enlighten me as to why this is so:
---8<---
def __classdef_integer(self):
"""
class definition for a integer object.
"""
this_class = "Integer"
# metadata inherited
self.__class_data[this_class] = \
self.__class_data["Object"]
# cache parent struct sig for later (when casting ptrs)
parent_struct_sig = \
self.__class_data[this_class]["struct-sig"]
this_cdata = self.__class_data[this_class]
#this_cdata["membernames"].append("value")
#this_cdata["type-sym"] = 1
#this_cdata["parent-class"] = "Object"
#vtab = self.__construct_vtable(this_class)
#self.__ir_add_typesym(this_class, vtab)
print "parent"
print parent_struct_sig
this_cdata["struct-sig"].append(self.__int_t)
print "new"
print parent_struct_sig
sys.exit(1)
---8<---
Notice how I am caching the old value of 'parent_struct_sig' before I
manipulate it.
Produces the following output:
---8<---
parent
[]
new
[, ]
---8<---
My question is: why has 'parent_struct_sig' changed? I was under the
impression the assignment operator copies, not references.
Sorry if the answer is blindingly obvious. I am somewhat jaded from
working on this every day :P
Heres my python environment:
---8<---
Python 2.6.1 (r261:67515, Dec 27 2008, 16:56:14)
[GCC 4.2.0 20070307 (prerelease)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
---8<---
Thanks
--
http://mail.python.org/mailman/listinfo/python-list
