[Python] Python vs. Io

Io (www.iolanguage.com) is a new programming language that's purelyobject-oriented (but with prototypes), has a powerful concurrencymechanism via actors, and uses an extremely flexible syntax becauseall code is a modifiable message tree. Like Python, it is dynamicallytyped, has a very clean syntax, produces short code, and isexcruciatingly slow (on the same level as eachother). Io has a uniquesyntax combining Lisp's idea of functions for flow control withtraditional function syntax and smalltalk-like syntax to get slots ofobjects. Io has no keywords and everything, even multiple lines ofcode, can be used as an expression. Even as a beginner to Io, I wasable to write something in just 43 lines to let you do something likethis (and more) in Io:

Neither the each function nor the map function were built in (Io hasother 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 Pythonor allow block syntax at all without hacking the C source code?

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

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

Many users of Io (myself included) have switched over from Python forthese 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 blocksBut unless there are other problems, the first two go away soon(considering that Io was first created just two years ago). The lastthree are somewhat trivial and may even be to Io's advantage.

Search Discussions

John Roth"Daniel Ehrenberg" wrote in message news:711c7390.0401291301.3f95794 at posting.google.com... 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:

"Daniel Ehrenberg" <LittleDanEhren at yahoo.com> wrote in messagenews: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 lookingfor is called the Visitor Pattern (Design Patterns: GOF). It's actuallytrivial to implement as long as you're not looking for built-in support.

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

Brian KelleyI 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)

John Roth wrote:"Daniel Ehrenberg" <LittleDanEhren at yahoo.com> wrote in messagenews: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 lookingfor is called the Visitor Pattern (Design Patterns: GOF). It's actuallytrivial 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. Itresembles more closly the lisp-ish macros that were discussed to death awhile ago.

David M. CookeHey, 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. Ok, these two points

Io (www.iolanguage.com) is a new programming language that's purelyobject-oriented (but with prototypes), has a powerful concurrencymechanism via actors, and uses an extremely flexible syntax becauseall code is a modifiable message tree. Like Python, it is dynamicallytyped, has a very clean syntax, produces short code, and isexcruciatingly slow (on the same level as eachother). Io has a uniquesyntax combining Lisp's idea of functions for flow control withtraditional function syntax and smalltalk-like syntax to get slots ofobjects. Io has no keywords and everything, even multiple lines ofcode, can be used as an expression. Even as a beginner to Io, I wasable to write something in just 43 lines to let you do something likethis (and more) in Io:

Neither the each function nor the map function were built in (Io hasother 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 Pythonor 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 wouldmake 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 twolines. I don't think "this isn't builtin" is a selling point -- youneed a critical mass of builtins to make a language useful.

Io doesn't use __methods_with_this_annoying_syntax__ because nothingis supposed to be for internal use only and there are only about threefunctions that would cause a problem if overridden. For embedding, Io doesn't have to use Py_ALL_CAPS, instead it justuses IoCamelCase, which looks much better. Interfaces to C are muchmore object oriented.

Ok, these two points are window-dressing: minor spelling andpunctuation issues (which seems to be what most language wars are about).

Heck, use boost::python for C++ interfaces; those function names areeven shorter. Or use pyrex to generate wrappers, writing them in aPythonesque language.

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

I guess there are still the obvious advantages of Python over Io,including*large community*more bindings to stuffYep. 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 tobe extremely flexible.

*no need to close blocksBut unless there are other problems, the first two go away soon(considering that Io was first created just two years ago). The lastthree 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 :-)

Christopher Koppler[snip-a-lot] 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. 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

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

Ok, these two points are window-dressing: minor spelling andpunctuation issues (which seems to be what most language wars are about).

Heck, use boost::python for C++ interfaces; those function names areeven shorter. Or use pyrex to generate wrappers, writing them in aPythonesque language.

Many users of Io (myself included) have switched over from Python forthese 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 powerfulmostly comes down to personal preference regarding syntax. Library andcommunity support will of course grow for new languages if enoughpeople find it 'fits their minds' better than anything previouslyavailable.

*strict coding conventions*inflexible so everything is the same

