large class hierarchies in python
Justin Dubs
I'm new to python, as of last week. I know several other OO langauges
though. Anyway, I am having trouble getting a hierarchy of "modules" to
behave as I would like them to. I guess I have several questions, or maybe
just one long one.
I love python's syntax and functionality. I'm not sure, however, if I am
the least bit pleased with the way it deals with "modules". I probably just
don't understand what I'm doing. I'm trying to pretty much do Java style
package hierarchies with python modules and I'm not sure if it is
possible/appropriate.
I want the directory structure to be the module (package?) structure of the
program. And I want each class to exist in a file of the same name. I
haven't yet gotten this concept to mesh well with the python module/import
paradigm. For example:
/
/agent
/agent/Agent.py
/agent/Environment.py
/agent/grid
/agent/grid/GridAgent.py
/agent/grid/GridEnvironment.py
Here, GridAgent and GridEnvironment inherit from Agent and Environment,
respectively. I assume each directory will need a __init__.py file, but I
really don't understand what to put in it to have it behave the way I'd
like. Any suggestions?
Also, as a maybe simpler question:
Is this entire method of programming just not going to work out with Python?
Is Python not suitable for this type of problem? If not, what languages do
you know of that are syntactially similar to Python and WOULD be
appropriate?
Thanks a lot guys,
Justin Dubs
Ignacio Vazquez-Abrams
> I want the directory structure to be the module (package?) structure of the
> program. And I want each class to exist in a file of the same name. I
> haven't yet gotten this concept to mesh well with the python module/import
> paradigm. For example:
It's all explained in the tutorial:
http://linux.ignacio.lan/docs/python/tut/node8.html#SECTION008400000000000000000
--
Ignacio Vazquez-Abrams <ign...@openservices.net>
Ignacio Vazquez-Abrams
> On Sat, 8 Sep 2001, Justin Dubs wrote:
>
> > I want the directory structure to be the module (package?) structure of the
> > program. And I want each class to exist in a file of the same name. I
> > haven't yet gotten this concept to mesh well with the python module/import
> > paradigm. For example:
>
> It's all explained in the tutorial:
It would probably help if I gave you an address you could actually get to...
http://www.python.org/doc/current/tut/node8.html#SECTION008400000000000000000
--
Ignacio Vazquez-Abrams <ign...@openservices.net>
Justin Dubs
times. It made some more sense this round.
One more question for you, however:
How do you feel about Python as a suitable language for this kind of
venture? In case I didn't mention it before, I forget, I'm working with
Intelligent Agents, one of the many subsets of AI. Is Python suitable for
what is very much OO and not at all scripting?
Also, can you suggest some other good OO languages to learn? I know
Objective-C, C++, Java, some Smalltalk and now Python. What do you think of
Eiffel, if anything?
Anyway, thanks again for the link.
Justin Dubs
"Ignacio Vazquez-Abrams" <ign...@openservices.net> wrote in message
news:mailman.1000001295...@python.org...
Ignacio Vazquez-Abrams
> How do you feel about Python as a suitable language for this kind of
> venture? In case I didn't mention it before, I forget, I'm working with
> Intelligent Agents, one of the many subsets of AI. Is Python suitable for
> what is very much OO and not at all scripting?
People may call Python a "scripting" language, but that's only because it
doesn't have enough mindshare for them to give it the distinction of being
called a "programming" language. It is, however, a full-fledged programming
language just as much as C and Java and all the rest.
> Also, can you suggest some other good OO languages to learn? I know
> Objective-C, C++, Java, some Smalltalk and now Python. What do you think of
> Eiffel, if anything?
Hmm. Unfortunately my OO knowledge is limited to Python, C++, Pascal/Delphi,
and JavaScript, so I can't say anything about Eiffel. I've taken a look at
Ruby, but I'm firmly convinced that it has no real reason for existing. I have
nothing against it, it's just that everything it does can be more cleanly done
in other languages that came before it.
--
Ignacio Vazquez-Abrams <ign...@openservices.net>
Justin Dubs
to tell you, I really do enjoy the Python syntax. It's a breath of clean
air compared to C/C++/Java. I especially like the way the indentation
forces good code style to a certain extent. Thanks again,
Justin Dubs
"Ignacio Vazquez-Abrams" <ign...@openservices.net> wrote in message
news:mailman.1000011971...@python.org...
Alex Martelli
...
> I want the directory structure to be the module (package?) structure of
> the program.
That's Python's basic package/module infrastructure, after all.
> And I want each class to exist in a file of the same name.
This may be excessive granularity, but that's an issue quite independent
from package/module issues.
> I haven't yet gotten this concept to mesh well with the python
> module/import paradigm. For example:
>
> /
> /agent
> /agent/Agent.py
> /agent/Environment.py
> /agent/grid
> /agent/grid/GridAgent.py
> /agent/grid/GridEnvironment.py
>
> Here, GridAgent and GridEnvironment inherit from Agent and Environment,
> respectively. I assume each directory will need a __init__.py file, but I
> really don't understand what to put in it to have it behave the way I'd
> like. Any suggestions?
Maybe
__all__ = ["GridAgent","GridEnvironment"]
as grid/__init__.py, etc, but that's only really needed if you want to
support "from agent.grid import *" and the like. If you have no other
initialization code you want to run for the package, __init__.py may almost
be empty -- except for the docstring, which should really always be there.
Such tricks as manipulating __path__ are rarely needed. The essay at
http://www.python.org/doc/essays/packages.html does a creditable job of
presenting such issues, it seems to me.
agent/__init__.py:
"""The agent package enables agentification [snip]"""
agent/Agent.py:
"""The agent.Agent module [blah blah]"""
class Agent:
"""The agent.Agent.Agent class [blah blah]"""
pass
agent/grid/__init__.py:
"""The agent.grid package enables agentification [snip]"""
agent/grid/GridAgent.py:
"""The agent.grid.GridAgent module [snip]"""
from agent import Agent
class GridAgent(Agent.Agent):
"""The agent.grid.GridAgent.GridAgent class [blah blah]"""
pass
Etc, etc.
> Also, as a maybe simpler question:
>
> Is this entire method of programming just not going to work out with
> Python?
> Is Python not suitable for this type of problem? If not, what languages
> do you know of that are syntactially similar to Python and WOULD be
> appropriate?
I don't know of anything in Python that will stand in the way of this
approach, nor of any languages where this approach would work better.
Alex
Andrae Muys
> Also, can you suggest some other good OO languages to learn? I know
> Objective-C, C++, Java, some Smalltalk and now Python. What do you think of
> Eiffel, if anything?
I personally only ever have two reasons for learning another
programming language. The first is naturally need, when my boss
needed me to do some "web-programming", I spent two days and learnt
Javascript. The second is for what I refer to as mental hysterisis.
The #1 trait I look for, and recommend in a new language, is "Will
this language permanantly change the way I think and program in the
other languages I use?".
So if you already know Obj-C, C++, Java, Smalltalk, and Python, I
would suggest it's probably time to experiment with something that
isn't imperitive-OO. Prolog, Haskell, Miranda, Forth, Postscript,
APL, would all suggest themselves to me as possibles, but there are
others in this group better qualified to make suggestions.
Andrae Muys
(and then one day you finish a small 15kloc C program, grep it and
realise that you forgot to use any explicit loops, without trying. ;).
Roy Smith
> So if you already know Obj-C, C++, Java, Smalltalk, and Python, I
> would suggest it's probably time to experiment with something that
> isn't imperitive-OO. Prolog, Haskell, Miranda, Forth, Postscript,
Postscript is a wonderful language, and one which anybody who considers
themselves a well-rounded programmer should learn. It's something that
most people come into contact with on a daily basis, without ever being
aware that it's a real programming language.
The stack-oriented nature of the language should feel familiar to anybody
who's used an RPN calculator (and anybody who hasn't will get exposed to
something worth being exposed to). The way functions are defined (push a
procedure body onto the stack then bind that to a name) is very similar to
way functions are defined in python (or, for that matter, lisp). All in
all, it's a cool little language, and definately worth learning if your
goal is to explore the range of programming languages.
Justin Dubs
I have already taught myself the basics of Prolog, Postscript and Lisp. I
will look into the rest of them though. I am trying to expose myself to all
of the various unique methods of programming for the purposes of eventually
designing one of my own also for purely theoretical and curiosity-based
reasons.
In order of abstraction, starting at the lowest is obviously assembler. I
know that for both x86 up through Pentium as well as the basics of motorola
assembler.
Above that I have C.
Above that I have C++, Objective-C, Pascal, Basic as well as more visual
languages such as Visual BASIC, Visual C++, Java and TCL and FoxPro.
Above that I have Perl, Python.
Above that I have Prolog, Lisp.
Also, more miscellaneously, HTML, Javascript, VBScript, SQL and Shell
scripting and a little of postscript and smalltalk.
I"ll dive into Haskell/Forth/Miranda/APL and see what I like. I also want
to do a little Scheme and Eiffel at some point. Thanks a lot for the
suggestions.
Do I appear to be missing any categories of languages? I have the basic OO,
Functional, Scripting languages covered, I think. Thanks again guys,
Justin Dubs
Justin Dubs
compiler/interpreters for Miranda or APL. I found the APL to C compiler,
but I was hoping for an interpreter. Miranda seems to be copyrighted and
APL seems to have very little website/newsgroup support. Thanks for you
help,
Justin Dubs
"Justin Dubs" <jtd...@eos.ncsu.edu> wrote in message
news:9nhhn5$g1o$1...@uni00nw.unity.ncsu.edu...
Alex Martelli
...
> I"ll dive into Haskell/Forth/Miranda/APL and see what I like. I also want
> to do a little Scheme and Eiffel at some point. Thanks a lot for the
> suggestions.
>
> Do I appear to be missing any categories of languages? I have the basic
OO,
> Functional, Scripting languages covered, I think. Thanks again guys,
If you dig into Haskell, I don't think you need Miranda too -- once
you know Haskell well you can peek at
http://www.cs.uwindsor.ca/help/on-line-docs/mira-paper.html and see if
Miranda has anything further, but I
strongly doubt you'll find anything really different. Rather, you might
look into ML, both Standard (SML) and French-dressing (OCAML) -- _they_
are quite different approaches to FP, being strict (non-lazy) by default
(and OCAML in particular has accreted lots of other stuff on top).
APL has basically evolved into J, as far as I know -- key difference
being that you don't need a special keyboard and font, but rather can
do APL'ish unreadable superpowerful oneliners with pure ASCII:-).
Sorry, I don't know where to find a J interpreter -- the funet.fi
archive seems empty, the one at Waterloo, disappeared... (?)
You appear to be missing the category of languages focused on
concurrency/distribution. Those and many other similar issues
are well covered in Mozart, http://www.mozart-oz.org/, which
appears to be a VERY interesting language/system.
I think you should also look into Dylan, http://www.gwydiondylan.org/.
It doesn't really introduce many deeply new concepts when compared
to Common Lisp (does ANY language?-), but it's wrapped in somewhat
conventional syntax and focuses on very specific, interesting issues --
multi-dispatching, optionally-static typing for performance, an
interestingly novel module-system, highly-hygienic macros.
Alex
Justin Dubs
Dylan looks mediocre. Nothing that shook my world. Interesting though.
OCaml for some reason just doesn't "do it for me." Not sure why. I'll
check out it's feature-set though.
Mozart on the other hand, look interesting. As does Haskell. I've always
thought about learning SML, maybe I'll check that one out too.
Oh, and as an aside, I've decided that I'm not thrilled with Eiffel either.
It seems like it has lots of interesting features, but that they would take
so much effort to use well that most programmers wouldn't bother. And if
you don't bother with the pre/post-conditions then why bother with Eiffel.
But maybe I'll change my mind.
Thank you all for the great advice. If anyone else knows of some languages
with anything radical about them, let me know. Thanks guys,
Justin Dubs
Alex Martelli
> Thank you. Great ideas. I'll pass on Miranda for now then.
>
> Dylan looks mediocre. Nothing that shook my world. Interesting though.
I think you should give it more of a try (they used to sell the
books on it at a very good price) -- pin down what you find wrong
with it. Multi-dispatching IS powerful, after all; and the
argument about advantages of optional static typing is heard
VERY often -- well, Dylan HAS that, so, why doesn't it 'click'...?
> OCaml for some reason just doesn't "do it for me." Not sure why. I'll
> check out it's feature-set though.
Doesn't do much for me either, and I *DO* know why: it strikes
me as the present-day equivalent of C++. Lots of paradigms more
or less jumbled together, lots of power (and speed!), syntax
somewhat haphazard. SML (and even more Haskell) strike me as
way more elegant.
And a very different way to merge OO with FP is O'Haskell, see
http://www.cs.chalmers.se/~nordland/ohaskell/ -- haven't really
used it, but, it DOES seem interesting.
> Mozart on the other hand, look interesting. As does Haskell. I've always
> thought about learning SML, maybe I'll check that one out too.
For completeness, I should mention Erlang -- it has a lot of
emphasis on distributed/concurrent programming, FP (single-
assignment), dynamic typing -- an interesting combination, and
I believe it's _the_ FP language on which most money is being
invested and made these days (both in Ericsson development,
and in other companies, such as one which was acquired by
Nortel about a year ago and whose name now escapes me).
> Oh, and as an aside, I've decided that I'm not thrilled with Eiffel
either.
Me neither. Sather used to be an interesting variation, pity it's
now "stabilized" (for which, read: "dead":-).
> It seems like it has lots of interesting features, but that they would
take
> so much effort to use well that most programmers wouldn't bother. And if
> you don't bother with the pre/post-conditions then why bother with Eiffel.
> But maybe I'll change my mind.
Pre/post conditions are the *GOOD* part (well, those and invariants:-).
For that you pay with the most rigid of typesystems (Haskell shows
what a completely compile-time safe, static typesystem should be --
Eiffel shows what it _shouldn't_ be:-), Meyers' many hobby-horses (any
function that returns a result must not have side effects), "impure"
generics (mixing signature-based AND type-based considerations -- pooh,
give me pure signature-based generics any day!-).
> Thank you all for the great advice. If anyone else knows of some
languages
> with anything radical about them, let me know. Thanks guys,
Thinking again of concurrency-centered languages, Occam used to be pretty
radical back in its time (I do believe it was also first to introduce
"whitespace as the only way to group statements" which we love so much
in Python:-). But I'm not sure where one would find a compiler and
interpreter today, or, for that matter, a transputer PC board:-).
Alex
Justin Dubs
news:9niei...@enews1.newsguy.com...
> "Justin Dubs" <jtd...@eos.ncsu.edu> wrote in message
> news:9ni3p0$rkn$1...@uni00nw.unity.ncsu.edu...
> > Thank you. Great ideas. I'll pass on Miranda for now then.
> >
> > Dylan looks mediocre. Nothing that shook my world. Interesting though.
>
> I think you should give it more of a try (they used to sell the
> books on it at a very good price) -- pin down what you find wrong
> with it. Multi-dispatching IS powerful, after all; and the
> argument about advantages of optional static typing is heard
> VERY often -- well, Dylan HAS that, so, why doesn't it 'click'...?
Now, I've only been looking at this language for a little bit now....
but.... it seems to me that Multi-dispatching is just a fancy new word for
polymorphism and more over is rather poorly implemented in Dylan. Hell, I
even prefer C++ over Dylan as far as polymorphism. Plus I find the overall
syntax just clunky and unappealing. The whole var :: <type> thing just
doesn't do it for me.
I'm new to the optional static typing. I'm familiar with the concept of
dynamic and static typing and suppose I can see the advantage in optional
static typing, but I'm very non-commital at this point. I'll need to do
some more reading and experimenting with it.
>
>
> > OCaml for some reason just doesn't "do it for me." Not sure why. I'll
> > check out it's feature-set though.
>
> Doesn't do much for me either, and I *DO* know why: it strikes
> me as the present-day equivalent of C++. Lots of paradigms more
> or less jumbled together, lots of power (and speed!), syntax
> somewhat haphazard. SML (and even more Haskell) strike me as
> way more elegant.
I would agree whole-heartedly.
>
> And a very different way to merge OO with FP is O'Haskell, see
> http://www.cs.chalmers.se/~nordland/ohaskell/ -- haven't really
> used it, but, it DOES seem interesting.
>
>
> > Mozart on the other hand, look interesting. As does Haskell. I've
always
> > thought about learning SML, maybe I'll check that one out too.
>
> For completeness, I should mention Erlang -- it has a lot of
> emphasis on distributed/concurrent programming, FP (single-
> assignment), dynamic typing -- an interesting combination, and
> I believe it's _the_ FP language on which most money is being
> invested and made these days (both in Ericsson development,
> and in other companies, such as one which was acquired by
> Nortel about a year ago and whose name now escapes me).
I checked out Erlang. It looks interested. I've got it bookmarked and will
do some more reading when I have some more time. Thanks for the idea.
Heh. Interesting. Thanks a lot for the great ideas.
Justin Dubs
Jon
<jtd...@eos.ncsu.edu> wrote:
> Ack. Can one of you guys point me in the right direction for some
> compiler/interpreters for Miranda or APL. I found the APL to C
> compiler, but I was hoping for an interpreter. Miranda seems to be
> copyrighted and APL seems to have very little website/newsgroup support.
> Thanks for you help,
>
APL is justly regarded as a language we don't need to know about any more
(mainly because modern keyboards don't have enough keys for it :-) )...
but just in case you are interested, take a look here:
A+ is a language grown out of APL, developed by people from Morgan
Stanley (the investment bank). There is a GPLed interpreter system which
you can download from that site.
--
If you are intested in even more esoteric languages, you might want to
look at the Cat's Eye Technologies website:
http://www.catseye.mb.ca/
part of which is a collection of esoteric programming language --
including two really beautiful ones: Befunge (2D source code), and
Brainf**k (minimalist and beautiful), as well as several horrible ones,
Intercal (the original obfuscated programming language) among them.
Brendan Hahn
>Ack. Can one of you guys point me in the right direction for some
>compiler/interpreters for Miranda or APL. I found the APL to C compiler,
>but I was hoping for an interpreter. Miranda seems to be copyrighted and
>APL seems to have very little website/newsgroup support. Thanks for you
>help,
There are a bunch of free APLs around, but they're not too well-supported
or easy to find. You should check out J at http://www.jsoftware.com
instead. J is the contemporary descendent of APL.
For interesting glimpses at a whole range of lesser-known languages and
programming models, look at the International Conference on Functional
Programming (ICFP) annual contests. ICFP has sponsored a programming
contest each of the last couple years: they propose a problem (decidedly
non-trivial ones), teams have a couple of days to submit solutions. Best
performer wins. The ICFP is naturally oriented towards functional
languages, but the contest is open to anything you care to write in.
Prizes have been awarded for solutions in J, ML, Haskell, Dylan... There's
a different web site for each year's contest, but if you just search for
"icfp contest 1998", 1999, and so on, you'll find it.
bh...@transoft.mmangle.net <-- unmangle address to reply
John J. Lee
> In article <9nhj3l$gqi$1...@uni00nw.unity.ncsu.edu>, "Justin Dubs"
> <jtd...@eos.ncsu.edu> wrote:
[...]
> APL is justly regarded as a language we don't need to know about any more
> (mainly because modern keyboards don't have enough keys for it :-) )...
> but just in case you are interested, take a look here:
>
> http://www.aplusdev.org/
>
> A+ is a language grown out of APL, developed by people from Morgan
> Stanley (the investment bank). There is a GPLed interpreter system which
> you can download from that site.
Ken Iverson, the designer of APL, went on to make J (which has no funny
symbols):
Yes, it still looks like line noise (this program, partly written by the
Iverson dynasty itself, was a runner-up in the ICFP functional programming
contest):
http://www.ai.mit.edu/extra/icfp-contest/j-source.txt
> If you are intested in even more esoteric languages, you might want to
> look at the Cat's Eye Technologies website:
>
> http://www.catseye.mb.ca/
>
> part of which is a collection of esoteric programming language --
> including two really beautiful ones: Befunge (2D source code), and
I think this guy wins *that* contest :-)
(the original page appears to be dead atm, this is the Google cache of it)
http://www.google.co.uk/search?q=cache:o8sP21nnd-Q:www.flourish.org/zbefunge.html+ZBefunge&hl=en
It's Befunge interpreter (and IDE, if you can believe that), written in
Inform, which itself compiles into Z-code, the format used by Infocom for
their text adventure games way back in prehistoric times. The web page
shows "ZBefunge, ironically running a simple text adventure".
On the question of more practical languages, there are several
logic-programming languages that are being actively developed at the
moment, both these look very interesting:
http://www.cs.mu.oz.au/research/mercury/
John
John J. Lee
[...]
> I think this guy wins *that* contest :-)
>
> (the original page appears to be dead atm, this is the Google cache of it)
> http://www.google.co.uk/search?q=cache:o8sP21nnd-Q:www.flourish.org/zbefunge.html+ZBefunge&hl=en
>
> It's Befunge interpreter (and IDE, if you can believe that), written in
> Inform, which itself compiles into Z-code, the format used by Infocom for
> their text adventure games way back in prehistoric times. The web page
> shows "ZBefunge, ironically running a simple text adventure".
Maybe I was wrong:
http://home.wanadoo.nl/wimrijnders/befunge/befbef2.bf
This claims to be a Befunge interpreter written in Befunge, but the string
you can see embedded in it would seem to suggest that's unlikely...
John
Alex Martelli
...
> Now, I've only been looking at this language for a little bit now....
> but.... it seems to me that Multi-dispatching is just a fancy new word for
> polymorphism and more over is rather poorly implemented in Dylan. Hell, I
A brief tirade in favour of multi-dispatching...:
It's runtime-polymorphism over an unlimited number of objects, rather
than over one object at a time. In any language that doesn't offer
it (i.e., any I've ever used, except for Lisp and Dylan), one often
finds oneself working around it with kludges &c -- just like one has
to do for even single-object polymorphism in non-OO languages.
Take a typical case. We have several kinds of objects (and more
kinds will be developed in the future) that need to render
themselves over several kinds of output-media (and more kinds
will be developed in the future). Basically, the typical,
elementary first example of polymorphism where 'shapes' render
themselves onto a canvas -- except that, instead of a 'canvas'
with a single (abstract) interface, we have a variety of kinds
of output media that is just as wide and bewildering as the
variety of objects needing rendering (and the latter are not
limited to just 'shapes' -- there's many more kinds).
How do we approach this in Python, C++, or other single-dispatch
OO language? Basically, we approach it with great difficulty,
through such kludges as the Visitor pattern, Martin's Acyclic
Visitor variation thereof, and other kinds of more or less
masqueraded *type-testing* (UGH!). The least-inelegant approach
I know is based on Protocol Adaptation (PEP 246 -- which nobody
important seems to think is as crucial as it looks to me!-),
but it's still at heart a moderately-softened typetesting-like
kludge. Basically, function render(renderable, outputmedium)
must have SOME "hard-wired" knowledge of possible varieties of
"kind of output interfaces" and try protocol-adaptation "in
parallel" over the renderable and outputmedium, from most desirable
match down to least desirable, until it finds a pair of protocols
(one to which the renderable can adapt, one to which the
outputmedium can adapt, and such that the two protocols match
each other) or, failing to find any match, gives up with some
appropriate exception about "there's no way this renderable can
render itself on this outputmedium". I put "hard-wired" in
quotes because one can rely on some registry of protocols and
protocol-matching functions, dynamically or persistently
updated as new kinds of objects and media are introduced. But
it still IS a kludge -- the language isn't supporting you in
any way, really... count yourself lucky if it isn't actively
_fighting_ you through static typing!-)
Multiple-dispatch languages put paid to all this. "render"
becomes a generic function, and specific ways to render a
renderable object of a certain kind onto an output medium
of some kind become specific methods implementing that
generic function. Whoever introduces new objects can add
the appropriate methods to render them onto known kinds of
output media -- and, vice versa, whoever introduces new
output media can add appropriate methods for known kinds of
objects to render themselves on those media. The need to
decide whether such methods "belong" to the renderable
object, or to the output medium, is totally artificial, just
as, say, the need to establish object ownership for purposes
of deletion is artificial in C++ and due to the lack of
built-in garbage-collection functionality in the language.
This is exactly the kind of thing that makes it worthwhile
to learn new languages -- exploring what IS possible in
programming, as opposed to what some given _language_ makes
it appear possible:-).
And the Dylan implementation looks fine to me in as far
as I've dug into it. What do you find wrong with it...?
> even prefer C++ over Dylan as far as polymorphism. Plus I find the
overall
> syntax just clunky and unappealing. The whole var :: <type> thing just
> doesn't do it for me.
I'm no fan of Dylan syntax, either. But syntax sugar is
never a crucial determinant for me.
> I'm new to the optional static typing. I'm familiar with the concept of
> dynamic and static typing and suppose I can see the advantage in optional
> static typing, but I'm very non-commital at this point. I'll need to do
> some more reading and experimenting with it.
It goes hand in hand with Dylan's dispatching strategy,
by the way. Any generic function is dispatched to some
specific method based on the most specific types that
the compiler is able to attribute to the objects that
are involved in the call -- the compiler can do some
type inference, but often you can help it by asserting
what you know to be true by design intent.
Your assertions can be used for error-checking (much
like 'assert' is in Python or C) but also, the compiler
can rely on them (whether it also doublechecks them,
or not) and compile efficient code for dispatching,
code that is based on types as precise as they can be.
A good runtime system can also take a trace of actual
types encountered at key points during a set of runs,
compare them with the types that could be determined
by compile-time type-inferencing alone, and SUGGEST
to you what type-annotations you could probably use
for better error-checking and/or better performance.
(I'm not sure if anything like this "good runtime" is
around for Dylan, but it's the kind of thing that you
were already able to find for _LISP_ over a decade
ago:-).
Type-issues don't exhaust programming one way or
another, mind you, and similar concepts (hints to
the compiler, expressing design intent, usable for
error checking AND for optimization) could well
also apply to issues that it would be very strained
to consider "type" issues. But, hey, it's a start!-)
> > For completeness, I should mention Erlang -- it has a lot of
> > emphasis on distributed/concurrent programming, FP (single-
> > assignment), dynamic typing -- an interesting combination, and
> > I believe it's _the_ FP language on which most money is being
> > invested and made these days (both in Ericsson development,
> > and in other companies, such as one which was acquired by
> > Nortel about a year ago and whose name now escapes me).
>
> I checked out Erlang. It looks interested. I've got it bookmarked and
will
> do some more reading when I have some more time. Thanks for the idea.
It definitely does look like a case of "and now for something
completely different" from the viewpoint of most other langs:-)
Alex
Justin Dubs
> "Justin Dubs" <jtd...@eos.ncsu.edu> wrote in message
> news:9nismr$fve$1...@uni00nw.unity.ncsu.edu...
...
>
> It's runtime-polymorphism over an unlimited number of objects, rather
> than over one object at a time. In any language that doesn't offer
> And the Dylan implementation looks fine to me in as far
> as I've dug into it. What do you find wrong with it...?
Ahhhhhh..... Thank you. I didn't spend enough time letting the concepts
sink in. Thanks for the great explanation. It makes sense now. That is
very useful. I still hate the dylan syntax, but the multi-dispatching makes
sense now. Thank you for the help.
Justin Dubs
Alex Martelli
You're welcome! Another characteristics of Dylan that we
see in Python 2.2 at last (although I'm not sure whether
Guido was aware of it or simply redesigned it anew) is a
cleverer ordering of bases in a multiple-inheritance case
where one or more base classes happen more than once (an
"inheritance diamond" or similar topologies), with support
for "walking" along bases classes in a systematic way
(although the latter, with the 'super' built-in, is still
rather syntactically unripe in Python 2.2 alpha 3, there IS
hope that it may be better integrated before 2.2 gets
released).
Let's give a classic example in Pythonic syntax (I share
your dislike for Dylan's syntax, though it falls well
short of "hate" in my case:-)...:
class Base:
def methodone(self): print "Base::methodone"
def methodtwo(self): print "Base::methodtwo"
class BetterOne(Base):
def methodone(self): print "a better methodone"
class BetterTwo(Base):
def methodtwo(self): print "a better methodtwo"
class BetterBoth(BetterOne, BetterTwo): pass
bb = BetterBoth()
bb.methodone()
bb.methodtwo()
Looks reasonable, right? Alas, in Python 2.1 and
earlier:
a better methodone
Base::methodtwo
The order in which classes are looked up when
searching for any bb attribute is:
BetterBoth, BetterOne, Base, BetterTwo
so Base.methodtwo HIDES the BetterTwo.methodtwo
we _thought_ we had overridden.
The identical sources still give the same
disapponing result in Python 2.2, for the usual
reason -- backwards compatibility. BUT just
change the first line to
class Base(object):
[or, any other built-in type can be used as
Base's base, but 'object' is, well, "neutral"...]
so that Base and its descendants don't have to
be "classic classes" anymore (with their many
backwards-compatibility restrictions), and...:
C:\>\python22\python bb.py
2.2a3 (#23, Sep 7 2001, 01:43:22) [MSC 32 bit (Intel)]
a better methodone
a better methodtwo
...exactly as one would hope!
The old ordering of class lookup can be
seen as left-first, depth-first, period.
Strictly speaking there's an extra Base
in the linearized lookup-ordered sequence
of bases, at the end (after BetterTwo),
but nothing is ever found there of course
(since an earlier instance of Base in the
sequence was searched before during the
lookup).
The new order can be seen as follows: start
with the old left-first, depth-first one:
BetterBoth, BetterOne, Base, BetterTwo, Base
but now, if any class appears more than once,
only keep the LAST appearance (while the old
"classic classes" rule boiled down to keeping
the FIRST appearance), to get:
BetterBoth, BetterOne, BetterTwo, Base
and THAT is exactly what we want in just about
all cases! It's also Dylan's algorithm, although
their way to frame things is different.
This "mro" (which I believe stands for "method
resolution order") is built ONCE when a class is
defined, for performance and clarity reasons
I guess, so we do lose in terms of dynamic
behavior (not for classic classes though:-).
But the gain is big, even aside from any kind
of performance considerations. I guess I
shall be inheriting more and more of my classes
from object, unless some other builtin type
appears more suitable:-). Apart from overriding
the right things, it also makes possible (via
super) the correct way of cooperation under
multiple inheritance, where a class may do a
bit of extra work in a method it overrides but
wants to delegate most of it to superclasses --
the super builtin makes it possible (currently
only with some syntactic kludgeing around:-) to
delegate to "whoever comes after me in mro",
which may be different classes in different multi
inheritance cases...
(Do note that Dylan has had the equivalent of
this for quite a few years:-).
If you do look into Dylan, one of its features
which I _don't_ like (an extensive, rich macro
framework) may perhaps help you work around the
syntax you detest so much. It's worth it for
mind-expansion purposes, I think, even if you
put it back on the shelf when you're done
absorbing its lessons -- just as, say, for
Haskell or Erlang. Gwydyon Dylan should be
OK for Macs, Unix/Linux/BSD, or Cygwin, while
funpro makes a subset of their commercial
offering (the complete language, just not the
rich extra libraries for COM access &c &c)
available for free under Windows. Who knows,
maybe if more Pythonistas get used to (and
fired up about:-) such features as multi-dispatch
and optional-typing, one day they'll be adding
them into the Python mainstream and we'll enjoy
those AND the joys of Python at once, just as
soon with Python 2.2 we'll be doing for clever
class ordering in multi-inheritance cases!-)
Alex
Garry Hodgson
> I"ll dive into Haskell/Forth/Miranda/APL and see what I like. I also want
> to do a little Scheme and Eiffel at some point. Thanks a lot for the
> suggestions.
>
> Do I appear to be missing any categories of languages? I have the basic OO,
> Functional, Scripting languages covered, I think. Thanks again guys,
you might look at erlang (www.erlang.org), an FP oriented toward
building
distributed systems. very slick.
--
Garry Hodgson One way or another
Senior Hacker One way or another
Software Innovation Services One way or another
AT&T Labs This darness got to give...
ga...@sage.att.com
Alex Martelli
...[about Dylan, mostly snipped]...
> Haskell or Erlang. Gwydyon Dylan should be
> OK for Macs, Unix/Linux/BSD, or Cygwin, while
> funpro makes a subset of their commercial
> offering (the complete language, just not the
> rich extra libraries for COM access &c &c)
> available for free under Windows. Who knows,
Just an update: on comp.os.linux.announce, I saw
a recent announcement by funpro that an alpha of
their version of Dylan (pretty rich-looking too)
is also available for Linux (they're working with
the Gwydyon people to cooperate on some of the
issues, they also say). I still prefer Python,
BUT I also still think Dylan is well worth looking
into -- one day we might borrow more of their good
stuff (as, in 2.2, we are doing for MRO -- I still
don't know whether Guido reinvented it or inspired
himself directly from the Dylan idea).
Alex
Albert Langer
> [...] Another characteristics of Dylan that we
> see in Python 2.2 at last (although I'm not sure whether
> Guido was aware of it or simply redesigned it anew) is a
> cleverer ordering of bases in a multiple-inheritance case
> where one or more base classes happen more than once (an
> "inheritance diamond" or similar topologies), with support
> for "walking" along bases classes in a systematic way
> (although the latter, with the 'super' built-in, is still
> rather syntactically unripe in Python 2.2 alpha 3, there IS
> hope that it may be better integrated before 2.2 gets
> released).
Guido references "Putting Metaclasses to Work" by Ira Forman
and Scott Danforth.
Also mentions that this relies on dynamically creating metaclasses
that are derived from the metaclasses of all the base classes and
this is too difficult for Python 2.2.
I tracked down some relevant papers (and java software) via Google, eg
at:
http://home.austin.rr.com/forman/ira/
These are useful for understanding the thinking behind Python 2.2
(though I imagine the book would be even more useful).
One of them mentions (p4) that "Similar arrangements of classes are
also used in CLOS[12], ObjVlisp[2], Dylan[1], and Pro-teus[16]."
http://www.parc.xerox.com/csl/groups/sda/projects/reflection96/docs/forman/forman.pdf
It isn't at all clear that this is specifically referring to the mro
for "diamonds".
Others mention that the mro is "depth first" but I still don't
understand this stuff well enough to be able to tell whether it
implies selecting the last repetition in a "diamond" rather than the
first. (This is certainly not very explicit as a result of the
dynamically derived metaclasses stuff and the
orientation towards java single inheritance).
Nevertheless I do recommend studying these papers (or the book) for
anyone else trying to understand the background. This stuff in 2.2 is
certainly going to have a major impact on how to do all sorts of
things and I would guess that a lot of the content of the book is also
in the various papers and tutorials.