FAQ

[Python] Python vs. Io

Daniel Ehrenberg
Jan 29, 2004 at 9:01 pm
Io (www.iolanguage.com) is a new programming language that's purely
object-oriented (but with prototypes), has a powerful concurrency
mechanism via actors, and uses an extremely flexible syntax because
all code is a modifiable message tree. Like Python, it is dynamically
typed, has a very clean syntax, produces short code, and is
excruciatingly slow (on the same level as eachother). Io has a unique
syntax combining Lisp's idea of functions for flow control with
traditional function syntax and smalltalk-like syntax to get slots of
objects. Io has no keywords and everything, even multiple lines of
code, can be used as an expression. Even as a beginner to Io, I was
able to write something in just 43 lines to let you do something like
this (and more) in Io:

each((key, value) in map(x=1, y=2, z=3),
write(key, ": ", value, "\n")
)

Neither the each function nor the map function were built in (Io has
other mechanisms for that kind of thing, but they are less efficient).
Can anyone show me how to so much as alias "for" to "each" in Python
or allow block syntax at all without hacking the C source code?

Io doesn't use __methods_with_this_annoying_syntax__ because nothing
is supposed to be for internal use only and there are only about three
functions that would cause a problem if overridden.

For embedding, Io doesn't have to use Py_ALL_CAPS, instead it just
uses IoCamelCase, which looks much better. Interfaces to C are much
more object oriented.

Many users of Io (myself included) have switched over from Python for
these reasons.

I guess there are still the obvious advantages of Python over Io,
including
*large community
*more bindings to stuff
*strict coding conventions
*inflexible so everything is the same
*no need to close blocks
But unless there are other problems, the first two go away soon
(considering that Io was first created just two years ago). The last
three are somewhat trivial and may even be to Io's advantage.

Daniel Ehrenberg
reply

Search Discussions