Can you elaborate a bit on why Python is inflexible? I find Python tobe extremely flexible.

If inflexibility means not being able to arbitrarily change thesyntax, then I'm all for it, because it does help consistency andreadability, which I like very much in my programs, especially whennot working on them alone... Python seems to have found a good middleground between strictness and dynamism.If I wanted a 'flexible' language, I'd use Lisp, or Forth.

Daniel EhrenbergI 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

Hey, if I wanted to to, I could add functions and all that that wouldmake 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 twolines. I don't think "this isn't builtin" is a selling point -- youneed a critical mass of builtins to make a language useful.

I know. Maybe in the future, it can be builtin, but it just shows howflexible Io is. Io has its own version of a for loop (in addition tobeing able to iterate directly over a dictionary or list) which insome cases makes more sense than Python's. It's like this:

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

IMHO, this makes more sense than iterating over a list created justfor a specific loop. On my computer, Io's loops are faster thanPython'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 biggerthan the Python community two years after Python was released(although that's probably because it wasn't publicly released for twoyears).

Can you elaborate a bit on why Python is inflexible? I find Python tobe extremely flexible.

There's still a difference between types and classes in Python. Trythis 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): passx = goodObject()x.number = 5

Also, Python has statements (as opposed to just expressions) even forthe simplest things like writing things to the command line. In Io,flow control is in functions, which can be overwritten if you want tochange them. The Python philosophy is that if you allow this and otherflexible things to happen, you will have inconsistent code. If someoneasks 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'snot 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 eitherlanguage.

Josiah CarlsonHaven't you heard of xrange? It's like range, only without the list instantiation (and a few other things). 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

IMHO, this makes more sense than iterating over a list created justfor a specific loop. On my computer, Io's loops are faster thanPython's (probably because they are lazy).

Haven't you heard of xrange? It's like range, only without the listinstantiation (and a few other things).

But the community will grow larger in time. The Io community is biggerthan the Python community two years after Python was released(although that's probably because it wasn't publicly released for twoyears).

I would also be willing to bet that is due to the ease of distributionthat the modern internet allows, coupled with the current geek-chic oflearning new-better-than-ever languages. Heck, brainfuck probably hasmore users than Python did 2 years after its introduction, but thatdoesn't mean that you will be able to write programs that are better,more efficient, easier to update, easier to debug, etc., with BF thanwith some other newer language.

Also, Python has statements (as opposed to just expressions) even forthe simplest things like writing things to the command line. In Io,flow control is in functions, which can be overwritten if you want tochange them. The Python philosophy is that if you allow this and otherflexible things to happen, you will have inconsistent code. If someoneasks 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'snot the most flexible.

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

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

- Josiah

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

Jp CalderoneNope. The syntax is identical. Strings just happen to have more useful attributes new. Hmm. Not really a syntactic difference... The syntax is the same, after all, but the behavior is definitely different. 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. This is another iffy one. The syntax is no different, the behavior has just been changed. "str", "int", etc, used to be

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 anyoneto read your code and know that there isn't any magical syntax that isusable on one Python x.y installation, that isn't on another.

- Josiah

What are you talking about? There's tons of new "magical syntax" inPython. Examples for "magical syntax" features that don't work on1.5.2 include:*List comprehensions Yep.*String methods

Nope. The syntax is identical. Strings just happen to have more usefulattributes new.

Hmm. Not really a syntactic difference... The syntax is the same, afterall, 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 witha 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 hasjust been changed. "str", "int", etc, used to be builtin functions, nottype objects. You also couldn't subclass types in Python, but if you couldhave, the syntax would have been identical to what it is today.

