Re: The Modernization of Emacs
On 17 Jun., 17:13, Xah Lee <[EMAIL PROTECTED]> wrote: Yaawn! > Xah > [EMAIL PROTECTED] > ∑http://xahlee.org/ Hmm I just had to think about the C64/Amiga etc. game "California Games"... The game displayed a comment when the player broke his neck the 13th time when BMXing: "Geek of the week!" Karsten -- http://mail.python.org/mailman/listinfo/python-list
Extending objects by a method?
Hello, I'm new to Python so beware. I have a hierarchical object structure which I iterate over (the elements/classes of interest). I would like to apply the Visitor pattern onto this object structure, so I must add an "accept" method to every object (I'm interesting in) for the Visitor pattern to work. Is there any Python-inbuilt way to dynamically add a method or do I have to wrap each iterated object into a Decorator supplying the accept method? The latter would mean having to rebuild the (part) hierarchy with the Decorator objects before running the Visitor, which I'd like to avoid. Karsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Extending objects by a method?
Small correction: I probably have to add a method to a class, so that every object instantiated not by me has the desired functionality. Karsten -- http://mail.python.org/mailman/listinfo/python-list
Code generator and visitor pattern
Hello, this is obviously a Python OO question: Since Python isn't stringly typed, single-dispatch isn't available per se. So is the "double-dispatch" Visitor pattern, which is usually used in OO systems to implement code generators. So, what is the de facto method in Python to handle source code generation? Karsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Code generator and visitor pattern
On 15 Jul., 20:28, Thomas Jollans wrote: > On 07/15/2010 07:58 PM, Karsten Wutzke wrote: > > > Hello, > > > this is obviously a Python OO question: > > > Since Python isn't stringly typed, > > I expect this is an innocent typo, and you mean strictly. > > > single-dispatch isn't available per se. So is the "double-dispatch" Visitor > > pattern, > Yes, typo, I meant strictly. > Wait, what? > First of all, python is strictly typed in that every object has exactly > one type, which is different from other types. So you can't do "1"+2, as > you can in some other languages. > > Anyway, this is interesting: Tell me more about how Python's dynamic > nature makes it impossible to do whatever you're trying to do. I'm > baffled. What are you trying to do, anyway? > > > which is usually used > > in OO systems to implement code generators. So, what is the de facto > > method in Python to handle source code generation? > > WHOA! Now if that isn't a Gedankensprung. Also, I'm still very far from > your train of thought, apparently: Now, the thing that code generators > probably share is that they write code to files. It depends on what I'm > trying to do of course, but I expect there's a good chance that if I > wrote a code generator in Python, it wouldn't be particularly > object-oriented at all. Well, I'm most experienced in OO, so writing OO in Python seems like the way to start with Python. The visitor pattern uses single- dispatch, that is, it determines which method to call be the type of object passed in. I did some reading and it turned out that Python can't do it without some tricks (function decorators and 3rd party code). For what I'm doing, I can't, or rather don't want to rely on 3rd party code (that has reasons). Thus, the visitor OO pattern must be replaced by some other way. As I expected, you already hinted a non-OO solution. Which is now that *I* am wondering what that would look like... Note, that I have an hierarchical object structure which I want to iterate over, so using OO looked natural to me. If there's a better approach, I'm all ears. Karsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Code generator and visitor pattern
> > Yes, typo, I meant strictly. > Damn, I mean strongly. At least not for identifying which methods to call depending on the type/s. Karsten -- http://mail.python.org/mailman/listinfo/python-list
Visitor pattern and separating iteration
Hello,
I'm referring to
http://groups.google.com/group/comp.lang.python/browse_thread/thread/4f9ba9816fe4fd55#
I'm currently implementing what looks like a promising solution. I
have one problem though. My code generator isn't awfully complex, but
still I have problems trying to figure out where to put the iteration
code. Ideally, this should be in the classes the generator operates
on. Take the following Python code from my generator class:
def handleMethod(self, method):
# generate indent depending on object depth in tree
indent = self.generateIndent(method)
# "public final"
modifierString = ""
i = 0
for modifier in method.getModifiers():
if i > 0:
modifierString += " "
modifierString += modifier
i += 1
# "String firstName, String lastName"
parameterString = ""
i = 0
for parameter in method.getParameters():
if i > 0:
parameterString += ", "
parameterString += parameter.getType() + " " +
parameter.getName()
i += 1
code = indentString + modifierString + " " +
(method.getReturnType() is None and "" or method.getReturnType() + "
") + method.getName() + "(" + parameterString + ")"
code += "\n{"
# here the statements should go
code += "\n}"
return code
The place where the statements should go would require an iteration
over the statements. When looking at other code samples, you often see
def accept(self, visitor):
for child in self.getChildren():
child.accept(visitor)
visitor.visitMyClass(self)
Now, I am wondering how separation of iteration and actual code
generation can be done in my situation.
def accept(self, generator):
for child in self.getChildren():
child.accept(generator)
generator.handleMethod(self)
I could of course add a parameter to handleMethod which would be the
generated code for the statements, but is that design of any good use
then? I'm rather tempted to ditch the idea of separating iteration and
code generation, but then the use of the visitor pattern becomes more
and more questionable.
What is it I'm missing?
Karsten
--
http://mail.python.org/mailman/listinfo/python-list
Re: Visitor pattern and separating iteration
> # "public final" > modifierString = "" > > i = 0 > > for modifier in method.getModifiers(): > if i > 0: > modifierString += " " > modifierString += modifier > > i += 1 > And please don't comment on the code itself, as I'm just starting to learn the Python API. The above should be modifierString = " ".join(method.getModifiers()) Thanks Karsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Visitor pattern and separating iteration
On 22 Jul., 22:25, Ian wrote: > Hi Karsten, > > On 22/07/2010 12:03, Karsten Wutzke wrote:> What is it I'm missing? > > I think you are making it more complicated than it really is. > > The visitor pattern is about bringing all the little bits that would > otherwise be scattered all over > many node classes into one visitor class. For code generation this means > that all the code generation is done > in your visitor class. For pretty-printing you have another visitor > class. For code optimization a third > visitor class. > > If there is only one sequence in which the nodes should be visited, then > you can build it > in to the nodes of the tree. > > If you need to visit your nodes in different orders you might be better > off building a separated > tree-walker class for each order. Thus you might have a > post-order-walker for use with the code > generating visitor, and a in-order-walker for a pretty-printing visitor. > > The optimizing walker may need to take different routes through the tree > depending > upon what it finds. For example, it may compute the value of the RHS of > an assignment > before computing the address of the LHS, so it can make better use of > registers. Here the > visitor class itself needs to do the walking. > > Regards > > Ian My objects to iterate over are plain object-structures, composites. I have only one code generation pass, so generating code and then pretty printing is not intended/possible. I have many user options to configure the code generation. The visitor pattern is ideal for that matter, because I can keep the options in the generator rather than scatter all the options into the object classes' accessor methods. (making me think the visitor is just right and not more complicated than needed) I was just curious about separating the iteration code into the object classes, because GoF said "The main reason to put the traversal strategy in the visitor is to implement a *particular complex* traversal, one that depends on the results of the operations on the object structure." My code generator isn't really THAT complex (I thought), but reviewing the latter part of the quote makes me believe I was wrong. Code generation always depends on the previous results, that is the children of a composite in the object structure. Now that I realized it, I feel great about traversing in the visitor. Python just has a few consequences that makes creating common interfaces/abstract classes a little unusual. I'm just starting to really love Python (or its API), though I don't feel I've already discovered the core what it is really about. Best regards Karsten -- http://mail.python.org/mailman/listinfo/python-list
Constructor call in the same class?
What's wrong with:
class Enum(RootFragment):
__jpaTypes = {
# complete!
'CascadeType': Enum("javax.persistence.CascadeType"),
'DiscriminatorType':
Enum("javax.persistence.DiscriminatorType"),
'EnumType': Enum("javax.persistence.EnumType"),
'FetchType': Enum("javax.persistence.FetchType"),
'FlushModeType': Enum("javax.persistence.FlushModeType"),
'GenerationType': Enum("javax.persistence.GenerationType"),
'InheritanceType': Enum("javax.persistence.InheritanceType"),
'LockModeType': Enum("javax.persistence.LockModeType"),
'PersistenceContextType':
Enum("javax.persistence.PersistenceContextType"),
'TemporalType': Enum("javax.persistence.TemporalType"),
}
# constructor
def __init__(self, package, modifiers, name, superInterfaces = [],
annotations = [], innerClasses = [], properties = [],
methods = []):
RootFragment.__init__(self, packageName, modifiers, "enum",
name, superInterfaces, annotations, innerClasses, properties, methods)
?
I get
'CascadeType': Enum("javax.persistence.CascadeType"),
NameError: name 'Enum' is not defined
What's wrong with calling a constructor in a dict initializer? How do
I solve this?
Karsten
--
http://mail.python.org/mailman/listinfo/python-list
Re: Constructor call in the same class?
>
> You have to create your dict somewhere else. You can either set it from
> outside:
>
> class Enum(RootFragment):
> ...
>
> Enum._jpaTypes = { ... }
>
THANKS for the quick help.
Karsten
--
http://mail.python.org/mailman/listinfo/python-list
Contains/equals
Hello, I have an object which has a list of other complex objects. How do I best achieve a complex "contains" comparison based on the object's class? In Java terms, I'm looking for an equivalent to equals(Object) in Python. Does a similar thing exist? Directions appreciated. Karsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Contains/equals
On Aug 19, 4:47 pm, Peter Otten <__pete...@web.de> wrote: > Karsten Wutzke wrote: > > I have an object which has a list of other complex objects. How do I > > best achieve a complex "contains" comparison based on the object's > > class? In Java terms, I'm looking for an equivalent to equals(Object) > > in Python. Does a similar thing exist? Directions appreciated. > > I can't infer from your question whether you already know about > __contains__(). So there: > > >>> class Cornucopia: > > ... def __contains__(self, other): > ... return True > ...>>> c = Cornucopia() > >>> 42 in c > True > >>> "cherry pie" in c > True > >>> c in c > > True Whoops that easy... Thanks! Karsten -- http://mail.python.org/mailman/listinfo/python-list