53 responses

  • John Roth at Jan 29, 2004 at 9:32 pm
    "Daniel Ehrenberg" <LittleDanEhren at yahoo.com> wrote in message
    news:711c7390.0401291301.3f95794 at posting.google.com...
    Can anyone show me how to so much as alias "for" to "each" in Python
    Without getting into the language wars, I think what you're looking
    for is called the Visitor Pattern (Design Patterns: GOF). It's actually
    trivial to implement as long as you're not looking for built-in support.

    Something like this works quite well in any object where you want
    to implement a visitor over a collection:

    class aCollection:
    def visit(self, instance):
    for x in self._collection:
    instance.visitor(x)
    return instance.result()

    The final call is a little more than the bare visitor pattern, but it
    allows the visitor instance to pass back a result so you can use
    it in expressions.

    A visitor then looks like this:

    class fubar:
    def __init__(self):
    self.whatever = 0
    def visitor(self, value):
    self.whatever += value
    def result(self):
    return self.whatever

    and you use it like this:

    ohWow = aCollection.visit(fubar())

    Unlike a block in, for example, Ruby, a visitor instance
    can be pre-initialized, it can have multiple methods and
    it can persist after being passed against the collection.

    Of course, you can use more complex data structures as well,
    see the compiler stuff for examples of the visitor pattern used
    over the Python Abstract Syntax Tree.

    The visitor pattern is also very useful for file system
    navigation; I use it consistently.

    John Roth
    Daniel Ehrenberg
  • Brian Kelley at Jan 29, 2004 at 9:57 pm

    John Roth wrote:
    "Daniel Ehrenberg" <LittleDanEhren at yahoo.com> wrote in message
    news:711c7390.0401291301.3f95794 at posting.google.com...

    Can anyone show me how to so much as alias "for" to "each" in Python

    Without getting into the language wars, I think what you're looking
    for is called the Visitor Pattern (Design Patterns: GOF). It's actually
    trivial to implement as long as you're not looking for built-in support.
    I think Daniel's example is a little bit more complicated than that. It
    resembles more closly the lisp-ish macros that were discussed to death a
    while ago.

    Note that in his code:
    each((key, value) in map(x=1, y=2, z=3),
    write(key, ": ", value, "\n")
    )

    key and value are variable names that get used inside the function call.

    Here is my pythonic(?) version, however it requries a lambda to bind the
    variable names.

    def map(**kw):
    return kw.items()

    def each(seq, func):
    for v in seq:
    apply(func, v)

    from sys import stdout
    write = stdout.write

    each(map(x=1,y=2,z=3),
    lambda key, value: write("%s: %s\n"%(key, value)))

    Brian
  • David M. Cooke at Jan 29, 2004 at 10:21 pm

    At some point, LittleDanEhren at yahoo.com (Daniel Ehrenberg) wrote:

    Io (www.iolanguage.com) is a new programming language that's purely
    object-oriented (but with prototypes), has a powerful concurrency
    mechanism via actors, and uses an extremely flexible syntax because
    all code is a modifiable message tree. Like Python, it is dynamically
    typed, has a very clean syntax, produces short code, and is
    excruciatingly slow (on the same level as eachother). Io has a unique
    syntax combining Lisp's idea of functions for flow control with
    traditional function syntax and smalltalk-like syntax to get slots of
    objects. Io has no keywords and everything, even multiple lines of
    code, can be used as an expression. Even as a beginner to Io, I was
    able to write something in just 43 lines to let you do something like
    this (and more) in Io:

    each((key, value) in map(x=1, y=2, z=3),
    write(key, ": ", value, "\n")
    )

    Neither the each function nor the map function were built in (Io has
    other mechanisms for that kind of thing, but they are less efficient).
    Can anyone show me how to so much as alias "for" to "each" in Python
    or allow block syntax at all without hacking the C source code?
    Hey, if I wanted to to, I could add functions and all that that would
    make Python look like Lisp, or IO, or whatever.

    But, why? If I wanted to write Lisp or Io, I'd use those.

    Your example I'd write in Python as

    for key, value in dict(x=1, y=2, z=3):
    print '%s: %s\n" % (key, value)

    I didn't have to write 43 lines of support code, and it's also two
    lines. I don't think "this isn't builtin" is a selling point -- you
    need a critical mass of builtins to make a language useful.
    Io doesn't use __methods_with_this_annoying_syntax__ because nothing
    is supposed to be for internal use only and there are only about three
    functions that would cause a problem if overridden.
    For embedding, Io doesn't have to use Py_ALL_CAPS, instead it just
    uses IoCamelCase, which looks much better. Interfaces to C are much
    more object oriented.
    Ok, these two points are window-dressing: minor spelling and
    punctuation issues (which seems to be what most language wars are about).

    Heck, use boost::python for C++ interfaces; those function names are
    even shorter. Or use pyrex to generate wrappers, writing them in a
    Pythonesque language.
    Many users of Io (myself included) have switched over from Python for
    these reasons.

    I guess there are still the obvious advantages of Python over Io,
    including
    *large community
    *more bindings to stuff
    Yep. That's a *big* difference, I'd say.
    *strict coding conventions
    *inflexible so everything is the same
    Can you elaborate a bit on why Python is inflexible? I find Python to
    be extremely flexible.
    *no need to close blocks
    But unless there are other problems, the first two go away soon
    (considering that Io was first created just two years ago). The last
    three are somewhat trivial and may even be to Io's advantage.
    Python is 14 years old, and it's still working on global domination;
    Io's got some catching up to do :-)

    --
    \/|<
    /--------------------------------------------------------------------------\
    David M. Cooke
    cookedm(at)physics(dot)mcmaster(dot)ca
  • Christopher Koppler at Jan 29, 2004 at 11:41 pm

    On Thu, 29 Jan 2004 17:21:19 -0500, cookedm+news at physics.mcmaster.ca (David M. Cooke) wrote:

    At some point, LittleDanEhren at yahoo.com (Daniel Ehrenberg) wrote:
    [snip-a-lot]
    For embedding, Io doesn't have to use Py_ALL_CAPS, instead it just
    uses IoCamelCase, which looks much better. Interfaces to C are much
    more object oriented.
    Ok, these two points are window-dressing: minor spelling and
    punctuation issues (which seems to be what most language wars are about).

    Heck, use boost::python for C++ interfaces; those function names are
    even shorter. Or use pyrex to generate wrappers, writing them in a
    Pythonesque language.
    Many users of Io (myself included) have switched over from Python for
    these reasons.

    I guess there are still the obvious advantages of Python over Io,
    including
    *large community
    *more bindings to stuff
    Yep. That's a *big* difference, I'd say.
    Using any language (other than a Lisp) which is sufficiently powerful
    mostly comes down to personal preference regarding syntax. Library and
    community support will of course grow for new languages if enough
    people find it 'fits their minds' better than anything previously
    available.
    *strict coding conventions
    *inflexible so everything is the same
    Can you elaborate a bit on why Python is inflexible? I find Python to
    be extremely flexible.
    If inflexibility means not being able to arbitrarily change the
    syntax, then I'm all for it, because it does help consistency and
    readability, which I like very much in my programs, especially when
    not working on them alone... Python seems to have found a good middle
    ground between strictness and dynamism.
    If I wanted a 'flexible' language, I'd use Lisp, or Forth.


    --
    Christopher
  • Daniel Ehrenberg at Jan 31, 2004 at 1:10 am

    Hey, if I wanted to to, I could add functions and all that that would
    make Python look like Lisp, or IO, or whatever.

    But, why? If I wanted to write Lisp or Io, I'd use those.

    Your example I'd write in Python as

    for key, value in dict(x=1, y=2, z=3):
    print '%s: %s\n" % (key, value)

    I didn't have to write 43 lines of support code, and it's also two
    lines. I don't think "this isn't builtin" is a selling point -- you
    need a critical mass of builtins to make a language useful.
    I know. Maybe in the future, it can be builtin, but it just shows how
    flexible Io is. Io has its own version of a for loop (in addition to
    being able to iterate directly over a dictionary or list) which in
    some cases makes more sense than Python's. It's like this:

    for(x, 1, 10, #goes through x with values 1-10
    write(x, "\n")
    )

    IMHO, this makes more sense than iterating over a list created just
    for a specific loop. On my computer, Io's loops are faster than
    Python's (probably because they are lazy).
    [stuff about size of communities and bindings to stuff]
    Yep. That's a *big* difference, I'd say.
    But the community will grow larger in time. The Io community is bigger
    than the Python community two years after Python was released
    (although that's probably because it wasn't publicly released for two
    years).
    Can you elaborate a bit on why Python is inflexible? I find Python to
    be extremely flexible.
    There's still a difference between types and classes in Python. Try
    this in Python:
    x = object()
    x.number = 5
    It raises an error. But the same thing in Io works (which is x :=
    Object clone; x number := 5). To do it in Python, you have to do
    class goodObject(object): pass
    x = goodObject()
    x.number = 5
    Also, Python has statements (as opposed to just expressions) even for
    the simplest things like writing things to the command line. In Io,
    flow control is in functions, which can be overwritten if you want to
    change them. The Python philosophy is that if you allow this and other
    flexible things to happen, you will have inconsistent code. If someone
    asks on the Tutor mailing list how to change that, everybody responds
    "Why would you want to do that?". While that's a valid viewpoint, it's
    not the most flexible.
    Python is 14 years old, and it's still working on global domination;
    Io's got some catching up to do :-)
    I don't think world domination is a practical goal for either
    language.

    Daniel Ehrenberg
  • Josiah Carlson at Jan 31, 2004 at 3:13 am

    IMHO, this makes more sense than iterating over a list created just
    for a specific loop. On my computer, Io's loops are faster than
    Python's (probably because they are lazy).
    Haven't you heard of xrange? It's like range, only without the list
    instantiation (and a few other things).

    But the community will grow larger in time. The Io community is bigger
    than the Python community two years after Python was released
    (although that's probably because it wasn't publicly released for two
    years).
    I would also be willing to bet that is due to the ease of distribution
    that the modern internet allows, coupled with the current geek-chic of
    learning new-better-than-ever languages. Heck, brainfuck probably has
    more users than Python did 2 years after its introduction, but that
    doesn't mean that you will be able to write programs that are better,
    more efficient, easier to update, easier to debug, etc., with BF than
    with some other newer language.

    Also, Python has statements (as opposed to just expressions) even for
    the simplest things like writing things to the command line. In Io,
    flow control is in functions, which can be overwritten if you want to
    change them. The Python philosophy is that if you allow this and other
    flexible things to happen, you will have inconsistent code. If someone
    asks on the Tutor mailing list how to change that, everybody responds
    "Why would you want to do that?". While that's a valid viewpoint, it's
    not the most flexible.
    Perhaps it isn't more flexible. On the other hand, it does allow anyone
    to read your code and know that there isn't any magical syntax that is
    usable on one Python x.y installation, that isn't on another.

    - Josiah
  • Daniel Ehrenberg at Jan 31, 2004 at 8:20 pm

    Perhaps it isn't more flexible. On the other hand, it does allow anyone
    to read your code and know that there isn't any magical syntax that is
    usable on one Python x.y installation, that isn't on another.

    - Josiah
    What are you talking about? There's tons of new "magical syntax" in
    Python. Examples for "magical syntax" features that don't work on
    1.5.2 include:
    *List comprehensions
    *String methods
    *Generators
    *Emulating numeric types
    *Nested scopes
    * * and ** in function declarations
    *for line in this_file
    *Subclassing types

    There's tons of stuff still being added to Python.

    Daniel Ehreberg
  • Jp Calderone at Jan 31, 2004 at 8:38 pm

    On Sat, Jan 31, 2004 at 12:20:52PM -0800, Daniel Ehrenberg wrote:
    Perhaps it isn't more flexible. On the other hand, it does allow anyone
    to read your code and know that there isn't any magical syntax that is
    usable on one Python x.y installation, that isn't on another.

    - Josiah
    What are you talking about? There's tons of new "magical syntax" in
    Python. Examples for "magical syntax" features that don't work on
    1.5.2 include:
    *List comprehensions Yep.
    *String methods
    Nope. The syntax is identical. Strings just happen to have more useful
    attributes new.
    *Generators Yep.
    *Emulating numeric types
    Nope. Never seen __coerce__? :)
    *Nested scopes
    Hmm. Not really a syntactic difference... The syntax is the same, after
    all, but the behavior is definitely different.
    * * and ** in function declarations Yep.
    *for line in this_file
    Nope. Same as with strings, the iterator protocol, a set of methods with
    a defined meaning, was added, and file objects were made to implement it.
    No syntactic changes.
    *Subclassing types
    This is another iffy one. The syntax is no different, the behavior has
    just been changed. "str", "int", etc, used to be builtin functions, not
    type objects. You also couldn't subclass types in Python, but if you could
    have, the syntax would have been identical to what it is today.
    There's tons of stuff still being added to Python.
    Definitely. But "stuff" isn't always the same as "magical syntax".

    Jp
  • Andrew Bennetts at Feb 1, 2004 at 1:35 am

    On Sat, Jan 31, 2004 at 03:38:02PM -0500, Jp Calderone wrote:
    On Sat, Jan 31, 2004 at 12:20:52PM -0800, Daniel Ehrenberg wrote:

    What are you talking about? There's tons of new "magical syntax" in
    Python. Examples for "magical syntax" features that don't work on
    1.5.2 include:
    [...]
    * * and ** in function declarations
    Yep.
    * and ** in function _calls_ is new in 2.0, but in declarations was already
    there in 1.5.2:

    bash-2.05b$ python1.5
    Python 1.5.2 (#0, Jul 5 2003, 11:45:08) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2
    Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
    def f(*args, **kwargs):
    ... print args, kwargs
    ...
    f('a', 'b', 'c', x=1, y=2, z=3)
    ('a', 'b', 'c') {'z': 3, 'x': 1, 'y': 2}
    >>>

    -Andrew.
  • Sean Ross at Jan 31, 2004 at 8:41 pm
    "Daniel Ehrenberg" <LittleDanEhren at yahoo.com> wrote in message
    news:711c7390.0401311220.763be80a at posting.google.com...
    [snip]
    there isn't any magical syntax that is
    usable on one Python x.y installation, that isn't on another.

    - Josiah
    What are you talking about?
    [snip]

    Syntax that can be used on one Python x.y.z installation, can
    be used on another installation of the _same_ version (x.y.z)
    of Python.
  • Paul Prescod at Feb 1, 2004 at 1:23 am
    I've always presumed that if I wanted an ultra-pure OO language I would
    use Smalltalk. Obviously IO's big difference is prototype rather than
    class-based inheritance. But that's a difference, not (necessarily) a
    benefit. Could you please describe what would attract one to IO over
    Smalltalk?

    Paul Prescod
  • Daniel Ehrenberg at Feb 1, 2004 at 2:22 am

    [snip]
    Definitely. But "stuff" isn't always the same as "magical syntax".

    Jp
    By that logic, anything that can be implimented in the language isn't
    "magical syntax". In Io, there is no difference between flow control
    and functions, so it's not "magical syntax" and it's just "stuff".

    Daniel Ehrenberg
  • Josiah Carlson at Feb 1, 2004 at 7:19 pm

    Daniel Ehrenberg wrote:

    Perhaps it isn't more flexible. On the other hand, it does allow anyone
    to read your code and know that there isn't any magical syntax that is
    usable on one Python x.y installation, that isn't on another.
    As mentioned by Sean Ross, I was talking about Python x.y compatibility
    with other copies of version x.y. With the way you describe IO, it
    encourages people to customize flow control and syntax. Such
    customization does not necessarily increase readability, usability, or
    write-once-run-anywhere with IO version u.v. It may also fragment the
    language in the long run into different camps; those that like the slim
    version, and those that like a version with every modification they can
    find.

    - Josiah
  • Daniel Ehrenberg at Feb 1, 2004 at 7:26 pm

    I've always presumed that if I wanted an ultra-pure OO language I would
    use Smalltalk. Obviously IO's big difference is prototype rather than
    class-based inheritance. But that's a difference, not (necessarily) a
    benefit. Could you please describe what would attract one to IO over
    Smalltalk?

    Paul Prescod
    In short, Io isn't as "ultra-pure" as Smalltalk. Here are some things
    that Io supports and Smalltalk doesn't:
    *Standard operator precedence
    *Normal function syntax
    *Standalone functions
    *Everything is public (like Python)
    *Interpreted and no monolithic system image like Smalltalk
    *Better block syntax (no cryptic square brackets or variable symbols)
    *Prototypes (which *is* a benefit, not just a difference)
    *Not obsessively object oriented (for stuff like flow control)
    *Growing, not shrinking community
    *Inplace mathematical operations
    *Much smaller implimentation and good for embedding
    *More flexible for syntax extension
    *Everything is anonymous (yet there is still some introspection for
    names)
    *Functions are first class objects, not merely messages
    *The ability to change what it inherets from
    *More flexible scoping
    *Writing self can be left out when sending messages to the current
    object
    *Speed on par with Python
    *Optionally non-strict functions (but usually strict anyway)

    Note that Python lacks some of these things too.

    Daniel Ehrenberg
  • Jeff Epler at Jan 31, 2004 at 4:14 pm

    On Fri, Jan 30, 2004 at 05:10:16PM -0800, Daniel Ehrenberg wrote:
    There's still a difference between types and classes in Python. Try
    this in Python:
    x = object()
    x.number = 5
    It raises an error. But the same thing in Io works (which is x :=
    Object clone; x number := 5). To do it in Python, you have to do
    class goodObject(object): pass
    x = goodObject()
    x.number = 5
    This is because instances of object don't have a __dict__, but instances
    of goodObject do. Says the new-style objects document:
    Instances of a class that uses __slots__ don't have a __dict__
    (unless a base class defines a __dict__); but instances of
    derived classes of it do have a __dict__, unless their class
    also uses __slots__.

    object has slots=[], effectively. The behavior is much like what you'll
    see in the example below:
    class S(object): __slots__ = ['x']
    class T(S): pass

    s = S()
    s.x = 1 # succeeds
    s.y = 2 # fails with exception

    t = T()
    t.y = 3 # succeeds

    Now, whether it's good to have __slots__ and __dict__ I can't tell you,
    but it's this wrinkle that caused the behavior you saw, not a
    "difference between types and classes".

    Jeff
  • Erik Max Francis at Jan 30, 2004 at 2:24 am

    Daniel Ehrenberg wrote:

    Neither the each function nor the map function were built in (Io has
    other mechanisms for that kind of thing, but they are less efficient).
    Can anyone show me how to so much as alias "for" to "each" in Python
    or allow block syntax at all without hacking the C source code?
    No, you cannot introduce new special forms (i.e., statement syntax) in
    Python without modifying the Python interpreter itself.

    There are two major camps in language design. One says that you should
    be able to modify the language itself to your will, and the other says
    that this gets rapidly confusing and you shouldn't. They're simply
    different camps, and the two camps won't agree. Furthermore, the
    ability to convert a language from the second camp to the first is not
    without difficulty; such things usually have to be designed into the
    language from the scratch, or you end up with a very complicated process
    of creating hygienic macros.

    This is a situation where Io is in the first camp and Python is in the
    second. They simply don't have equivalent goals; Python emphasizes
    transparency and readability more than customizability and flexibility,
    whereas Io does the opposite.
    Io doesn't use __methods_with_this_annoying_syntax__ because nothing
    is supposed to be for internal use only and there are only about three
    functions that would cause a problem if overridden.

    For embedding, Io doesn't have to use Py_ALL_CAPS, instead it just
    uses IoCamelCase, which looks much better. Interfaces to C are much
    more object oriented.
    These are really stylistic objections, as are the other objections you
    list below. That's completely fine, of course; you should choose a
    language that jives with your personal sense of language style. But
    language designers need to make decisions, and those decisions are
    necessarily going to eliminate some styles of programming, while
    emphasizing others.

    You're in a situation where it sounds like Io jives with your sense of
    style more than Python. That's perfectly fine, and I know from my own
    research that Io is a neat little language (though I haven't really used
    it for anything substantial yet). But you can't expect other languages
    to bend to your personal will and personal sense of style, particularly
    when it means necessarily violating someone else's corresponding senses.

    Io and Python have quite different fundamental approaches to language
    design, and so it's not surprising that there are going to be
    irreconcilable differences.

    --
    __ Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    \__/ The only completely consistent people are the dead.
    -- Aldous Huxley
  • Paul Prescod at Jan 30, 2004 at 3:22 am

    Daniel Ehrenberg wrote:

    Io (www.iolanguage.com) is a new programming language that's purely
    object-oriented (but with prototypes), has a powerful concurrency
    mechanism via actors, and uses an extremely flexible syntax because
    all code is a modifiable message tree.
    I long to live in a world where Python is considered a crufty incumbent
    legacy language that is forced on unwilling programmers by Pointy Haired
    Bosses. First, it would mean that Python has vanquished languages that
    programmers like less. Second, it would mean that the up-and-coming
    languages are so unbelievably cool and elegant that they make Python
    look like a lumbering dinosaur.

    Thanks for reminding me that that that day was once unfathomably far in
    the future and now seems almost around the corner!

    But when I look closer at IO it seems to me that the day is not as near
    as I hope. If you wish to hasten I urge you to:

    * finish the IO tutorial
    * distribute windows binaries of IO
    * make IO compilers to C and Java available
    * make bindings to popular windowing toolkits
    * make bindings to Java, .NET, COM, SOAP, XML-RPC etc.
    * use IO in a production context so that the rest of us can have faith
    in its stability
    * implement MySQL and Oracle bindings
    * publish some books on IO
    * point me to some documentation on how to launch and kill processes in IO

    If this were all done tomorrow I might be tempted to jump over to IO but
    I would be amazed if it were all done even two years from now.

    Also, an observation: IO's syntactic simplicity looks to me to be both a
    blessing and a curse.

    Paul Prescod
  • Jonathan Daugherty at Jan 30, 2004 at 3:31 am
    As other posts have indicated, this is not the io-user-list. While
    you probably have good, purely academic intentions with your post,
    this is not the correct forum. Create an io-vs-python list somewhere
    and I'm sure you'll get a few subscribers. :)

    --

    Jonathan Daugherty
    http://www.cprogrammer.org

    "It's a book about a Spanish guy called Manual, you should read it."
    -- Dilbert
  • Sean Ross at Jan 30, 2004 at 5:00 pm
    Hi.
    I took a look at Io because of your post, and I have a question:

    Are there prototype(?) _and_ instance methods/slots?

    In other words, is there a shared state mechanism between instances of a
    prototype?
    If so, could you show an example.

    Thanks,
    Sean
  • Daniel Ehrenberg at Jan 31, 2004 at 1:26 am
    "Sean Ross" <sross at connectmail.carleton.ca> wrote
    Hi.
    I took a look at Io because of your post, and I have a question:

    Are there prototype(?) _and_ instance methods/slots?

    In other words, is there a shared state mechanism between instances of a
    prototype?
    If so, could you show an example.

    Thanks,
    Sean
    I'm not sure how to tell you this so I'll just give a heavily
    commented example (comments in Io are with #, //, or /* */)

    parentProto := Object clone //makes parentProto a new object
    //:= is used for creating new variables
    parentProto shared := 5 //parentProto's new slot shared holds 5
    parentProto different := 6
    parentProto sum := method(shared + different) //self isn't necessary
    write("parentProto's sum: ", parentProto sum, "\n")
    x := parentProto clone //essentially new instance of parentProto
    y := parentProto clone
    x different = 2 //just updating slots is done with =.
    y different = 3
    write("first x sum ", x sum, "\n",
    "first y sum ", y sum, "\n")
    parentProto shared = 7 //should show up on all clones
    write("later x sum", x sum, "\n",
    "later y sum", y sum, "\n")

    Does that illustrate it well? I know the difference between := and =
    is annoying, but you'll get used to it, and it allows really cool
    things to be done with scopes and inheretance.

    Daniel Ehrenberg
  • Sean Ross at Jan 31, 2004 at 2:41 am
    "Daniel Ehrenberg" <LittleDanEhren at yahoo.com> wrote in message
    news:711c7390.0401301726.3e38da27 at posting.google.com...
    [snip example]
    Does that illustrate it well? I know the difference between := and =
    is annoying, but you'll get used to it, and it allows really cool
    things to be done with scopes and inheretance.
    I think I get the idea. Let's see:

    P = Object clone do( # saw do() used in iolanguage mail archive
    allocated = 0
    init = method(
    id := allocated # semi-colons required?
    allocated += 1
    )
    howMany = method(return allocated)
    )

    x := P clone
    y := P clone
    write("allocated? ", P howMany())
    # output ...
    # allocated? 2

    Correct?

    Thanks for making me aware of this language, it has some
    interesting ideas. I'm not annoyed by the difference between :=
    and =. I understand the issue(s) they're trying to solve: you don't
    need to declare local variables, or use self, explicitly. I don't have
    a problem with that. I imagine it could lead to subtle bugs (if you
    update a slot when you meant to set a new one), but that is only
    speculation on my part.

    I'm not a fan of the parenthesis (which might be expected from
    a Python user - love that significant whitespace ;). I'm also not a
    big fan of 'clone', I'd rather see 'new', but I do understand why
    'clone' is more apt. Of course, in this language, you could always
    just say

    Object new = Object getSlot("clone")
    P = Object new
    ...

    I can appreciate the flexibility of that.
  • Daniel Ehrenberg at Jan 31, 2004 at 7:34 pm

    I think I get the idea. Let's see:

    P = Object clone do( # saw do() used in iolanguage mail archive
    allocated = 0
    init = method(
    id := allocated # semi-colons required?
    allocated += 1
    )
    howMany = method(return allocated)
    )

    x := P clone
    y := P clone
    write("allocated? ", P howMany())
    # output ...
    # allocated? 2

    Correct?
    No, init and allocated should have used :=, even though init has
    special meaning. I don't really know why you have the howMany method
    since it doesn't really do anything (everything is public and methods
    can be called with just references), and all clones of P will
    dynamically inheret allocated. Also, when initializing variables,
    their scope must be specified (which is the whole reason for the
    difference between := and =), so id := allocated should probably be
    self id := allocated. self, along with a few other variables, is
    implicitly sent to all functions (and do).
    Thanks for making me aware of this language, it has some
    interesting ideas. I'm not annoyed by the difference between :=
    and =. I understand the issue(s) they're trying to solve: you don't
    need to declare local variables, or use self, explicitly. I don't have
    a problem with that. I imagine it could lead to subtle bugs (if you
    update a slot when you meant to set a new one), but that is only
    speculation on my part.
    Actually, the whole scoping model is really that you're working in
    transparent objects with inheretance, even for things like the global
    scope and the scope of functions.
    I'm not a fan of the parenthesis (which might be expected from
    a Python user - love that significant whitespace ;).
    At first I didn't like them easier, and with the syntax of most
    languages, there really isn't any advanatage, but Io code by
    convention can be much more dense (while still readible). For example,
    Io doesn't have a ternary operator (like Python), but the flow control
    function if can be used like one. For example:

    x := if(Nil, 1, 0)

    would set x to 0. Note that only Nil (and things that emulate Nil) are
    false in the context of if.
    I'm also not a
    big fan of 'clone', I'd rather see 'new', but I do understand why
    'clone' is more apt. Of course, in this language, you could always
    just say

    Object new = Object getSlot("clone")
    P = Object new
    ...

    I can appreciate the flexibility of that.
    Yeah, that is an advantage. That way of using 'new' will be inhereted
    dynamically for all objects.

    Daniel Ehrenberg
  • Sean Ross at Jan 31, 2004 at 8:28 pm
    "Daniel Ehrenberg" <LittleDanEhren at yahoo.com> wrote in message
    news:711c7390.0401311134.26cd0a11 at posting.google.com...
    [snip]
    (everything is public and methods
    can be called with just references),
    Okay. So, is there no way to have private attributes/operations?
    Or, like in Python, is there just a convention? "_slotName"

    [snip]
    Also, when initializing variables,
    their scope must be specified (which is the whole reason for the
    difference between := and =), so id := allocated should probably be
    self id := allocated. self, along with a few other variables, is
    implicitly sent to all functions (and do).
    Okay. So, if I set 'self id', like so

    self id := allocated

    and want to update it later in the same block I can use

    id = "updated self 'id' slot value"

    But, if I later use

    id := "set new local 'id' slot value"

    in the same block I get a new local variable. Is that how it works?
    Or does the first use of a slot determine its assignment scope
    for the duration of the block?

    self a := "unchanged"
    a := "changed"
    write("self a is ", self a) # changed or unchanged?
  • Daniel Ehrenberg at Feb 1, 2004 at 2:35 am

    Okay. So, if I set 'self id', like so

    self id := allocated

    and want to update it later in the same block I can use

    id = "updated self 'id' slot value"

    But, if I later use

    id := "set new local 'id' slot value"
    Yes, but code like that is confusing and shouldn't be used unless you
    need to.
    in the same block I get a new local variable. Is that how it works?
    Or does the first use of a slot determine its assignment scope
    for the duration of the block?

    self a := "unchanged"
    a := "changed"
    write("self a is ", self a) # changed or unchanged?
    unchanged.

    If you want to learn more about Io, you should probably join the Io
    mailing list instead of bothering the whole usenet thread. Its website
    is http://groups.yahoo.com/group/iolanguage/ .

    Daniel Ehrenberg
  • Josiah Carlson at Jan 31, 2004 at 3:10 am

    I'm not sure how to tell you this so I'll just give a heavily
    commented example (comments in Io are with #, //, or /* */)

    parentProto := Object clone //makes parentProto a new object
    //:= is used for creating new variables
    parentProto shared := 5 //parentProto's new slot shared holds 5
    parentProto different := 6
    parentProto sum := method(shared + different) //self isn't necessary
    write("parentProto's sum: ", parentProto sum, "\n")
    x := parentProto clone //essentially new instance of parentProto
    y := parentProto clone
    x different = 2 //just updating slots is done with =.
    y different = 3
    write("first x sum ", x sum, "\n",
    "first y sum ", y sum, "\n")
    parentProto shared = 7 //should show up on all clones
    write("later x sum", x sum, "\n",
    "later y sum", y sum, "\n")

    Does that illustrate it well? I know the difference between := and =
    is annoying, but you'll get used to it, and it allows really cool
    things to be done with scopes and inheretance.

    Daniel Ehrenberg
    After looking at your sample code, I couldn't help but say 'ick'. Maybe
    it is my C and Python background, but just putting a space between an
    object and its properties looks ugly. The use of method() also makes my
    skin crawl.

    It is cool that you dig on Io, and I wish you the best.

    - Josiah
  • Paul Prescod at Jan 31, 2004 at 5:40 pm

    Daniel Ehrenberg wrote:
    "Sean Ross" <sross at connectmail.carleton.ca> wrote \>
    I'm not sure how to tell you this so I'll just give a heavily
    commented example (comments in Io are with #, //, or /* */)

    parentProto := Object clone //makes parentProto a new object
    //:= is used for creating new variables
    parentProto shared := 5 //parentProto's new slot shared holds 5
    Do you know why the creator of IO decided not to use the now-ubiquitous
    "." operator? I don't know whether I can define a "." operator that has
    the appropriate behaviour but that wouldn't help anyhow.

    Paul Prescod
  • John Roth at Jan 31, 2004 at 7:37 pm
    "Paul Prescod" <paul at prescod.net> wrote in message
    news:mailman.1078.1075571238.12720.python-list at python.org...
    Daniel Ehrenberg wrote:
    "Sean Ross" <sross at connectmail.carleton.ca> wrote \>
    I'm not sure how to tell you this so I'll just give a heavily
    commented example (comments in Io are with #, //, or /* */)

    parentProto := Object clone //makes parentProto a new object
    //:= is used for creating new variables
    parentProto shared := 5 //parentProto's new slot shared holds 5
    Do you know why the creator of IO decided not to use the now-ubiquitous
    "." operator? I don't know whether I can define a "." operator that has
    the appropriate behaviour but that wouldn't help anyhow.
    As far as I know, since everything is a "message send", the dot
    is unnecessary. Every operation is either object.paremeter(s),
    or syntactic sugar that gets transformed into that format.

    John Roth
    Paul Prescod
  • Daniel Ehrenberg at Feb 1, 2004 at 2:08 am

    Do you know why the creator of IO decided not to use the now-ubiquitous
    "." operator? I don't know whether I can define a "." operator that has
    the appropriate behaviour but that wouldn't help anyhow.

    Paul Prescod
    In the opinion of the creators of Io, a space looked cleaner. Using a
    period looks kinda like you're finishing a sentence and starting a new
    one. Consider the following syntaxes:

    Dog barks //Io
    Dog.barks() #Python

    Regardless of which one is more common, which looks more like
    language?
    You say that "." is more ubiquitous, but "{}" is more ubiquitous than
    ":" by far, yet Python uses the latter and we don't complain. (note
    that in Io, unlike other languages with similar syntax such as Ruby,
    functions are first class objects.)

    Daniel Ehrenberg
  • Brian Quinlan at Feb 1, 2004 at 5:28 am

    Daneil Ehrenberg wrote:

    Dog barks //Io
    Dog.barks() #Python
    Interesting. I would never name a method like that because it is not
    immediately clear to me whether the method is imperative of interrogatory.

    The dog barks (Are you asking or telling the dog?)
    Bark dog (You are definitely telling the dog something)
    Dog, are you barking (You are definitely asking the dog)

    So I'd write:

    Dog barking
    Dog bark

    Cheers,
    Brian
  • Christopher Koppler at Feb 1, 2004 at 6:39 am

    On 31 Jan 2004 18:08:15 -0800, LittleDanEhren at yahoo.com (Daniel Ehrenberg) wrote:
    Do you know why the creator of IO decided not to use the now-ubiquitous
    "." operator? I don't know whether I can define a "." operator that has
    the appropriate behaviour but that wouldn't help anyhow.

    Paul Prescod
    In the opinion of the creators of Io, a space looked cleaner. Using a
    period looks kinda like you're finishing a sentence and starting a new
    one. Consider the following syntaxes:

    Dog barks //Io
    Dog.barks() #Python

    Regardless of which one is more common, which looks more like
    language?
    Looking like natural language is *not* necessarily a good thing in
    programming languages.

    --
    Christopher
  • Daniel Ehrenberg at Feb 1, 2004 at 6:42 pm

    Regardless of which one is more common, which looks more like
    language?
    Looking like natural language is *not* necessarily a good thing in
    programming languages.
    Ok, which one looks more intuitive, then? Both languages are
    turing-complete and Io's easy syntax doesn't hamper it in the way that
    BASIC's intuitive but limited syntax does.

    Daniel Ehrenberg
  • Paul Prescod at Feb 1, 2004 at 9:47 pm

    Daniel Ehrenberg wrote:
    ...

    In the opinion of the creators of Io, a space looked cleaner. Using a
    period looks kinda like you're finishing a sentence and starting a new
    one. Consider the following syntaxes:

    Dog barks //Io
    Dog.barks() #Python

    Regardless of which one is more common, which looks more like
    language?
    The space "operator" is used in way too many different ways in language.
    Consider these two grammatical sentences:

    The Dog barks. (how IO uses the space)
    The Dog Spot. (how Java/C/C++ use the space)

    But anyhow I'm not going to argue that IOs choice is wrong, just
    confusing at first.
    You say that "." is more ubiquitous, but "{}" is more ubiquitous than
    ":" by far, yet Python uses the latter and we don't complain. (note
    that in Io, unlike other languages with similar syntax such as Ruby,
    functions are first class objects.)
    First, if I had invented Python I would not have bothered to buck the
    trend of using curly braces. Hardly anyone chooses Python because of
    that feature and some are turned off by it. Python makes tons of
    conservative, "traditional" choices and I think that they do have
    something to do with its current level of popularity. Sometimes Python
    even hides pretty radical semantics under "traditional" syntax (e.g. []
    as sugar for getitem). Ruby takes this even farther. If I were in charge
    of IO I might do that too. e.g. make {} sugar for a last argument that
    is a statement list or something.

    Second, I think that the meaning of Python's colon is unuusal but
    self-evident. I personally decided to learn Python because I stumbled
    upon some code that looked exactly pseudo-code and wondered what
    language I was reading. Coming from (e.g.) Java or C++, most of Python's
    surfact syntax is self-evident to the English speaker, even when
    different (e.g. "or" instead of "||").

    Language design is like music composition. You must be better than your
    competitors but no so much better (i.e. different) that you just seem
    "weird". Judging the right balance is not easy.

    Paul Prescod
  • Andrew Henshaw at Feb 2, 2004 at 1:18 pm
    Paul Prescod wrote:

    ...snip...
    First, if I had invented Python I would not have bothered to buck the
    trend of using curly braces. Hardly anyone chooses Python because of
    that feature and some are turned off by it.
    ...snip...


    Not that this invalidates your point, as I still fall into the category of
    'hardly anyone'; but, the indentation-identified block is precisely the
    reason I first tried Python. Having used Occam for many years, I was very
    pleased to find a language that recognized the superiority of that style.


    --Andy
  • Terry Carroll at Feb 2, 2004 at 6:26 pm

    On Sun, 01 Feb 2004 13:47:20 -0800, Paul Prescod wrote:
    First, if I had invented Python I would not have bothered to buck the
    trend of using curly braces. Hardly anyone chooses Python because of
    that feature and some are turned off by it.
    I have to admit that the indentation feature turned me off at first, but
    having used Python for a while now, I find that method superior to the
    curly braces approach. Much more DWIM.
  • John Roth at Feb 2, 2004 at 9:10 pm
    "Paul Prescod" <paul at prescod.net> wrote in message
    news:mailman.1110.1075672228.12720.python-list at python.org...
    First, if I had invented Python I would not have bothered to buck the
    trend of using curly braces.
    I suppose I am hardly anyone else, since that it exactly what
    attracted me to Python. In fact, I will take partial responsibility
    for the indentaion syntax in IBM's ISPF mini-language - it's a
    preferance of long standing with me.

    Now that I actually have a significant language using them, I
    can see that there are a couple of things they make more
    difficult, statement syntax embedded within expressions being
    one. The other is a rather esoteric issue with clauses like
    elif, else and except.

    John Roth
    Paul Prescod

  • Paul Prescod at Feb 2, 2004 at 10:56 pm

    John Roth wrote:

    "Paul Prescod" <paul at prescod.net> wrote in message
    news:mailman.1110.1075672228.12720.python-list at python.org...
    First, if I had invented Python I would not have bothered to buck the
    trend of using curly braces.

    I suppose I am hardly anyone else, since that it exactly what
    attracted me to Python. In fact, I will take partial responsibility
    for the indentaion syntax in IBM's ISPF mini-language - it's a
    preferance of long standing with me.
    There are certainly costs and benefits to the Python way. And we've been
    over them many times. ;)

    I'm just saying that from a language popularity point of view,
    "different" is usually perceived as "worse" unless it is really vastly
    better.

    Paul Prescod
  • Donn Cave at Feb 1, 2004 at 6:18 pm

    Dog barks //Io
    Dog.barks() #Python
    Another thought about that: from the Python version, barks is
    evidently a function. Even if were a data attribute, I think
    in classical usage it would be a "message", and given that a
    class instance can implement its own attribute lookup, we may
    as well say that data attributes are simply functions with no
    extra parameters.

    So, how odd that anyone would think of putting the function
    AFTER the object. Did this come from Forth or something?

    In the above example it looks somewhat natural, but only
    because of a declarative flavor that is hardly the rule in
    OO programming. Take wl.append(w), for example - we're so
    used to this notation there's no point in asking if it would
    make more sense written append.wl(w), but if we're looking
    at a language that has taken a more lispish notation, I'd
    suggest "append wl w" is far more consonant with normal
    (not Forth) programming language notation.

    That leads to an interesting generalization. Take a common
    thorn out of Python's hide: "join sep wl". Is "join" a member
    function of sep, or a plain function? Well, who cares? If
    sep has a join function, it should apply in this case, but if
    not, there's a generic. In essence, all functions with 1 or
    more arguments are "member" functions - either of the class
    in which they're declared, or of the generic object class at
    the top of the object hierarchy.

    Donn Cave, donn at drizzle.com
  • Paul Prescod at Feb 1, 2004 at 9:06 pm

    Donn Cave wrote:
    Dog barks //Io
    Dog.barks() #Python
    ...

    So, how odd that anyone would think of putting the function
    AFTER the object. Did this come from Forth or something?
    Dog is not just the object. It is also the namespace that "barks" comes
    from. Both the computer and the human need to know the namespace before
    they can interpret the meaning of the string "barks" so it seems natural
    to me that it should come first. This is especially true in languages
    like Python and IO where two objects of even the same type could have
    different name->method mappings.

    Paul Prescod





    From http Sun Feb 1 22:17:07 2004
    From: http (Paul Rubin)
    Date: 01 Feb 2004 13:17:07 -0800
    Subject: OT: why do web BBS's and blogs get so slow?
    References: <7xbrojk9rk.fsf_-_@ruckus.brouhaha.com>
    <m2ad42342e.fsf@david-steuber.com>
    Message-ID: <7xad421ovg.fsf@ruckus.brouhaha.com>

    David Steuber <david.steuber at verizon.net> writes:
    1) It would be single threaded web server (asyncore, twistedmatrix)
    with a select loop talking to a socket, either on port 80 directly, or
    to a proxy web server running mod_gzip, SSL, and so forth.
    Is this how you would handle concurrency?
    Yes, it's a BBS, not a data mining system. There should be few if any
    long-running transactions. Maybe some occasional complicated requests
    would get spun off to a new thread or even just forked off. The
    server would run normal requests to completion before going on to the
    next request.
    Also, how bad is using files really? A decent Unix will use memory
    to cache files, abstracting disk io behind the scenes for you.
    Maybe. Using mmap does avoid a lot of system calls/context switches.
  • Daniel Ehrenberg at Feb 2, 2004 at 2:56 am

    Another thought about that: from the Python version, barks is
    evidently a function. Even if were a data attribute, I think
    in classical usage it would be a "message", and given that a
    class instance can implement its own attribute lookup, we may
    as well say that data attributes are simply functions with no
    extra parameters.

    So, how odd that anyone would think of putting the function
    AFTER the object. Did this come from Forth or something?

    In the above example it looks somewhat natural, but only
    because of a declarative flavor that is hardly the rule in
    OO programming. Take wl.append(w), for example - we're so
    used to this notation there's no point in asking if it would
    make more sense written append.wl(w), but if we're looking
    at a language that has taken a more lispish notation, I'd
    suggest "append wl w" is far more consonant with normal
    (not Forth) programming language notation.

    That leads to an interesting generalization. Take a common
    thorn out of Python's hide: "join sep wl". Is "join" a member
    function of sep, or a plain function? Well, who cares? If
    sep has a join function, it should apply in this case, but if
    not, there's a generic. In essence, all functions with 1 or
    more arguments are "member" functions - either of the class
    in which they're declared, or of the generic object class at
    the top of the object hierarchy.

    Donn Cave, donn at drizzle.com
    In your advocacy of Lisp over Forth (something completely unrelated to
    this thread and newsgroup), you miss the major selling point of object
    orientation: encapsulation. If you had barks(Dog) instead of
    Dog.bark() (I'm using Python not Io syntax for now), bark() is
    accessible to everyone, not just Dogs. So I could write bark(Cat),
    which shouldn't work. Also, some of your examples of things that are
    ambiguous really aren't ambiguous because neither Python nor any other
    language uses spaces both in the way they are used in Lisp and the way
    they are used in Smalltalk.

    Daniel Ehrenberg
  • Donn Cave at Feb 2, 2004 at 4:52 am
    Quoth LittleDanEhren at yahoo.com (Daniel Ehrenberg):
    ...
    In your advocacy of Lisp over Forth (something completely unrelated to
    this thread and newsgroup), My what?
    ... you miss the major selling point of object
    orientation: encapsulation. If you had barks(Dog) instead of
    Dog.bark() (I'm using Python not Io syntax for now), bark() is
    accessible to everyone, not just Dogs. So I could write bark(Cat),
    which shouldn't work.
    You're not only using Python syntax, you're using its rules
    for function namespaces, and that wasn't exactly what I had
    in mind.

    In Python, we know that obj.fun() looks for fun in obj, and we
    know the reverse is generally true - to invoke fun in obj, we
    write obj.fun(). But there are functions like repr or "+" that
    end up deferring to their parameters' member functions. When we
    write str(obj) instead of obj.str(), we're hopefully not kidding
    ourselves that there's some profound distinction between these two
    notations. Still less in a hypothetical language whose syntax
    is different.

    There are plenty of cases in anyone's Python code where a plain
    function could have been a method of its parameter, or vice versa,
    flip a coin. Why do I have to go through all my code and change
    flip(coin) to coin.flip(), or vice versa? It's an implementation
    detail that no one but the implementor should have to care about.

    Donn Cave, donn at drizzle.com
  • Donn Cave at Feb 2, 2004 at 6:21 am
    Quoth Paul Prescod <paul at prescod.net>:
    Donn Cave wrote:
    Dog barks //Io
    Dog.barks() #Python
    ...

    So, how odd that anyone would think of putting the function
    AFTER the object. Did this come from Forth or something?
    Dog is not just the object. It is also the namespace that "barks" comes
    from. Both the computer and the human need to know the namespace before
    they can interpret the meaning of the string "barks" so it seems natural
    to me that it should come first. This is especially true in languages
    like Python and IO where two objects of even the same type could have
    different name->method mappings.
    If as a human I need to know the namespace of a function to understand
    it, am I going to be confounded if a function defined in SGMLParser
    appears to be invoked on an instance of HTMLParser? Well, honestly
    that kind of thing can sometimes be a source of frustration, but in
    principle we prefer to consider it a virtue of the system, right?

    Taking the "feed" function there, for example -
    parser.feed(data)

    In principle, it already could be one of
    HTMLParser.feed
    SGMLParser.feed
    ParserBase.feed
    object.feed

    and this is fine, we're not supposed to have a problem with it.
    But if the feed function had been outside this hierarchy, we would
    be writing instead
    feed(parser, data)

    Why isn't that a violation of the object abstraction? Simply make
    it generic and let the above notation serve in either case, and you
    don't have to know the implementation in order to use it.

    Now I'll admit that this level of abstraction does pose a problem
    with scope and legibility, and that might have to be addressed.
    My point though is that we already accept this problem as a cost
    of doing OO business, so it's kind of surprising to me that OO
    languages invariably stop there, instead of going all the way.
    They'll proudly declare that `everything is an object', but don't
    wonder about the distinction between functions and methods.

    Once you get far enough down the path that you have `languages
    like Python and IO', you have some semantics that would be an
    awkward fit here. Two objects of the same could have different
    name->method mappings, indeed. But it's far from obvious that
    this is even a good thing, let alone the obvious evolution of OOP.

    Donn Cave, donn at drizzle.com


    From nomail Mon Feb 2 08:00:59 2004
    From: nomail (BG)
    Date: Mon, 2 Feb 2004 08:00:59 +0100
    Subject: bsddb.dbshelve problem unpickling objects from another directory
    References: <401d7d15$0$3257$58c7af7e@news.kabelfoon.nl>
    <bvk2t3$q5h$1@news.service.uci.edu>
    Message-ID: <401df5c2$0$3244$58c7af7e@news.kabelfoon.nl>

    Josiah,

    Thank you for your quick answer. But, this very much limits the way
    persistent objects can be used. Objects can apparently only be used in the
    context they were created. There is a logic to this, but it is also strange
    to me. Is there a way that upickled objects can also be used outside there
    original context?

    Berry.

    "Josiah Carlson" <jcarlson at nospam.uci.edu> schreef in bericht
    news:bvk2t3$q5h$1 at news.service.uci.edu...
    BG wrote:
    I am experimenting with dbshelve in Python 2.3.3 on Win2k. The problem
    is
    that objects put into the dbshelve by a script in one directory cannot
    be
    unpickled by script running in another directory. Why?

    I am writing my own collection called testcollection to hold testitems.
    The
    testcollection uses dbshelve to store its items to disk. I want design a
    package called testmodules.
    [snip]

    Pickled objects reference the module and the class from which they were
    created from.
    When running testmodules/test.py, testitem lives in in the module testitem.
    When running test.py, testitem lives in the module testmodules.testitem.


    - Josiah
  • Kylotan at Feb 2, 2004 at 11:48 pm
    "Donn Cave" <donn at drizzle.com> wrote in message news:<1075702864.490920 at yasure>...
    But if the feed function had been outside this hierarchy, we would
    be writing instead
    feed(parser, data)

    Why isn't that a violation of the object abstraction? Simply make
    it generic and let the above notation serve in either case, and you
    don't have to know the implementation in order to use it.

    Now I'll admit that this level of abstraction does pose a problem
    with scope and legibility, and that might have to be addressed.
    My point though is that we already accept this problem as a cost
    of doing OO business, so it's kind of surprising to me that OO
    languages invariably stop there, instead of going all the way.
    They'll proudly declare that `everything is an object', but don't
    wonder about the distinction between functions and methods.
    From my point of view (C++ and general OOP background) this comes down
    to access privileges and the visible implications of the code.

    feed(parser, data) implies that feed has equal access privileges to
    both parser and data, and that parser and data are unchanged by the
    operation. It's vaguely saying "I want something to happen based on
    parser and data".

    parser.feed(data) implies that feed has enhanced access privileges to
    parser compared to its access to data. In particular it implies that
    parser maintains some sort of state and that data is just an argument.
    It's saying "I want parser to do something based on data".

    In Python this is mainly just a semantic issue since you don't have
    the rigorous public/private/protected system that C++ does. But it
    does usually provide useful hints as to what the main object in any
    given interaction is. (ie. distinguishing between controller and
    entity classes, in UML terms.) Of course, it's entirely a religious
    matter in much the same way as arguing for a clear distinction between
    functions and subroutines would be. Just different ways of looking at
    it to suit different thought processes.

    --
    Ben Sizer
  • Donn Cave at Feb 3, 2004 at 12:28 am
    In article <153fa67.0402021548.6c5e394 at posting.google.com>,
    kylotan at hotmail.com (Kylotan) wrote:
    "Donn Cave" <donn at drizzle.com> wrote in message
    news:<1075702864.490920 at yasure>...
    But if the feed function had been outside this hierarchy, we would
    be writing instead
    feed(parser, data)

    Why isn't that a violation of the object abstraction? Simply make
    it generic and let the above notation serve in either case, and you
    don't have to know the implementation in order to use it.
    From my point of view (C++ and general OOP background) this comes down
    to access privileges and the visible implications of the code.

    feed(parser, data) implies that feed has equal access privileges to
    both parser and data, and that parser and data are unchanged by the
    operation. It's vaguely saying "I want something to happen based on
    parser and data".

    parser.feed(data) implies that feed has enhanced access privileges to
    parser compared to its access to data. In particular it implies that
    parser maintains some sort of state and that data is just an argument.
    It's saying "I want parser to do something based on data".

    In Python this is mainly just a semantic issue since you don't have
    the rigorous public/private/protected system that C++ does. But it
    does usually provide useful hints as to what the main object in any
    given interaction is. (ie. distinguishing between controller and
    entity classes, in UML terms.) Of course, it's entirely a religious
    matter in much the same way as arguing for a clear distinction between
    functions and subroutines would be. Just different ways of looking at
    it to suit different thought processes.
    I think that's what I meant by violating the abstraction.
    Aren't these issues only for the author of the parser?
    Why do you want to know what privileges feed has with
    one parameter vs. another? Isn't it enough that it works?

    Donn Cave, donn at drizzle.com
  • Jonathan Daugherty at Feb 3, 2004 at 12:48 am
    Not to dampen spirits, but I believe this thread has gone on long
    enough and is by this point very OT.

    Thanks.

    --

    Jonathan Daugherty
    http://www.cprogrammer.org

    "It's a book about a Spanish guy called Manual, you should read it."
    -- Dilbert
  • Daniel Ehrenberg at Feb 1, 2004 at 11:26 pm

    As other posts have indicated, this is not the io-user-list. While
    you probably have good, purely academic intentions with your post,
    this is not the correct forum. Create an io-vs-python list somewhere
    and I'm sure you'll get a few subscribers. :)
    Io vs. Python is a very narrow topic and not fit for a mailing list.
    There have been many repetitive Python vs. Ruby threads and nobody
    made this complaint. When somebody asks a question about using the
    Zope CMF, people don't say "go make a zope-cmf mailing list", they
    give a constructive response.

    Daniel Ehrenberg
  • A. Lloyd Flanagan at Feb 2, 2004 at 3:30 pm
    LittleDanEhren at yahoo.com (Daniel Ehrenberg) wrote in message news:<711c7390.0401291301.3f95794 at posting.google.com>...
    Can anyone show me how to so much as alias "for" to "each" in Python
    or allow block syntax at all without hacking the C source code?
    I think the point is, why on earth would you want to do something like
    that? If you want a language you can use to make programs that make
    no sense to anyone but the author, Perl should be more than sufficient
    for your needs.
  • Hannu Kankaanp?? at Feb 2, 2004 at 9:17 pm
    alloydflanagan at comcast.net (A. Lloyd Flanagan) wrote in message news:<e838aa6e.0402020730.3d45c9b1 at posting.google.com>...
    LittleDanEhren at yahoo.com (Daniel Ehrenberg) wrote in message news:<711c7390.0401291301.3f95794 at posting.google.com>...
    Can anyone show me how to so much as alias "for" to "each" in Python
    or allow block syntax at all without hacking the C source code?
    I think the point is, why on earth would you want to do something like
    that? If you want a language you can use to make programs that make
    no sense to anyone but the author, Perl should be more than sufficient
    for your needs.
    The point is that implementing your own "for" is something you can't
    do in Python very nicely, so it's a proof that Io can achieve
    genuinely higher abstraction levels on this part. Implementing
    "for" again with a new name probably wouldn't make anyone
    happy, but such power opens a set of tricks and idioms to
    be used in real code to solve real problems, that wouldn't
    be possible in Python without kludgy syntax.

    Here's a normal loop:

    bar = 0
    for x in range(10):
    bar += x

    Here's the same using a custom loop:

    bar = [0]
    def temp(x):
    bar[0] += x
    for_each(range(10), temp)

    That is just so damn ugly. I want to be able to define (e.g.)

    bar = 0
    for_each(x, range(10)):
    bar += x

    Now tell me which of these two lowermost forms looks
    better and makes more sense? For examples that don't
    just make aliases of existing syntax, see the
    Lisp vs Python thread that was here a few months ago
    (sorry, can't remember it's topic name).

    BTW, Python can be used to make programs that make
    no sense as well. (due to Ulf Bartelt:)

    print (lambda Ru,Ro,Iu,Io,IM,Sx,Sy:reduce(lambda x,y:x+y,map(lambda y,
    Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,Sy=Sy,L=lambda yc,Iu=Iu,Io=Io,Ru=Ru,Ro=Ro,i=IM,
    Sx=Sx,Sy=Sy:reduce(lambda x,y:x+y,map(lambda x,xc=Ru,yc=yc,Ru=Ru,Ro=Ro,
    i=i,Sx=Sx,F=lambda xc,yc,x,y,k,f=lambda xc,yc,x,y,k,f:(k<=0)or (x*x+y*y
    =4.0) or 1+f(xc,yc,x*x-y*y+xc,2.0*x*y+yc,k-1,f):f(xc,yc,x,y,k,f):chr(
    64+F(Ru+x*(Ro-Ru)/Sx,yc,0,0,i)),range(Sx))):L(Iu+y*(Io-Iu)/Sy),range(Sy
    ))))(-2.1, 0.7, -1.2, 1.2, 30, 80, 24)

    The real question is if the language *allows* a sensible
    programmer to write clear, understandable code even in hard
    problem domains.

    But this is nothing but my humble opinion without actually
    knowing anything about Io.. Maybe it isn't that good. I wasn't
    really arguing for Io but for better abstractions.
  • Daniel Ehrenberg at Feb 3, 2004 at 1:29 am

    I think the point is, why on earth would you want to do something like
    that? If you want a language you can use to make programs that make
    no sense to anyone but the author, Perl should be more than sufficient
    for your needs.
    Nobody uses Perl because they like its illegibility, they think (for
    some reason) that it's more powerful.
    As for the flexibility of Io, there's a big difference between
    flexibility and illegibility. Whenever a new, more powerful
    programming language comes out, everybody says it's too flexible.
    Fortran people were saying that about C, C people were saying it about
    C++ and Java, and C++ and Java people are still saying it about
    Python. Dynamic typing? That's so error-prone, they say. Flexible
    block syntax? Code is "illegible", you say.

    Daniel Ehrenberg
  • Erik Max Francis at Feb 3, 2004 at 2:25 am

    Daniel Ehrenberg wrote:

    Whenever a new, more powerful
    programming language comes out, everybody says it's too flexible.
    Fortran people were saying that about C, C people were saying it about
    C++ and Java, ...
    C people were saying that about Java?

    Look, you like Io better than Python. Fine. You're not going to be
    convincing others that you're right by simply repeating it over and over
    again. Io and Python cater to different styles; if your personal style
    is more in sync with Io, then so be it. But someone whose personal
    style is more in sync with Python than Io is simply not going to be
    swayed by your largely stylistic arguments.

    --
    __ Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    \__/ I just want to create my own life. I can just be me.
    -- Ekene Nwokoye
  • Dang Griffith at Feb 2, 2004 at 4:00 pm

    On 29 Jan 2004 13:01:06 -0800, LittleDanEhren at yahoo.com (Daniel Ehrenberg) wrote: ...
    Can anyone show me how to so much as alias "for" to "each" in Python
    or allow block syntax at all without hacking the C source code? ...
    Many users of Io (myself included) have switched over from Python for
    these reasons.
    If you've switch from Python to Io, what will you do with the answers
    to these questions? Use them for good or evil? Will you switch back
    from Io to Python?
    --dang

Related Discussions