Sean Ross"Daniel Ehrenberg" wrote in message news:711c7390.0401311220.763be80a at posting.google.com... [snip] [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 PrescodI'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

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

Daniel EhrenbergBy 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

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

Josiah CarlsonAs 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

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

As mentioned by Sean Ross, I was talking about Python x.y compatibilitywith other copies of version x.y. With the way you describe IO, itencourages people to customize flow control and syntax. Suchcustomization does not necessarily increase readability, usability, orwrite-once-run-anywhere with IO version u.v. It may also fragment thelanguage in the long run into different camps; those that like the slimversion, and those that like a version with every modification they canfind.

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

Paul Prescod

In short, Io isn't as "ultra-pure" as Smalltalk. Here are some thingsthat 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 fornames)*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 currentobject*Speed on par with Python*Optionally non-strict functions (but usually strict anyway)

Jeff EplerThis 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 #

On Fri, Jan 30, 2004 at 05:10:16PM -0800, Daniel Ehrenberg wrote:There's still a difference between types and classes in Python. Trythis 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): passx = goodObject()x.number = 5

This is because instances of object don't have a __dict__, but instancesof 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 ofderived classes of it do have a __dict__, unless their classalso uses __slots__.

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

s = S()s.x = 1 # succeedss.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".

Erik Max FrancisNo, 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

Neither the each function nor the map function were built in (Io hasother 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 Pythonor allow block syntax at all without hacking the C source code?

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

This is a situation where Io is in the first camp and Python is in thesecond. They simply don't have equivalent goals; Python emphasizestransparency and readability more than customizability and flexibility,whereas Io does the opposite.

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

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

These are really stylistic objections, as are the other objections youlist below. That's completely fine, of course; you should choose alanguage that jives with your personal sense of language style. Butlanguage designers need to make decisions, and those decisions arenecessarily going to eliminate some styles of programming, whileemphasizing others.

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

Io and Python have quite different fundamental approaches to languagedesign, and so it's not surprising that there are going to beirreconcilable differences.

Paul PrescodI 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

Io (www.iolanguage.com) is a new programming language that's purelyobject-oriented (but with prototypes), has a powerful concurrencymechanism via actors, and uses an extremely flexible syntax becauseall code is a modifiable message tree.

I long to live in a world where Python is considered a crufty incumbentlegacy language that is forced on unwilling programmers by Pointy HairedBosses. First, it would mean that Python has vanquished languages thatprogrammers like less. Second, it would mean that the up-and-cominglanguages are so unbelievably cool and elegant that they make Pythonlook like a lumbering dinosaur.

Thanks for reminding me that that that day was once unfathomably far inthe 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 nearas 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 faithin 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 butI 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 ablessing and a curse.

Jonathan DaughertyAs 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

As other posts have indicated, this is not the io-user-list. Whileyou probably have good, purely academic intentions with your post,this is not the correct forum. Create an io-vs-python list somewhereand I'm sure you'll get a few subscribers. :)

Sean RossHi. 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

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

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

Daniel EhrenbergNo, 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

No, init and allocated should have used :=, even though init hasspecial meaning. I don't really know why you have the howMany methodsince it doesn't really do anything (everything is public and methodscan be called with just references), and all clones of P willdynamically inheret allocated. Also, when initializing variables,their scope must be specified (which is the whole reason for thedifference between := and =), so id := allocated should probably beself id := allocated. self, along with a few other variables, isimplicitly sent to all functions (and do).

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

Actually, the whole scoping model is really that you're working intransparent objects with inheretance, even for things like the globalscope and the scope of functions.

I'm not a fan of the parenthesis (which might be expected froma Python user - love that significant whitespace ;).

At first I didn't like them easier, and with the syntax of mostlanguages, there really isn't any advanatage, but Io code byconvention can be much more dense (while still readible). For example,Io doesn't have a ternary operator (like Python), but the flow controlfunction 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) arefalse in the context of if.

I'm also not abig fan of 'clone', I'd rather see 'new', but I do understand why'clone' is more apt. Of course, in this language, you could alwaysjust 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 inhereteddynamically for all objects.

Sean Ross"Daniel Ehrenberg" wrote in message news:711c7390.0401311134.26cd0a11 at posting.google.com... [snip] Okay. So, is there no way to have private attributes/operations? Or, like in Python, is there just a convention? "_slotName" [snip] 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

"Daniel Ehrenberg" <LittleDanEhren at yahoo.com> wrote in messagenews:711c7390.0401311134.26cd0a11 at posting.google.com...[snip]

(everything is public and methodscan 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 thedifference between := and =), so id := allocated should probably beself id := allocated. self, along with a few other variables, isimplicitly 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 scopefor the duration of the block?

Daniel EhrenbergYes, but code like that is confusing and shouldn't be used unless you need to. 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 CarlsonAfter 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

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

Daniel Ehrenberg

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

Paul PrescodDo 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"Paul Prescod" wrote in message news:mailman.1078.1075571238.12720.python-list at python.org... 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

Daniel EhrenbergIn 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,

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 hasthe appropriate behaviour but that wouldn't help anyhow.

Paul Prescod

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

Dog barks //IoDog.barks() #Python

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

Brian QuinlanInteresting. 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

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 hasthe appropriate behaviour but that wouldn't help anyhow.

Paul Prescod

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

Dog barks //IoDog.barks() #Python

Regardless of which one is more common, which looks more likelanguage?

Looking like natural language is *not* necessarily a good thing inprogramming languages.

Daniel EhrenbergOk, 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 PrescodThe 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. 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

But anyhow I'm not going to argue that IOs choice is wrong, justconfusing 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. (notethat 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 thetrend of using curly braces. Hardly anyone chooses Python because ofthat feature and some are turned off by it. Python makes tons ofconservative, "traditional" choices and I think that they do havesomething to do with its current level of popularity. Sometimes Pythoneven hides pretty radical semantics under "traditional" syntax (e.g. []as sugar for getitem). Ruby takes this even farther. If I were in chargeof IO I might do that too. e.g. make {} sugar for a last argument thatis a statement list or something.

Second, I think that the meaning of Python's colon is unuusal butself-evident. I personally decided to learn Python because I stumbledupon some code that looked exactly pseudo-code and wondered whatlanguage I was reading. Coming from (e.g.) Java or C++, most of Python'ssurfact syntax is self-evident to the English speaker, even whendifferent (e.g. "or" instead of "||").

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

Andrew HenshawPaul Prescod wrote: ...snip... ...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

First, if I had invented Python I would not have bothered to buck thetrend of using curly braces. Hardly anyone chooses Python because ofthat 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 thereason I first tried Python. Having used Occam for many years, I was verypleased to find a language that recognized the superiority of that style.

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 thetrend of using curly braces. Hardly anyone chooses Python because ofthat feature and some are turned off by it.

I have to admit that the indentation feature turned me off at first, buthaving used Python for a while now, I find that method superior to thecurly braces approach. Much more DWIM.

John Roth"Paul Prescod" wrote in message news:mailman.1110.1075672228.12720.python-list at python.org... 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

"Paul Prescod" <paul at prescod.net> wrote in messagenews:mailman.1110.1075672228.12720.python-list at python.org...

First, if I had invented Python I would not have bothered to buck thetrend of using curly braces.

I suppose I am hardly anyone else, since that it exactly whatattracted me to Python. In fact, I will take partial responsibilityfor the indentaion syntax in IBM's ISPF mini-language - it's apreferance of long standing with me.

Now that I actually have a significant language using them, Ican see that there are a couple of things they make moredifficult, statement syntax embedded within expressions beingone. The other is a rather esoteric issue with clauses likeelif, else and except.

Paul PrescodThere 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

"Paul Prescod" <paul at prescod.net> wrote in messagenews:mailman.1110.1075672228.12720.python-list at python.org...

First, if I had invented Python I would not have bothered to buck thetrend of using curly braces.

I suppose I am hardly anyone else, since that it exactly whatattracted me to Python. In fact, I will take partial responsibilityfor the indentaion syntax in IBM's ISPF mini-language - it's apreferance of long standing with me.

There are certainly costs and benefits to the Python way. And we've beenover 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 vastlybetter.

Donn CaveAnother 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

Another thought about that: from the Python version, barks isevidently a function. Even if were a data attribute, I thinkin classical usage it would be a "message", and given that aclass instance can implement its own attribute lookup, we mayas well say that data attributes are simply functions with noextra parameters.

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

In the above example it looks somewhat natural, but onlybecause of a declarative flavor that is hardly the rule inOO programming. Take wl.append(w), for example - we're soused to this notation there's no point in asking if it wouldmake more sense written append.wl(w), but if we're lookingat a language that has taken a more lispish notation, I'dsuggest "append wl w" is far more consonant with normal(not Forth) programming language notation.

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

Paul PrescodDog 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

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

Dog is not just the object. It is also the namespace that "barks" comesfrom. Both the computer and the human need to know the namespace beforethey can interpret the meaning of the string "barks" so it seems naturalto me that it should come first. This is especially true in languageslike Python and IO where two objects of even the same type could havedifferent name->method mappings.

1) It would be single threaded web server (asyncore, twistedmatrix)with a select loop talking to a socket, either on port 80 directly, orto 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 anylong-running transactions. Maybe some occasional complicated requestswould get spun off to a new thread or even just forked off. Theserver would run normal requests to completion before going on to thenext request.

