Prev: Q for Emacs users: code-folding (hideshow)
Next: Best Pythonic Approach to Annotation/Metadata?
From: Paul Rubin on 15 Jul 2010 23:51
Karsten Wutzke <kwutzke(a)web.de> writes:
> 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?

A minute of web surfing found this:

http://chris-lamb.co.uk/2006/12/08/visitor-pattern-in-python/
From: Carl Banks on 16 Jul 2010 01:50
On Jul 15, 8:33 pm, Stefan Behnel <stefan...(a)behnel.de> wrote:
> Carl Banks, 16.07.2010 01:14:
>
>
>
>
>
> > Around these parts, we consider the main use of most Design Patterns
> > to be to work around limitations of other languages.  Visitor Pattern
> > is probably the worst example of it.
>
> > In Python it's completely unnecessary (at least in its boilerplate-
> > heavy incarnation as used in C++), and the fact that Python isn't
> > strongly typed, as you put it, is exactly the reason why.
>
> > Say you have a bunch of unrelated types that define a calculate
> > method, you have a variable x that could be any of these types.
> > Here's how you would do that in Python:
>
> >      x.calculate()
>
> > Bam, that's it.  Visitor Pattern in Python.  You don't have to create
> > a bunch of homemade dispatching boilerplate like you do in C++.
>
> Well, you can do that in every OO language. It's not what the visitor
> pattern is there for, though.
>
> The code I referenced is from the Cython compiler, and we use it to "do
> stuff" with the AST. The visitor pattern is actually a pretty common way to
> bind code in a single place that does a certain thing to different parts of
> a data structure. Without it, if you kept that code *inside* of the data
> structure, you'd have to spill the type specific parts all over your code..

Ahh, so this aspect oriented programming is it.

I see your point, Visitor Pattern isn't necessary to work around the
"can't easily polymorph unrelated types" limitation, but could still
be necessary to work around "can't easily dispatch on methods not part
of the class" limitation. So, ok, Visitor Pattern maybe isn't the
worst one. My bad


Carl Banks
From: Michele Simionato on 16 Jul 2010 03:52
On Jul 15, 7:58 pm, Karsten Wutzke <kwut...(a)web.de> wrote:
> 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

You ask about code generation and you already had answers in that
area, but let me talk a bit about a simpler topic, traversing a
hierarchical file system. I think this is relevant (even if not
answering your question) if you want to get familiar with the Python
way. In the old days, the way to traverse a file system was through
the os.path.walk function. Here is what the docs say (from
http://docs.python.org/library/os.path.html):

"""
os.path.walk(path, visit, arg)

Calls the function visit with arguments (arg, dirname, names) for each
directory in the directory tree rooted at path (including path itself,
if it is a directory). The argument dirname specifies the visited
directory, the argument names lists the files in the directory (gotten
from os.listdir(dirname)). The visit function may modify names to
influence the set of directories visited below dirname, e.g. to avoid
visiting certain parts of the tree. (The object referred to by names
must be modified in place, using del or slice assignment.)
"""

As you see the documentation make explicit reference to the visitor
pattern.
However a note below says:

"""
This function is deprecated and has been removed in 3.0 in favor of
os.walk().
"""

In other word, the visitor pattern is *not* the Pythonic way to solve
this
problem. The Pythonic way is to use os.walk, which converts the nested
structure in a flat structure. From the docs
(http://docs.python.org/library/os.html):

"""
This example displays the number of bytes taken by non-directory files
in each directory under the starting directory, except that it doesn’t
look under any CVS subdirectory:

import os
from os.path import join, getsize
for root, dirs, files in os.walk('python/Lib/email'):
print root, "consumes",
print sum(getsize(join(root, name)) for name in files),
print "bytes in", len(files), "non-directory files"
if 'CVS' in dirs:
dirs.remove('CVS') # don't visit CVS directories
"""

There is a big conceptual difference between os.path.walk and os.walk.
The first works like a framework: you pass a function to it and
os.path.walk
is in charging of calling it when needed. The second works like a
library:
os.walk flattens the hierarchical structure and then you are in charge
of
doing everything you wish with it.

os.walk is the Pythonic way, and you suggested to follow that
approach;
for instance elementTree and lxml (libraries for parsing XML data)
work
exactly that way. Actually one of the motivating examples for the
introduction of generators in Python was their use in flattening
data structure, i.e. exactly the pattern used by os.walk.

The message is stop thinking like in Java and start using idiomatic
Python. We are here to help.

Michele Simionato
From: Stefan Behnel on 16 Jul 2010 04:25
Carl Banks, 16.07.2010 07:50:
> On Jul 15, 8:33 pm, Stefan Behnel wrote:
>> The code I referenced is from the Cython compiler, and we use it to "do
>> stuff" with the AST. The visitor pattern is actually a pretty common way to
>> bind code in a single place that does a certain thing to different parts of
>> a data structure. Without it, if you kept that code *inside* of the data
>> structure, you'd have to spill the type specific parts all over your code.
>
> Ahh, so this aspect oriented programming is it.

Never thought about it that way, but you have a point there. It's pretty
much the same idea as AOP, but without any of those huge and feature
drooling code injection frameworks.

Stefan

From: Jean-Michel Pichavant on 16 Jul 2010 05:00
Karsten Wutzke wrote:
>> Yes, typo, I meant strictly.
>>
>>
>
> Damn, I mean strongly. At least not for identifying which methods to
> call depending on the type/s.
>
> Karsten
>
Stringly is the perfect combination of strictly and strongly. Nice one :)

JM
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Q for Emacs users: code-folding (hideshow)
Next: Best Pythonic Approach to Annotation/Metadata?