Help the visibility of Python in computational science
Hi everyone, There is currently a competition running that could help give Python in computational science a bit of visibility. The competition is for the most popular recently published article on the Scholarpedia website, one of which is about a Python package "Brian" for computational neuroscience simulations. If you could take one minute to make sure you are signed in to your Google+ account and click the g+1 icon near the top right of the page, it has a chance of winning the competition. Here's the link to the article: http://www.scholarpedia.org/article/Brian_simulator Full disclosure, I'm the first author of that article, and I'd be happy to win the competition too. :) More details: Scholarpedia is an alternative to wikipedia with slightly tighter control: contributions only allowed from scholars, etc. "Brain Corporation" is offering $1 in prizes to the top 3 most popular entries published between last October and this June based on google +1 votes. It's a bit of a silly popularity contest because of this, but I still think it would be great if a Python based thing could win it. "Brian" is a package I wrote (with several others) to do simulations of spiking neural networks in Python. Read the article if you want to know more! :) Thanks all for your attention, Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Help the visibility of Python in computational science
On Thursday, January 31, 2013 10:06:44 PM UTC-5, Terry Reedy wrote: > On 1/31/2013 8:05 PM, dg.google.gro...@thesamovar.net wrote: > > Here's the link to the article: > > http://www.scholarpedia.org/article/Brian_simulator > > 'Brian' is obviously a play on 'brain', with two letters transposed. But > > comparison of the logo on the page above with the image on > > https://en.wikipedia.org/wiki/Life_of_brian > > shows another source ;-). > Pure coincidence I assure you, I'm just very stuck in the old days of web design with 3D text logos. ;) Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Help the visibility of Python in computational science
On Friday, February 1, 2013 12:09:04 AM UTC-5, Chris Angelico wrote: > On Fri, Feb 1, 2013 at 4:00 PM, Steven D'Aprano > > wrote: > > > dg.google.gro...@thesamovar.net wrote: > > > > > >> If you could take one minute to make sure you > > >> are signed in to your Google+ account > > > > > > Which Google+ account would that be? I have so few. > > > > > > > It's a thing non-nerds do, Steven. You wouldn't understand. Sadly for me though, I think the nerds are in the majority here. As of yesterday I got only two additional +1's. Ah well. I had to create a Google+ account for it myself actually. ;) Dan -- http://mail.python.org/mailman/listinfo/python-list
Magic function
Hi all,
I'm part of a small team writing a Python package for a scientific
computing project. The idea is to make it easy to use for relatively
inexperienced programmers. As part of that aim, we're using what we're
calling 'magic functions', and I'm a little bit concerned that they
are dangerous code. I'm looking for advice on what the risks are (e.g.
possibility of introducing subtle bugs, code won't be compatible with
future versions of Python, etc.).
Quick background: Part of the way our package works is that you create
a lot of objects, and then you create a new object which collects
together these objects and operates on them. We originally were
writing things like:
obj1 = Obj(params1)
obj2 = Obj(params2)
...
bigobj = Bigobj(objects=[obj1,obj2])
bigobj.run()
This is fine, but we decided that for clarity of these programs, and
to make it easier for inexperienced programmers, we would like to be
able to write something like:
obj1 = Obj(params1)
obj2 = Obj(params2)
...
run()
The idea is that the run() function inspects the stack, and looks for
object which are instances of class Obj, creates a Bigobj with those
objects and calls its run() method.
So, any comments on that approach?
I'm including the code I've written to do this, and if you have time
to look through it, I'd also be very grateful for any more specific
comments about the way I've implemented it (in particular, can it be
made faster, is my program creating cycles that stop the garbage
collection from working, etc.). I hope the code will be formatted
correctly:
def
getInstances(instancetype,level=1,includeglobals=True,containersearchdepth=1,exclude={},predicate=lambda
x:True):
"""Find all instances of a given class at a given level in the
stack
"""
vars = {}
# Note: we use level+1 because level refers to the level relative
to the function calling this one
if includeglobals: vars.update(stack()[level+1][0].f_globals)
vars.update(stack()[level+1][0].f_locals)
# Note that you can't extract the names from vars.itervalues() so
we provide via knownnames the names vars.iterkeys(),
# containersearchdepth+1 is used because vars.itervalues() is the
initial container from the point of view of this
# function, but not from the point of view of the person calling
getInstances
objs, names =
extractInstances(instancetype,vars.itervalues(),containersearchdepth
+1,knownnames=vars.iterkeys(),exclude=exclude,predicate=predicate)
return (objs,names)
def
extractInstances(instancetype,container,depth,containingname='vars()',knownnames=None,exclude={},predicate=lambda
x:True):
if depth<=0: return ([],[])
if isinstance(container,str): return ([],[]) # Assumption: no need
to search through strings
# Ideally, this line wouldn't be here, but it seems to cause
programs to crash, probably because
# some of the simulator objects are iterable but shouldn't be
iterated over normally
# TODO: Investigate what is causing this to crash, and possibly
put in a global preference to turn this line off?
if not isinstance(container,
(list,tuple,dict,type({}.itervalues(: return ([],[])
# Note that knownnames is only provided by the initial call of
extractInstances and the known
# names are from the dictionary of variables. After the initial
call, names can only come from
# the __name__ attribute of a variable if it has one, and that is
checked explicitly below
if knownnames is None:
knewnames = False
knownnames = repeat(containingname)
else:
knewnames = True
objs = []
names = []
try: # container may not be a container, if it isn't, we'll
encounter a TypeError
for x,name in zip(container,knownnames):
# Note that we always have a name variable defined, but if
knewnames=False then this is just
# a copy of containingname, so the name we want to give it
in this instance is redefined in this
# case. We have to use this nasty check because we want to
iterate over the pair (x,name) as
# variables in the same position in the container have the
same name, and we can't necessarily
# use __getitem__
if hasattr(x,'__name__'): name = x.__name__
elif not knewnames: name = 'Unnamed object, id =
'+str(id(x))+', contained in: '+containingname
if isinstance(x,instancetype):
if x not in exclude and predicate(x):
objs.append(x)
names.append(name)
else: # Assumption: an object of the instancetype is not
also a container we want to search in.
# Note that x may not be a container, but then
extractInstances will just return an empty list
newobjs, newnames =
extractInstances(instancetype,x,depth-1,containingname=name,predicate=predicate)
objs += newobjs
names += newnames
return (objs,names)
except: # if we encounter a TypeError from
Re: Magic function
Thanks everyone for the comments. I had previously thought about the possibility of the classes keeping track of their instances. I guess this could probably be done quite transparently with a decorator too (as we have many different types of objects being collected together). The only issue is that this approach forces you to use what are essentially global variables, whereas the searching through the stack method allows you to use the structure of the program to organise what objects each 'magic' function sees. Is this a good idea or not? I'm not entirely sure. I think that personally I would lean towards using this method of classes keeping track of their instances. It's not entirely my decision so I'll see what the others say about it. Any comments on this possibility: classes could keep track of their instances, and also keep track of which function or module the instances were defined in. Then, the magic functions could pick out objects defined in the same function or module rather than looking at the stack. This would achieve a similar thing, but is there any great advantage in doing it this way? My first thought is that you'd still have to go digging around in the stack to do this, but just not as much. Also, does anyone know of any specific things I should be aware of in taking this stack searching approach? I'm thinking of, for example, any planned changes in the execution model of Python or the inspect.stack() function in the next version of Python. Paul, "Your users are *scientists*, and you don't trust their intellectual ability to learn a programming language as simple as Python?" Well, it's not quite as simple as that. One thing is that we're not going to be able to force people to use our package. We believe it's going to be considerably better - particularly in terms of ease of use and extensibility - than the existing alternatives, but one of the factors that will affect how many people start using it is how simple we can make it to do basic things that they'll be familiar with. Many scientists are using Python now, but it's not yet quite well known enough that we can just assume that people will know it, and having to learn the details of a new programming language is a considerable disincentive for someone thinking about switching to a new piece of software (even if, as you say, Python is not the most difficult language to learn). Although the difference between the two pieces of hypothetical code I presented seems quite trivial to an experienced programmer, I think that the clarity and simplicity of the version that uses the magic functions might make a difference. The difference between being able to define and run a model with 10 lines or 20-30 lines of code might, somewhat perversely, be a significant factor. (The example I gave was simplified to illustrate what was going on, but the actual situation is more like you have 5 or 6 different types of object, each of which uses other types of object to initialise themselves, so that the magic function approach really reduces the length of the program considerably.) So, there's an aspect of PR about our wanting to have something like the magic functions, but it's not entirely about self promotion, because we think that in the long term it will be better for the users if they switch to using our package (or something like it). The reason being that the alternatives available at the moment all use their own custom made programming languages which have nothing like the power of a well developed general purpose language like Python, and are much more difficult to use and extend. One of them is a stack based language of all things! Carl, "Even if you implement magic functions, don't get rid of the straightforward "hard way"." Absolutely not! A very good point. In fact, the magic functions don't actually do any work themselves, they just create and call the 'hard way' functions (which are still visible to the user). They're an additional layer of abstraction which you can choose to use or not use. And actually, there will be situations where there is no alternative but to use the 'hard way'. We already learnt this lesson: a couple of our magic functions were behaving differently and causing some odd behaviour, so we changed them and now we're working on building a more consistent and explicit interface (and enforcing it works as expected with the unit testing module, a tedious but hopefully very useful exercise in the long run). -- http://mail.python.org/mailman/listinfo/python-list
Re: Magic function
Hi Rüdiger, Thanks for your message. I liked your approach and I've been trying something along exactly these sorts of lines, but I have a few problems and queries. The first problem is that the id of the frame object can be re-used, so for example this code (where I haven't defined InstanceTracker and getInstances, but they are very closely based on the ideas in your message): class A(InstanceTracker): gval = 0 def __init__(self): self.value = A.gval # each time you make a new object, give A.gval += 1 # it a value one larger def __repr__(self): return str(self.value) def f2(): a = A() # objects 0 and 2 return getInstances(A) def f3(): a = A() # object 1 return f2() inst2 = f2() inst3 = f3() print inst2 print inst3 The output is: [0] [0, 2] The A-variable with value 0 is not being garbage collected because it's saved in the variable inst2, but it's also being returned by the second call to getInstances because the frame of f2 is the same each time (which makes sense, but may be implementation specific?). The same problem doesn't exist when you use the stack searching method because from f2's point of view, the only bound instance of A is the one in that particular call of f2. If you had at the end instead of the inst2, inst3 stuff: print f2() print f3() The output is: [0] [2] Again, I guess this because A with value 0 is being garbage collected between print f2() and print f3(), but again I think this is implementation specific? You don't have a guarantee that this object will be garbage collected straight away do you? So my concern here is that this approach is actually less safe than the stack based approach because it depends on implementation specific details in a non-straightforward way. That said, I very much like the fact that this approach works if I write: a = [A()] a = [[A()]] etc. To achieve the same thing with the stack based approach you have to search through all containers to (perhaps arbitrary) depth. I also have another problem which is that I have a function decorator which returns a callable object (a class instance not a function). Unfortunately, the frame in which the callable object is created is the frame of the decorator, not the place where the definition is. I've written something to get round this, but it seems like a bit of a hack. Can anyone suggest an approach that combines the best of both worlds, the instance tracking approach and the stack searching approach? Or do I need to just make a tradeoff here? Thanks again for all your help everyone, Dan Goodman -- http://mail.python.org/mailman/listinfo/python-list
Just for fun: Countdown numbers game solver
Ever since I learnt to program I've always loved writing solvers for
the Countdown numbers game problem in different languages, and so now
I'm wondering what the most elegant solution in Python is.
If you don't know the game, it's simple: you're given six randomly
chosen positive integers, and a target (another randomly chosen
positive integer), and you have to make the target using only the
numbers you're given, and +,-,* and / (and any number of brackets you
like). You're not allowed fractions as intermediate values. So, given
2, 3 and 5 say, and a target of 21, you could do (2+5)*3 = 21.
So what's the best algorithm? And, what's the most elegant way to code
it in Python? I've posted my most elegant version below (I have a
faster version which is slightly less elegant). Can anyone do better?
Refs:
* This academic paper describes an implementation of an algorithm to
solve the problem in Haskell. I found it after I'd written mine but it
uses a very similar algorithm. http://www.cs.nott.ac.uk/~gmh/countdown.pdf
* My web page where I put both versions of my code:
http://thesamovar.net/countdownnumbers
* The web page of the TV show the problem is based on:
http://www.channel4.com/entertainment/tv/microsites/C/countdown/index.html
My version:
class InvalidExpressionError(ValueError):
pass
subtract = lambda x,y: x-y
def add(x,y):
if x<=y: return x+y
raise InvalidExpressionError
def multiply(x,y):
if x<=y or x==1 or y==1: return x*y
raise InvalidExpressionError
def divide(x,y):
if not y or x%y or y==1:
raise InvalidExpressionError
return x/y
add.display_string = '+'
multiply.display_string = '*'
subtract.display_string = '-'
divide.display_string = '/'
standard_operators = [ add, subtract, multiply, divide ]
class Expression(object): pass
class TerminalExpression(Expression):
def __init__(self,value,remaining_sources):
self.value = value
self.remaining_sources = remaining_sources
def __str__(self):
return str(self.value)
def __repr__(self):
return str(self.value)
class BranchedExpression(Expression):
def __init__(self,operator,lhs,rhs,remaining_sources):
self.operator = operator
self.lhs = lhs
self.rhs = rhs
self.value = operator(lhs.value,rhs.value)
self.remaining_sources = remaining_sources
def __str__(self):
return '('+str(self.lhs)+self.operator.display_string
+str(self.rhs)+')'
def __repr__(self):
return self.__str__()
def
ValidExpressions(sources,operators=standard_operators,minimal_remaining_sources=0):
for value, i in zip(sources,range(len(sources))):
yield TerminalExpression(value=value,
remaining_sources=sources[:i]+sources[i+1:])
if len(sources)>=2+minimal_remaining_sources:
for lhs in
ValidExpressions(sources,operators,minimal_remaining_sources+1):
for rhs in ValidExpressions(lhs.remaining_sources,
operators, minimal_remaining_sources):
for f in operators:
try: yield BranchedExpression(operator=f, lhs=lhs,
rhs=rhs, remaining_sources=rhs.remaining_sources)
except InvalidExpressionError: pass
def TargetExpressions(target,sources,operators=standard_operators):
for expression in ValidExpressions(sources,operators):
if expression.value==target:
yield expression
def FindFirstTarget(target,sources,operators=standard_operators):
for expression in ValidExpressions(sources,operators):
if expression.value==target:
return expression
raise IndexError, "No matching expressions found"
if __name__=='__main__':
import time
start_time = time.time()
target_expressions = list(TargetExpressions(923,[7,8,50,8,1,3]))
target_expressions.sort(lambda x,y:len(str(x))-len(str(y)))
print "Found",len(target_expressions),"solutions, minimal string
length was:"
print target_expressions[0],'=',target_expressions[0].value
print
print "Took",time.time()-start_time,"seconds."
--
http://mail.python.org/mailman/listinfo/python-list
Re: Just for fun: Countdown numbers game solver
Hi Marek, That's a really nice solution (and ultrafast). Unfortunately I realise I stated the problem imprecisely. You're only allowed to use each number once (otherwise there's a trivial solution for every problem, i.e. x/x + x/x + x/x + ... + x/x repeated y times for target y given any source number x). Trying your program on 234 from [100,9,7,6,3,1] gives you 9*9*3-9 using the 9 three times. Does your solution adjust to deal with this additional requirement? At first I thought it would be an easy fix, but maybe it's a little more complicated than I thought... Dan Goodman -- http://mail.python.org/mailman/listinfo/python-list
Re: Just for fun: Countdown numbers game solver
Hi all, It's great how many different sorts of solutions (or almost solutions) this puzzle has generated. Speedwise, for reference my solution posted above takes about 40 seconds on my 1.8GHz laptop, and the less elegant version (on my webpage linked to in the original post) takes about 15 seconds. It seems to me like surely this problem can be more efficiently solved than that? My version isn't very Pythonic (it could almost be written in C++ the way I've done it) so I liked the idea of the first solution, but I don't think it can be fixed. I adapted it so that it doesn't use the same number more than once, but it still has some problems. Firstly, it only finds solution ((a op b) op c) op d etc. and won't find (for example (1+2)*(3+4). Secondly, it stores a dictionary value->how to get to value which is fine if you can re-use numbers because one way to get to a given value is as good as another, but sometimes you can get to the same number in two different ways using different numbers, so it misses solutions. Paul: 758 = 8+(5*((2+4)*25)) Arnaud: I haven't had time to play with your solution yet - how quick does it run? My fantasy is that there is a solution that isn't TOO slow where you can just look at the code and go 'Oh yes, of course that works!' and understand it immediately. Maybe that's too much to ask even of Python! ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Just for fun: Countdown numbers game solver
Decided I may as well post my other solution while I'm at it. The neat
trick here is redefining the add, mul, etc. functions so that they
raise exceptions for example if x>y then add(x,y) raises an exception
which is handled by the search algorithm to mean don't continue that
computation - this stops you from having to evaluate x+y AND y+x, etc.
sub = lambda x,y:x-y
def add(x,y):
if x<=y: return x+y
raise ValueError
def mul(x,y):
if x<=y or x==1 or y==1: return x*y
raise ValueError
def div(x,y):
if not y or x%y or y==1:
raise ValueError
return x/y
add.disp = '+'
mul.disp = '*'
sub.disp = '-'
div.disp = '/'
standard_ops = [ add, sub, mul, div ]
def strexpression(e):
if len(e)==3:
return '('+strexpression(e[1])+e[0].disp+strexpression(e[2])
+')'
elif len(e)==1:
return str(e[0])
# I don't like this function, it's nice and short but is it clear
# what it's doing just from looking at it?
def expressions(sources,ops=standard_ops,minremsources=0):
for i in range(len(sources)):
yield ([sources[i]],sources[:i]+sources[i+1:],sources[i])
if len(sources)>=2+minremsources:
for e1, rs1, v1 in expressions(sources,ops,minremsources+1):
for e2, rs2, v2 in expressions(rs1,ops,minremsources):
for o in ops:
try: yield ([o,e1,e2],rs2,o(v1,v2))
except ValueError: pass
def findfirsttarget(target,sources,ops=standard_ops):
for e,s,v in expressions(sources,ops):
if v==target:
return strexpression(e)
return None
print findfirsttarget(923,[7,8,50,8,1,3])
gives:
((7*(((8*50)-1)/3))-8)
Dan Goodman
--
http://mail.python.org/mailman/listinfo/python-list
Re: Just for fun: Countdown numbers game solver
Arnaud and Terry, Great solutions both of you! Much nicer than mine. I particularly like Arnaud's latest one based on folding because it's so neat and conceptually simple. For me, it's the closest so far to my goal of the most elegant solution. So anyone got an answer to which set of numbers gives the most targets from 100 onwards say (or from 0 onwards)? Is Python up to the task? A thought on that last one. Two ways to improve speed. First of all, you don't need to rerun from scratch for each target. Secondly, you can try multiple different sets of numbers at the same time by passing numpy arrays instead of single values (although you have to give up the commutativity and division by zero optimisations). Dan Goodman -- http://mail.python.org/mailman/listinfo/python-list
Re: Just for fun: Countdown numbers game solver
Well I tried the NumPy array thing that I was talking about, to parallelise the problem, and there were some difficulties with it. Firstly, the pruning makes a really big difference to the speed, and you don't get that if you're trying to parallelise the problem because what is an equivalent calculation for one set of numbers is obviously not for another set. I think this problem disappears when you consider very large sets of numbers though (where the cost of doing equivalent computations vanishes in comparison to the alternative cost of starting up the whole recursive computation from scratch many times). The second problem is that you can't weed out division by zero and intermediate fractions. I haven't looked at the internals of how NumPy deals with these though, so this might be fixable or it might not. For my part, I'd consider the following equivalences to be right for defining equivalent expressions (where here a, b and c are any subexpression, and 1 and 0 means any subexpression that evaluates to 1 and 0). Commutativity: a*b <-> b*a a+b <-> b+a Associativity: (a+b)+c <-> a+(b+c) (a+b)-c <-> a+(b-c) (a-b)+c <-> a-(b-c) (a-b)-c <-> a-(b+c) (a*b)*c <-> a*(b*c) (a*b)/c <-> a*(b/c) (a/b)*c <-> a/(b/c) (a/b)/c <-> a/(b*c) Units (1 is multiplicative unit, 0 is additive unit): a*1 <-> a a/1 <-> a a+0 <-> a a-0 <-> a Substitution (swapping equal starting numbers is equivalent): expr(a,b,c,...,z) <-> expr(s(a,b,c,...,z)) where a,b,c,...,z are the original numbers given and s is a permutation of (a,b,c...,z) so that (a,b,c,...z) evaluates to the same thing as s(a,b,c,...,z) or equivalently, expr1 <-> expr2 if str(expr1)==str(expr2) Then, any two expressions which can be transformed into one another by the equivalences above are equivalent. Commutativity and units can be easily implemented as you go and most of the programs suggested so far do this, by for example only allowing a*b or a+b if a>=b, and not allowing a*1 or 1*a, etc. Substitution can be implemented by just taking set(map(str,expressions)) at the end. The associativity ones are a little more tricky to implement, but Arnaud's idea of the fully ordered binary tree seems to do it. Another way of saying it is that any subexpression consisting only of + and - operations should be reduced to a+b+c+...-z-y-x- where a>b>c>... and z>y>x>... (and similarly for an expression involving only * and /). Terry, I'd also be interested in a copy of your stack simulation code, btw. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python self-evaluating strings
It's a bit cheap, but how about >>> from inspect import getsource >>> print getsource(getsource) or similarly def f(g): import inspect return inspect.getsource(g) print f(f) Dan -- http://mail.python.org/mailman/listinfo/python-list
explicit protocols and duck typing
Hi all, As I understand it, the idea behind duck typing is that you just take an object and if it has the methods you want to use you use it assuming it to be the right type of object. I'm interested in extending this idea a bit, but I feel the sort of thing I have in mind has already been thought of. So for example, in the program I'm writing a 'state variable' specifier can be either an integer or a string (the string name is mapped to an integer by another function getvarindex(name)). In this case, I can't do duck typing by seeing if the object has a method or not, because both of the types are built in types. I don't want to have to force the user to have objects like StateVariableSpecifier(name). Now at the moment, what I'm doing is accepting anything as a state variable specifier, and just passing it through the getvarindex function when I want to use it. This sort of specifies a protocol for state variable specifiers without making it explicit (like the sequence or mapping protocols built in to Python). What I'm wondering though is whether there is any value in making this more explicit? Say, have a class which makes explicit the various relationships involved, such as that the type of a state variable specifier can be correct or incorrect (it has to be an int or a string), that the value has to be correct (the integer has to be between 0 and n for some n, and the string has to be in a dict of names), and that there is a relationship between state variable specifiers (int, string) and the underlying data type (the index of the variable in an array). Making it more explicit seems like a good idea, the question is in what way to make it more explicit. I can make it explicit just by documenting the behaviour, or I can make it explicit by adding code that enforces certain ways of using things. For this simple example, it seems like just documenting it is the best route, but I have similar issues with other more complicated parts of the code. At the moment, a model for instance can be a Model object, an Equation object or a tuple of functions, but this could be subject to change in the future. The issue I want to address is the long term maintainability of the code when possibly many people might be contributing, the transparency for other users, and the ease of documenting it. Any opinions? Dan Goodman -- http://mail.python.org/mailman/listinfo/python-list
Adding properties to an instance
Hi all,
So I understand that properties belong to a class not an instance, but
nonetheless I want to add properties to an instance. I have a class
which when an instance is created runs some fairly complicated code
and produces a set of names which I'd like to be able to access via
properties. At the moment, I'm using something like obj.getvar(name)
but I'd like to be able to write obj.name. (Note that they can't be
just standard attributes because they only get computed when they are
accessed.) I could generate functions like obj.name() but I want it to
be obj.name instead.
The solution I've come up with is to create a new class for each
object which is just the real class with some extra properties, and
then dynamically change the class of the object to this new class.
This seems to work, but I wonder if (a) there is a nicer solution than
the one I'll post below, (b) if there are any dangers or pitfalls of
this approach. The obvious difficulty is with derived classes. At the
moment, I'm insisting that a derived class has to call a makeprops()
method to create the properties.
It's kind of similar to this recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/197965
but that recipe has a much simpler situation in which the properties
and values are known at the time of the creation of the object (by
contrast, I don't know what the properties are until the end of the
__init__ method).
Any thoughts?
Code below to illustrate my approach.
import warnings
from operator import itemgetter
class A(object):
def __init__(self,**kwds):
self._kwds = kwds
self.makeprops()
def __getitem__(self,i):
return self._kwds[i]
def makeprops(self):
if not hasattr(self,'_madeprops'):
self._madeprops = set()
self._failedprops = set()
class _A(self.__class__):
pass
for k,v in self._kwds.items():
if not k in self._madeprops and k in dir(self):
if not k in self._failedprops:
warnings.warn("Cannot create property "+k+",
already used in object "+str(self),RuntimeWarning)
self._failedprops.add(k)
else:
setattr(_A,k,property(fget=itemgetter(k)))
self._madeprops.add(k)
self.__class__ = _A
class B(A):
def __init__(self,**kwds):
super(B,self).__init__(**kwds)
self.makeprops()
class C(A):
def __init__(self,**kwds):
self._kwds = kwds
a = A(x=1)
b = B(x=2,makeprops=3)
c = C(x=3)
print isinstance(a,A), isinstance(a,B), isinstance(a,C) # True False
False
print isinstance(b,A), isinstance(b,B), isinstance(b,C) # True True
False
print isinstance(c,A), isinstance(c,B), isinstance(c,C) # True False
True
print a.__class__ #
print b.__class__ #
print c.__class__ #
print a.x # 1
print b.x # 2
print b.makeprops # >
try:
print c.x # raises exception
except AttributeError:
print "c has no element x"
c.makeprops()
print c.x # 3
print a.__class__ #
print b.__class__ #
print c.__class__ #
---
Dan Goodman
http://thesamovar.net/contact
--
http://mail.python.org/mailman/listinfo/python-list
Re: Adding properties to an instance
On Feb 6, 10:54 pm, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> I'd suggest a small improvement: _A as a class name isn't very nice.
> Replace the inner class statement with:
> _A = type(self.__class__.__name__ + '_autoprops', (self.__class__,), {})
Ah yes, that's much nicer.
> A problem with this approach is that instances aren't pickleable (perhaps
> that could be solved using __reduce__)
I think because the properties can be computed from knowing the rest
of the data of the object, it would be safe when pickling to just
pickle a copy of the object with the __class__ changed back to A (and
then when you load it again, you can just generate the properties
anew). I haven't really thought much about pickling but it would
certainly be a nice feature to have.
--
Dan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Adding properties to an instance
On Feb 6, 11:09 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > While this is technically possible (I tried a couple years ago), it > requires hacking the __getattribute__ method, which is something I > would not recommand, not only because it can be tricky, but mostly > because this is a very critical path wrt/ perfs. (IIRC it also > required using custom descriptors, but I'm not really sure about this > last point). Performance is pretty important for the class I'm designing so I think __getattribute__ is probably out. The computed properties are only infrequently accessed, but using __getattribute__ slows everything down, right? > Before new-style classes, we used the __getattr__/__setattr__ hooks > for computed attributes. While this approach is now a bit abandonned > in favor of descriptors (properties or custom ones), it still works > fine, and is probably the best solution to your problem. Ah, I didn't know about these - it looks as though they might be just the thing since it seems they're only called after all the other methods fail. That looks like there would be no performance hit, I wouldn't need to mess around with dynamically changing the class, and it would automatically deal with the (irritating) feature of having to check if there is already something in the object's dir() with that name. I'll look into this tomorrow - I hope this feature isn't going to be removed in future versions of Python? -- Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding properties to an instance
> As a side note: the naming symetry between __getattr__ and __setattr__ > is a gotcha, since __setattr__ is mostly symetric to __getattribute__ - > IOW, customizing __setattr__ is a bit tricky. The naive approach, ie: Ah I see - so __setattr__ is called immediately whereas __getattr__ is only called if the other methods fail. Does this mean that __setattr__ incurs the same performance penalty that overriding __getattribute__ would? Possibly I can live with this because I think that most of what I'm doing is getting attributes, or modifying mutable ones, rather than setting them. -- Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding properties to an instance
> > Does this mean that __setattr__ > > incurs the same performance penalty that overriding __getattribute__ > > would? > > Not quite AFAICT - there's less going on here. Also, getting an > attribute is (usually at least) more common than setting it. > > > Possibly I can live with this because I think that most of what > > I'm doing is getting attributes, or modifying mutable ones, rather > > than setting them. > > Well... Using the __setattr__/__getattr__ hooks is IMHO the simplest > solution that can possibly work - far simpler than your previous one at > least. As far as I'm concerned, and unless some other point of your > specs make this unusable or unpractical, I'd go for this solution first > and run a couple benchs on real-life-or-close-to conditions to check if > the performance hit is acceptable. I think you're right - I've just tried implementing a simple version of this in my code and it seems that in the time critical parts of it __setattr__ isn't called even once. So I think I'll go with this solution (after having run a few tests). Thanks for your suggestion! -- Dan -- http://mail.python.org/mailman/listinfo/python-list
How to tell if I'm being run from a shell or a module
Hi all, Is there any standard way to tell if the user is running from a module or from an interactive shell like IDLE or IPython? The best I've come up with so far is for a function to look at getouterframes(currentframe())[1][1] (the filename in the frame record of the frame that called the function), and check if it exists or not with os.path.exists. IPython gives '(ipython console)' and IDLE gives 'pyshell#0' whereas running from a module gives its filename. This seems a bit hacky. Any better ideas? -- Dan Goodman http://thesamovar.net/contact -- http://mail.python.org/mailman/listinfo/python-list
Re: How to tell if I'm being run from a shell or a module
Thanks for the replies, but it's not what I meant. What I want to be able to determine is whether or not the user is running from an interactive shell (like IPython or IDLE). Checking if __name__=='__main__' checks if the current module is the one being run, but suppose you have two modules A and B, with the function f defined in module B that should print 'Interactive' or 'Module' say. The module A just consists of: import B; B.f(). Now whenever f is called, __name__ will not be '__main__' for it. Someone using IDLE could write import B then B.f() too. The question is: is there a way for f to determine if someone was using an interactive shell to call it or if it was being called some other way. The way I came up with works in these limited cases but won't work in a more general situation (but perhaps there is no way for it to know in the more general situation). Dan On Feb 14, 7:01 pm, Chris <[EMAIL PROTECTED]> wrote: > If you're just trying to prevent some actions from happening if > something loads your script as a module just put the 'action items' > under an if like: > if __name__ == '__main__': > do_the_cool_stuff() > > All your functions inside the file will remain in-tact but it won't > execute anything. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to tell if I'm being run from a shell or a module
On Feb 14, 11:06 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > It depends on what you mean by "an interactive shell"? If you start your > script with: > python -i whatever.py > is it an interactive shell or not? > > I tried these two criteria: > a) See if the __main__ module has a __file__ attribute. > b) See if sys.stdin is a real tty Right, so my idea of an 'interactive shell' seems to be a little ill defined. Nonetheless, looking if the main module has a file attribute looked to be a good idea until I tried it on IPython - returns True... I think I'll do what I said in the first post, but add an option to override the behaviour for less usual circumstances. Seems to be the best compromise. Dan -- http://mail.python.org/mailman/listinfo/python-list
CUDA
Hi all, Has anyone managed to get any of the Python CUDA libraries working on Windows using cygwin? Which one, and was anything special required? Thanks in advance for any advice. Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: type-checking support in Python?
I also wrote a units package which I'm using for a project of my own (a spiking neural network simulator package called 'Brian'), released separately as a package called Piquant which you can get at sourceforge: http://sourceforge.net/projects/piquant I'm also looking for people to help improve it (get in touch!). The way the package works is to have a Quantity class derived from float, with extra operations. One thing that is different from the other packages out there (and the reason I went to the effort of writing my own package rather than using unum or scalar) is that we also have a QuantityArray or qarray class that derives from numpy.ndarray. There are at the moment two supported types of qarray, with homogeneous units (one unit for the whole array), and heterogeneous units (different unit for each item in the array). At the moment the heterogeneous units implementation is horrible and very slow, but I have a plan for a nicer version at some point (based on numpy's broadcasting rules, so allowing you to have one unit for each row or each column in a matrix for example). Actually I think it would be a really good idea for someone at some point to make a standardised system for units and add it to numpy/ scipy. I'd love to do it myself, but at the moment I have grant applications, papers to finish, etc... :-( Dan Sebastien Binet wrote: > hi, > > On Oct 7, 3:24�am, Bas <[EMAIL PROTECTED]> wrote: > > I have heard about some python package which overloads numbers and > > calculations to include units (quick google found unum, not sure if > > that is the only one). I guess that unless you are dealing with life- > > critical equipment or are using extreme programming, this is overkill > > (but I guess python is not really the right language for that anyway, > > imagine a garbage collection just when you want to launch your > > shuttle). > > FWIW, the python papers volume 3 issue 1 is mentionning another > package, 'scalar': > http://archive.pythonpapers.org/ThePythonPapersVolume3Issue1.pdf > http://russp.us/scalar.htm > > cheers, > sebastien. -- http://mail.python.org/mailman/listinfo/python-list