Also, how bad is using files really? A decent Unix will use memoryto cache files, abstracting disk io behind the scenes for you.

Daniel EhrenbergIn 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

Another thought about that: from the Python version, barks isevidently a function. Even if were a data attribute, I thinkin classical usage it would be a "message", and given that aclass instance can implement its own attribute lookup, we mayas well say that data attributes are simply functions with noextra parameters.

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

In the above example it looks somewhat natural, but onlybecause of a declarative flavor that is hardly the rule inOO programming. Take wl.append(w), for example - we're soused to this notation there's no point in asking if it wouldmake more sense written append.wl(w), but if we're lookingat a language that has taken a more lispish notation, I'dsuggest "append wl w" is far more consonant with normal(not Forth) programming language notation.

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

Donn Cave, donn at drizzle.com

In your advocacy of Lisp over Forth (something completely unrelated tothis thread and newsgroup), you miss the major selling point of objectorientation: encapsulation. If you had barks(Dog) instead ofDog.bark() (I'm using Python not Io syntax for now), bark() isaccessible to everyone, not just Dogs. So I could write bark(Cat),which shouldn't work. Also, some of your examples of things that areambiguous really aren't ambiguous because neither Python nor any otherlanguage uses spaces both in the way they are used in Lisp and the waythey are used in Smalltalk.

Donn CaveQuoth LittleDanEhren at yahoo.com (Daniel Ehrenberg): ... 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

In your advocacy of Lisp over Forth (something completely unrelated tothis thread and newsgroup), My what?... you miss the major selling point of objectorientation: encapsulation. If you had barks(Dog) instead ofDog.bark() (I'm using Python not Io syntax for now), bark() isaccessible 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 rulesfor function namespaces, and that wasn't exactly what I hadin mind.

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

There are plenty of cases in anyone's Python code where a plainfunction 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 changeflip(coin) to coin.flip(), or vice versa? It's an implementationdetail that no one but the implementor should have to care about.

Donn CaveQuoth Paul Prescod : 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

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

Dog is not just the object. It is also the namespace that "barks" comesfrom. Both the computer and the human need to know the namespace beforethey can interpret the meaning of the string "barks" so it seems naturalto me that it should come first. This is especially true in languageslike Python and IO where two objects of even the same type could havedifferent name->method mappings.

If as a human I need to know the namespace of a function to understandit, am I going to be confounded if a function defined in SGMLParserappears to be invoked on an instance of HTMLParser? Well, honestlythat kind of thing can sometimes be a source of frustration, but inprinciple 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 ofHTMLParser.feedSGMLParser.feedParserBase.feedobject.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 wouldbe writing insteadfeed(parser, data)

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

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

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

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

Berry.

"Josiah Carlson" <jcarlson at nospam.uci.edu> schreef in berichtnews: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 apackage called testmodules.

[snip]

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

Kylotan"Donn Cave" wrote in message news:<1075702864.490920 at yasure>... 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

"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 wouldbe writing insteadfeed(parser, data)

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

Now I'll admit that this level of abstraction does pose a problemwith scope and legibility, and that might have to be addressed.My point though is that we already accept this problem as a costof doing OO business, so it's kind of surprising to me that OOlanguages invariably stop there, instead of going all the way.They'll proudly declare that `everything is an object', but don'twonder 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 toboth parser and data, and that parser and data are unchanged by theoperation. It's vaguely saying "I want something to happen based onparser and data".

parser.feed(data) implies that feed has enhanced access privileges toparser compared to its access to data. In particular it implies thatparser 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 havethe rigorous public/private/protected system that C++ does. But itdoes usually provide useful hints as to what the main object in anygiven interaction is. (ie. distinguishing between controller andentity classes, in UML terms.) Of course, it's entirely a religiousmatter in much the same way as arguing for a clear distinction betweenfunctions and subroutines would be. Just different ways of looking atit to suit different thought processes.

Donn CaveIn article <153fa67.0402021548.6c5e394 at posting.google.com>, kylotan at hotmail.com (Kylotan) wrote: 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

In article <153fa67.0402021548.6c5e394 at posting.google.com>,kylotan at hotmail.com (Kylotan) wrote:

"Donn Cave" <donn at drizzle.com> wrote in messagenews:<1075702864.490920 at yasure>...

But if the feed function had been outside this hierarchy, we wouldbe writing insteadfeed(parser, data)

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

From my point of view (C++ and general OOP background) this comes downto access privileges and the visible implications of the code.

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

parser.feed(data) implies that feed has enhanced access privileges toparser compared to its access to data. In particular it implies thatparser 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 havethe rigorous public/private/protected system that C++ does. But itdoes usually provide useful hints as to what the main object in anygiven interaction is. (ie. distinguishing between controller andentity classes, in UML terms.) Of course, it's entirely a religiousmatter in much the same way as arguing for a clear distinction betweenfunctions and subroutines would be. Just different ways of looking atit 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 withone parameter vs. another? Isn't it enough that it works?

Jonathan DaughertyNot 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 EhrenbergIo 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

As other posts have indicated, this is not the io-user-list. Whileyou probably have good, purely academic intentions with your post,this is not the correct forum. Create an io-vs-python list somewhereand 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 nobodymade this complaint. When somebody asks a question about using theZope CMF, people don't say "go make a zope-cmf mailing list", theygive a constructive response.

A. Lloyd FlanaganLittleDanEhren at yahoo.com (Daniel Ehrenberg) wrote in message news:<711c7390.0401291301.3f95794 at posting.google.com>... 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.

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 Pythonor 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 likethat? If you want a language you can use to make programs that makeno sense to anyone but the author, Perl should be more than sufficientfor your needs.

Hannu Kankaanp??alloydflanagan at comcast.net (A. Lloyd Flanagan) wrote in message news:... 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

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 Pythonor 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 likethat? If you want a language you can use to make programs that makeno sense to anyone but the author, Perl should be more than sufficientfor your needs.

The point is that implementing your own "for" is something you can'tdo in Python very nicely, so it's a proof that Io can achievegenuinely higher abstraction levels on this part. Implementing"for" again with a new name probably wouldn't make anyonehappy, but such power opens a set of tricks and idioms tobe used in real code to solve real problems, that wouldn'tbe possible in Python without kludgy syntax.

Here's a normal loop:

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

Here's the same using a custom loop:

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

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

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

Now tell me which of these two lowermost forms looksbetter and makes more sense? For examples that don'tjust make aliases of existing syntax, see theLisp 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 makeno sense as well. (due to Ulf Bartelt:)

Daniel EhrenbergNobody 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

I think the point is, why on earth would you want to do something likethat? If you want a language you can use to make programs that makeno sense to anyone but the author, Perl should be more than sufficientfor your needs.

Nobody uses Perl because they like its illegibility, they think (forsome reason) that it's more powerful.As for the flexibility of Io, there's a big difference betweenflexibility and illegibility. Whenever a new, more powerfulprogramming language comes out, everybody says it's too flexible.Fortran people were saying that about C, C people were saying it aboutC++ and Java, and C++ and Java people are still saying it aboutPython. Dynamic typing? That's so error-prone, they say. Flexibleblock syntax? Code is "illegible", you say.

Erik Max FrancisC 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 &&

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

C people were saying that about Java?

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

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 Pythonor allow block syntax at all without hacking the C source code? ...Many users of Io (myself included) have switched over from Python forthese reasons.

If you've switch from Python to Io, what will you do with the answersto these questions? Use them for good or evil? Will you switch backfrom Io to Python?--dang