Guido van Rossum Leaves Zope.com

VladDrac writes "Guido van Rossum, the author of the Python programming language, announced at OSCON last night that he's leaving zope.com, to work for a new startup called 'Elemental Security', founded by Dan Farmer (known from several security tools such as Satan). Guido leaving Zope.com will also probably mean that he will be no longer involved in Zope3 development, but hopefully he'll have more time to spend on Python development." Guido says that he's excited about his new employer, but that nothing substantial will change about Python as a result of the move. "It's just that I'll be working from the West coast." Python is "already quite secure," he says, and will be the basis of an upcoming security product ("just getting started") from Elemental.

Comments

His goodbye posting

[VladDrac]

You can read his goodbye posting to the zope3 list here

Typo

[Anonymous Coward]

"an (sic) security product"

Please fix

Re:Typo

[Anonymous Coward]

How exactly is pointing out a flagrant grammatical error a troll?

Re:Typo

[Anonymous Coward]

Particularly considering that the editors actually did fix it, by inserting the word "upcoming". No note of that in the write-up, you'll notice.

Good times.

[Meat Blaster]

No doubt he'll have much more time to dedicate to his programming. Python sounds pretty interesting, and I dug through the BitTorrent source a bit to learn more about it, but it also seems pretty complex for what the end result is (as opposed to, say, Perl.) With a bit of work towards a more logical parse tree/DTD, I could see Python easily surpassing Perl as a strongly-typed effective scripting language.

What other projects are being done in Python?

Re:Good times.

[mjmalone]

I read somewhere that parts of google's database search software are written in python... but it was a long time ago so I could be wrong.

Re:Good times.

[dagarath]

The obvious reference to Python Web Site will give more information. Python often competes in the same space as perl. But, Python is probably more object oriented than perl. The difference being that python is OO from the ground up as opposed to perl where it was added late. Most of Redhat's installation tools and scripts are written in python. A 3d game a few years ago 'Blade of Darkness' was done with mostly python.

Re:Good times.

[Anonymous Coward]

Many of RedHat's GUI system tools are written in Python. Yahoo also uses Python for it's maps. Python is continually growing. It is simple and easy to learn yet powerful enough to do complex tasks. I'm not sure it will 'surpass' or 'takeover' Perl, but IMO it should be used if you hate reading obfuscated Perl code.

Re:Good times.

[listen]

You have got to be kidding...
Python is *SO* much easier to read than perl.

Neither python or perl are strongly typed, dumbass.

Re:Good times.

[Anonymous Coward]

I don't know about Perl, but Python is very strongly typed. It is not, however, statically typed.

Re:Good times.

[hesiod]

> Neither python or perl are strongly typed, dumbass.

While you may be right (I don't know, I have to assume you are), I don't think it's necessary to call him a dumbass. If you're going to insult someone, make it worthwhile, like "Learn what the F*&ck you are talking about before posting, asshat!" :)

Re:Good times.

[rRaminrodt]

Off the top of my head:
Twisted - a web/chat/anything-you-can-name server
Zope - Web Application/CMS type system
bittorrent - you know about that one
Red Hat uses Python in a lot of their scripts (I believe)
NumPy - used for scientific applications (replacing/augmenting Matlab, fortran, etc)
Karamba - KDE desktop eyecandy, written in C++ and scripted with python
and some really bad stuff I've written for my own amusement. :-)

Off course there's more, but I did say off the top of my head and I don't want to cheat. It's really a nice clean language, that really lends itself to prototyping but still can make great apps.

Re:Good times.

[leshert]

A 3d game a few years ago 'Blade of Darkness' was done with mostly python.

There are a few more games that use Python... you might have heard of them:

• Ultima Online 2
  
• Freedom Force
  
• Humongous's "Backyard Sports" series
  
• Disney's ToonTown
  

Re:Good times.

[Anonymous Coward]

How is Python "more complex" than Perl?

Or are you just describing "more complex" as "requires more typing"?

What is it you consider 'illogical' about the parse tree?

I am honestly just curious what your thoughts are.

Re:Good times.

[William Tanksley]

Python is actually simpler than Perl -- it's designed to be so. HOWEVER, Perl is also designed to do many specific things very simply, so when you need to do one of those specific things it's the fastest way to get it done -- assuming, of course, that you already knew Perl could do it :-).

I'm a Python fan, but I doubt Python will ever surpass Perl -- especially not by adding a "more logical parse tree", since it already has a very simple, consistent, and logical parse tree whereas Perl has more of a parse forest. Python and Perl are just too different; they compete in many areas, but their real strengths are far enough apart to keep them both viable in each other's presence.

For info on what projects are being done in Python, see the lists at www.python.org (Success Stories, Python Users, and Python Projects)).

Remarkable language, Python. Lovely plumage!

-Billy

Re:Good times.

[Anonymous Coward]

eroaster, a gtk2 frontend to cdrecord+mkisofs

rubrica, a gtk2 addressbook

emerge from gentoo

quark, quake map editor: http://dynamic.gamespy.com/~quark/

and yes, also quake (similar to q2java): http://barryp.org/software/qwpython

Re:Good times.

[listen]

You can change the type of an object at runtime via .__class__ right?

Re:Good times.

[dtolton]

It is a misconception that Python is not strongly typed. It is strongly typed, it is not *statically* typed.

Python is a stronly typed, dynamically typed, extremely late bound language.

Double check your facts before calling someone else a dumbass.

The difference between a dynamically typed language and a statically typed language is this:
// Java
int myvar = 1;

# Python
myvar = 1

The difference is that the Java compiler assigns a datatype to the location of myvar, but python assigns a datatype to the value held in myvar.

It's a subtle difference, and many python newbies think it's not strongly typed, however that is a mistake.

Re:Good times.

[Anonymous Coward]

eve online uses stackless python

Re:Good times.

[andrew_j_w]

It would appear that you are the 'dumbass' since Python is most definitely strongly typed.

Try running this command...
python -c 'print "3"+2'
... and you'll get a type error, it won't automatically cast the 123 to "123". You might find this link useful Strong vs Weak typing.

AFAIK Perl is a variant-bound language and as such isn't strongly typed, although I'm no Perl guru so I could be wrong.

Typing...
perl -e 'print "3"+2'
... does result in 5 suggesting that it is indeed weakly typed.

I do agree that Python is much easier to read than Perl :-)

Andrew

Re:Good times.

[Xerithane]

Python is *SO* much easier to read than perl.

I can't properly read blocks unless they are encapsulated in { }, thus I have a really hard time in Python. I'm sure if I spent enough time with it I would be able to figure it out though.

Perl code can be extremely readable though, it just takes a whole lot of work to do it.

Re:Good times.

[Ikari Gendo]

Guido seems to disagree.

GvR: In a strongly typed language, when you change to a different data structure, you will likely have to change the argument and return types of many methods that just pass these things on. You may also have to change the number of arguments, because suddenly you pass the information as two or three parts instead of one. In Python, if you change the type of something, most likely pieces of code that only pass that something around and don't use it directly don't have to change at all.

Now you might be splitting hairs and saying that "static" means known at compile time and "strong" means type errors are always detected, but in common parlance "strong typing" includes static typing. For the pedants, there's Sebesta:

...we define a programming language to be strongly typed if type errors are always detected. This requires that the types of all operands can be determined, either at compile time or at run time.

This criterion is met by very few real-world languages. Most imperative and object-oriented languages include type coercion which contradicts this property. It is interesting to note that future Python development is moving towards still stronger typing -- and, dare I say it -- functional-style constructs.

Of course, the pragmatic thing to do is to understand strong/weak typing not as binary, but as a continuum. In this case, Haskell is more strongly typed than Ada is more strongly typed than Python is more strongly typed than C++ is more strongly typed than C is more strongly typed than FORTRAN. It looks like Python 3.0 will be moving up the chain, however.

Re:Good times.

[rhaig]

badly written python is just as hard to read as badly written perl, or C, or Java, or C++, or miranda, or pascal, or basic, or blah blah blah... yada yada yada...

point being, not all perl is obsfucated, and not all python is like reading english.

Re:Good times.

[Tyler Eaves]

Quote: I'm a Python fan, but I doubt Python will ever surpass Perl -- especially not by adding a "more logical parse tree", since it already has a very simple, consistent, and logical parse tree whereas Perl has more of a parse forest.

Oh, WOW! What a quote ;)

Re:Good times.

[pldms]

The difference is that the Java compiler assigns a datatype to the location of myvar, but python assigns a datatype to the value held in myvar.

This is a minor point, but that doesn't show Java is statically typed:

Object myvar = "Hello";

myvar = new Foo();

That would be dynamic, AAUI. So Java has both static and dynamic typing? Or do OO languages just confuse things?

Re:Good times.

[listen]

So strings are the be and and end all of your "weakly typed languages coerce types" argument?

python:
>>> 2 + 3.0
5.0
>>> type(3)
< type 'int'>
>>> type(3.0)
< type 'float'>
>>>

So ints are coerced to floats in practice in python. Of course in a multi dispatch langauge + could be defined over Float, Int

If you want a real strongly typed language as in all type errors are detected use Haskell or ML.

Re:Good times.

[Maimun]

This is a question, I have little experience with Python and until I finish my thesis that will not change.

I read somewhere in usenet that python is relatively slow, even for interpreted language, and my (extremely limited) experience is the same. A while ago, I did a simple text converter in python as an exercise. Very basic stuff, read from file, check the value of each symbol, change with another value if necessary, write into another file. It was quite slow on texts of moderate size. I mean, if it were in C, the delay would not be noticeable.

However, if google uses it, then python has "industrial strength" and should perform well. I wonder...

Re:Good times.

[Anonymous Coward]

Java only has static typing. What you are showing
is the ability to use casting to access objects
through their parents in the inheritance tree
(superclasses).

Your example should be:

myvar = (Object)new Foo();

This allows myvar to manipulate the Foo class as
if it is an instance of Object. You will not be
able to access methods of Foo unless they are
inherited from Object.

-Dave

Re:Good times.

[Eric Desrosiers]

Type is only relevant to variables not the object they point to. Obviously, an object cannot change type and so are variables in a language with static typing. But with dynamic typing it can.

So in your example, even though myVar holds a string or a Foo, you can only use methods from Object with it because that's it's type. Doing
((Foo)myvar).fooMethod()
does not count because it can be seen as creating a temporary variable of type Foo.

In a dynamicaly typed language, you would only have to write myvar.fooMethod().

Re:Good times.

[Anonymous Coward]

it's possible that, given your "limited experience", you weren't doing things as efficiently as you could - eg using an iterative C approach when a pythonesque approach is better for python.

Re:Good times.

[andrew_j_w]

It might not be a completely convincing argument, but it highlights the difference between Perl and Python with respect to typing.

The majority of type error are detected at run time and will raise an exception. Ints being coerced to floats is a special case in Python, implemented for convenience.

And it's a hell of a lot better than "you're a Dumbass"

Re:Good times.

[tunjin]

using a tab-size of >= 8 can help a lot...

Re:Good times.

[Scaba]

So Java has both static and dynamic typing? Or do OO languages just confuse things?

Neither. Your argument is specious, because what you're referring to is inheritance, not typing. Inheritance is another aspect of OOP that says "If my parent is an Object(), by definition, I am an Object(), too." However, in your example, myvar will only have the properties and methods of Object(), not Foo(), unless you cast myvar like ((Foo)myvar).someFooMethod() (which disproves your argument, by the way).

Java is strongly and statically typed. To prove it, try this:

String s = "Poop";

s = new Integer(23);

You'll notice a compilation error about incompatible types.

Re:Good times.

[Da VinMan]

If you want a real strongly typed language as in all type errors are detected use Haskell or ML.

Hey, why mess around? Use Ada! ;+)

Re:Good times.

[axxackall]

What other projects are being done in Python?

Other guys are mentioning many projects, but I want to emphsize on three project, IMHO the most important to illustrate the power of Python:

• Zope - IMHO the best ever written application server, thanks to laziness and OOP of Python;
• Plone - this portal is the best software written for Zope's CMF; Zope would stay popular only among hackers if there would be no Plone;
• Portage - the best ever written package management system; I doubt ebuilds and eclasses would be that flexible and power without Python;

Re:Good times.

[pldms]

/me adding noise to this discussion, so I'll be brief...

In a dynamically typed language, you would only have to write myvar.fooMethod().

Ok, so ObjC and Ruby are dynamically typed (and, I guess all smalltalk style OO langs), but not Java and C++?

Re:Good times.

[DonGar]

I use Python on a regular basis, but I also found the BitTorrent code hard to read. What BitTorrent does it really cool, but the code really does seem messy.

However, I never was able to pin down exactly what it was about the style that I disliked. It makes me very uncomfortable to say "that code is bad" when I can't say why in a clear and concise manor.

I've never done much Python networking code. Perhaps the APIs lead to clunky code, especially when you are trying to do robust error handling.

Re:Good times.

[pldms]

Your argument is specious

How dare you... :-)

I was thinking of ObjC and Ruby here, plus I'd been trying Java's dynamic proxy class stuff, which achieves a similar 'dynamic typing' feel (but in long winded and painful fashion).

Re:Good times.

[Randolpho]

Sure, Python compared to C is slow, if you use calls written in Python rather than C (many Python modules are written in C with Python bindings). But compared to, say, Perl or Ruby? I'd say they're about on par.

Where Python is superior to C is the fact that Python is a higher level language. Easier to code it, easier to get things done, etc.

Re:Good times.

[hoggy]

So ints are coerced to floats in practice in python. Of course in a multi dispatch langauge + could be defined over Float, Int

If you want a real strongly typed language as in all type errors are detected use Haskell or ML.

Which would have been really clever and showed your deep understanding of programming languages if it weren't for the fact that you're wrong.

Observe:

jonathans-ibook% ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.0, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.

Loading package base ... linking ... done.
Prelude> 2 + 3.0
5.0
Prelude>

Haskell also casts integers to floats automatically. This is common in most languages.

You'll note from this that it's not an argument for Python not being strongly-typed.

Re:Good times.

[inkedmn]

Red Hat uses python in it's installer (anaconda, iirc)

Re:Good times.

[Andy Dodd]

EVE Online uses a modified version of Python called Stackless Python.

Re:Good times.

[sketerpot]

It's hard to define, but I will swear to anyone that aesthetics are very important in code. Case in point: I'm currently refactoring somebody else's Python code. It sucks. There isn't any one specific thing about it that sucks, but it is still shit. Working shit, but shit nonetheless. The parts that I've worked over are much easier to read and change.

Messy code must die!---and Python is a great language to kill it with when done properly.

Re:Good times.

[Anonymous Coward]

redhat's installation is done by anaconda - python
also all of it's configuration to the config-redhat-.+ family of apps - all python .
ximian redcarpet and redhat's up2date - python
I think that python presents and evolution for scripters that used to use bash then perl and then needed to manage something big Object Oriented(Purely naturally and elegently).
I've been writing python for almos 3 years after perl and it totally rocks!
Lior Kesos
aduva

Re:Good times.

[Larthallor]

The premiere free-form online pen-and-paper style role playing tool, OpenRPG is written in Python.

Re:Good times.

[Fencepost]

Two things that might have caused you problems:

• How were you reading the file? One big chunk, one character at a time, or with an intermediate buffer? An intermediate-sized buffer with data being copied to a new buffer for output will be the most efficient.
• Were you trying to make in-place changes to the string? Strings in Python can't change, so with larger inputs you might've been moving a lot more data around behind the scenes.

Re:Good times.

[cpeterso]

I like to think of static typing as the variable NAME has a type (regardless of value) and dynamic typing as the variable VALUE has a type (regardless of name).

Re:Good times.

[Ricin]

No criticism but an addition:

I've started looking into twisted lately and if you find zope too abstracted and rather hammer out code this is a very interesting project. Also webserver but also ftp, ssh, and more. Web app framework. Page templates.

It is different in the sense that it is more bare bones but has many features and 3rd party stuff and -- get this -- it's all about event loops. So you can have server side python scripts responding to browser (javascript) events. You can use a GUI toolkit as well. GUI app with e.g. an image (http) server? Import the web server module, instatiate a few classes, and go.

Very promising. Somewhat scarce documentation (but not outdated and confusing as I found zope's).

Unrelated: I first read you as: portage is the best written packman ever and wanted to reply in disagreement ;-)

Re:Good times.

[smallpaul]

The definition: ...we define a programming language to be strongly typed if type errors are always detected. This requires that the types of all operands can be determined, either at compile time or at run time.

You said: This criterion is met by very few real-world languages

Python and Java are two examples of languages that meet this criteria. They detect type errors either at compile time (in the Java-without-casting case) or at runtime (in the Python or the Java-with-casting case).

Re:Good times.

[Ikari Gendo]

Python and Java are two examples of languages that meet this criteria. They detect type errors either at compile time (in the Java-without-casting case) or at runtime (in the Python or the Java-with-casting case).

Since both Java and Python support type coercion, it is not the case that for any given Java or Python program, type errors will always be detected -- namely, in programs where coercion is used, the guarantee no longer holds. Pedantic, yes, but that's what the definition states. This is why I am in favor of a more pragmatic understanding of strong and weak typing. :)

Re:Good times.

[axxackall]

I've checked Twisted before makeing my choice for Zope. I found it as a sort of new OS, just without kernel. It can work well for embedded systems: imagine jsut kernel and twisted to do everything!

However the Unix way is oppositely different: make many small servers/applications/filters each doing its small function, but doing it very well. In case of twisted I found both web templates and instant messaging rather primitive, comparing to Zope and Jabber. And I don't see any benefits to keep inside the same application all of them: Web, IM, SSH. If I cannot answer to myself "why?" then I cannot recommend it to my clients.

By the way, Zope is also very big, comparing to Apache, which is just a core listener and static file service. However, the main problem with Apache is exactly in syndication of various information sources into pages in a way when such syndication is integrated with the overall web-server management. Check for typical problems in user and access management with Apache. Zope solves it for the price of making bigger. But as a developer I agree to pay that price as it gives me the integration around the same core thing: web-based information management as I get excelent quality for that price. In case of Twisted I have to pay even more price of complexivity for ... for what? For having gathered together often unrelated services? Why? Again, I know when I have an answer for "why" question - in embedded systems. But it's different market than Zope is positioned on.

Re:Good times.

[Ikari Gendo]

Haskell also casts integers to floats automatically. This is common in most languages.

This is not a typecast. Both Integer and Float are members of the Num type class, and (+) is an operation defined over the Num type class. This is much closer to what really happens in mathematics, where addition is understood to apply to reals (which include integers). For more information, see the Haskell Standard Prelude.

The short version is that there isn't one (+) :: Integer -> Integer -> Integer and one (+) :: Float -> Float -> Float, but rather a single (+) :: Num a => a -> a -> a. It is manifestly never possible to have a type error in this situation, so Haskell is still strongly typed.

Re:Good times.

[Genghis Troll]

No, there's no casting going on, because "2" in that context isn't an int, it's a member of the "Num" typeclass; you didn't specify a type for "2", so the compiler infers an appropriate one.

Prelude> :t 2
2 :: forall t. (Num t) => t
Prelude> :t 3.0
3.0 :: forall t. (Fractional t) => t
Prelude> :t 2 + 3.0
2 + 3.0 :: forall a. (Fractional a) => a

Now try this:

Prelude> let x = 2 in x + 3.0
5.0
Prelude> let x = 2 :: Int in x + 3.0

<interactive>:1:
No instance for (Fractional Int)
arising from the literal `3.0' at <interactive>:1
In the second argument of `(+)', namely `3.0'
In the definition of `it': it = let x = 2 :: Int in x + 3.0

Re:Good times.

[Anonymous Coward]

Didn't paste enough:

Prelude> let x = 2 :: Float in x + 3.0
5.0

(Just to show that it's not a syntactic issue with the "::" qualification).

Re:Good times.

[msaavedra]

I never was able to pin down exactly what it was about the style that I disliked.

Out of curiosity, I just checked out the BitTorrent code, and I can offer some concrete examples of what I don't like about it:

1. Almost no comments. Python has very good built in documentation features, and they are completely unused here.
2. Frequent use of single-letter variable names, or names that are abbreviated so heavily that someone unfamiliar with the code has no idea what they mean.
3. Very long lines. I saw a few that were about 160 characters long, twice what they should be.
4. Deeply nested code blocks. I'll have to agree with Linus Torvalds here, who said that if you're nesting more than three layers deep, you probably need to rethink what you're doing. Though I'd increase this to four layers for OOP languages like python.

I'm sure others can think of more. I don't mean to give this guy a hard time, though; I've definitely seen much worse, and some areas of the code actually seem fairly clean to me. Also, for anyone interested, there, is a good, standard for python coding style in PEP 8

Re:Good times.

[Erich]

Fortunately, Python supports open and close braces to mark beginning and end of blocks. Just prefix them with a hash and use proper indentation. For instance:

def the_count(): #{

for i in range(0,10): #{

print "%d, %d, Ah, Ah, Ah!" % (i,i)

#}

#}

Tadaa! Curly braces. The code is now readable.

PS. Sorry for the odd indentation, I haven't posted code under slashdot for a while...

Re:Good times.

[Ricin]

Twisted need not be web based at all. The idea is easy component reuse for high level inet services. It doesn't revolve around its webserver. It's one use but not its only.

Twisted is a programming framework. Swiss knive type of tool if you like python. Some of its web related stuff has resemblance with some of Zope's (that is web content manipulation etc) but it's a different thing overall. I don't dislike Zope, but I personally find twisted more interesting and general purpose. YMMV.

About the UNIX way: "small" components "each doing its small function, but doing it very well" is IMHO not a bad thing either :D

Re:Good times.

[hoggy]

The short version is that there isn't one (+) :: Integer -> Integer -> Integer and one (+) :: Float -> Float -> Float, but rather a single (+) :: Num a => a -> a -> a. It is manifestly never possible to have a type error in this situation, so Haskell is still strongly typed.

My point was not that Haskell is not strongly-typed, but that Python is not weakly-typed because one can add an integer and a float.

Re:Good times.

[Merk]

Well, maybe, until you use Ruby. At that point you realize that Python is by no means OO from the ground up. I like Python, it's one of my favourite languages, and it has been around for years... but while I like Python, I love Ruby because it is the most completely OO language I have ever used, and that is really handy. For a comparison, I'd recommend a page on the ruby site which is linked to from the python site, and contains a posting to comp.lang.python, so I'm guessing it's not too biased either way.

Although I use Ruby all the time at home, I'm stuck using Python for some things at work now, but as soon as Ruby matures a little more, I'll start using it here too.

Re:Good times.

[be-fan]

IIRC, Java doesn't support unsafe coercion. You can cast a value to something, but the runtime will check if that value is actually of that type and throw an exception if it isn't. Coercion in Python works the same way. Unless I'm misunderstanding your use of 'coercion'?

Re:Good times.

[smallpaul]

Since both Java and Python support type coercion, it is not the case that for any given Java or Python program, type errors will always be detected -- namely, in programs where coercion is used, the guarantee no longer holds.

In a system with type coercion, errors are caught at runtime. That's why both Java and Python have TypeError/ClassCastExceptions. If you read your own definition you'll see that it specifically allows for catching of errors at runtime.

Re:Good times.

[Maimun]

Hi,

* How were you reading the file? One big chunk, one character at a time, or with an intermediate buffer? An intermediate-sized buffer with data being copied to a new buffer for output will be the most efficient.
* Were you trying to make in-place changes to the string? Strings in Python can't change, so with larger inputs you might've been moving a lot more data around behind the scenes.

That's the code

while 1:
____c = sys.stdin.read(1)
____if not c: break
____n = ord(c)
____if n &lt 0xC0:
________text = text + c
________continue
____elif n &lt 0xE0:
## a small letter
________new = koi[n]
____else:
## a capital letter
________n -= 0x20
________new = chr(ord(koi[n]) - 0x20)
____text = text + new
print text

Of course, there are no underscores, I just don't know how to get the proper whitespaces at the beginning of the lines :)

Re:Good times.

[axxackall]

By the way, why doesn't Twisted have "resemblance" with some of Jabber-server for its IM? IMHO new IP protocol will be re-implementing the wheel. Moreover, the implementation of proprietary IM protocols while ignoring the most famous open-source IM protocol (Jabber) should be considered as a shame for any open-source project, don't you think?

Anyway, I dislike the concept of re-implementing such protocols as SSH - it must be very secured, that's why I trust more to OpenSSH (and its libraries). Again, in embedded systems there might be no place for OpenSSH, but in "real world"... You've got a point.

To be honest, there are two things I don't like in Zope.

1. First is that it re-implements an http listener. Alternatively Zope works with Apache through a sort of CGI (CGI? Today?). I'd rather use Zope with Apache through some sort of mod-zope, like Tomcat.

2. Also, I don't like ZODB - another reinventing the wheel while there are good open source databases. Besides, ZODB is a sort of ODBMS, while I think ODBMS is a techological dead-end, even more dead-end than RDBMS. ORDBMS is the only way to go, IMHO. Thanks to PostgreSQL, there is an open-source ORDBMS. Unfortunately, it's mot possible (or it's not documented) how to get rid off ZODB completely and to use PostgreSQL as the primary DB backend.

Apart of that Zope is well focused on a web-based content-management - right as it should following the Unix path :)

Re:Good times.

[Anonymous Coward]

But, IIRC, RedHat uses an old version; last time I installed a newer python in my system, it thrashed a couple of scripts.

I need to be more careful next time :(

Re:Good times.

[Earlybird]

• 1. First is that it re-implements an http listener. Alternatively Zope works with Apache through a sort of CGI (CGI? Today?). I'd rather use Zope with Apache through some sort of mod-zope, like Tomcat.

Zope's HTTP listener is optional. If you want to use a server such as Apache as the HTTP front end, use FastCGI (mod_fastcgi). Despite the name, though, FastCGI is not really CGI as you know it, although it does require that Zope is running separately from Apache.

However, Zope is a publishing engine mostly based around HTTP. Almost every part of Zope assumes that HTTP is on the client end. And that's all well and good, considering that HTTP is the core of the web. And it hasn't stopped the Zope people from supporting XML-RPC and other access methods.

• 2. Also, I don't like ZODB - another reinventing the wheel while there are good open source databases. Besides, ZODB is a sort of ODBMS ...

The ZODB is an ODBMS: It's an object-oriented database management system. Zope is an object-oriented system and relies entirely on the underlying OO persistence characteristics of the ZODB system.

With an RDBMS, Zope would have been forced to add a significant translation layer between its object file system and the logical database. Such translation -- usually known as object-relational mapping -- incurs much performance overhead, and is potentially awkward, since it needs to bridge between two fundamentally different data models.

• ... while I think ODBMS is a techological dead-end, even more dead-end than RDBMS. ORDBMS is the only way to go, IMHO. Thanks to PostgreSQL, there is an open-source ORDBMS.

Whatever marketing hype it is you've been smoking, consider detox. The ORDBMS is an illusion. Ever used the classes and methods and polymorphism specified by ANSI SQL-99 (aka SQL 3)? No, you have not -- because nobody has implemented it.

Oracle stuffed Oracle 8 with half-baked OO stuff. DB2 has support for tree constructs and multimedia. PostgreSQL started with inheritance and "time travel" versioning, and since they dropped the latter you're left with an esoteric mechanism that's hardly a significant improvement on the relational model.

Oh, and are we really mature enough to be playing around with bad, underspecified, non-standard "object" stuff when in fact nobody really implements the relational model correctly yet and we are still tied to that terrible language, SQL? Not even PostgreSQL is a true relational database in the mathematical sense as invented (or perhaps discovered) by E. F. Codd.

It's true that the ZODB does not support the relational model, but it solves some very specific problems and does it well, unlike ORDBMS technology, which is mostly smoke and mirrors used to describe proprietary extensions to SQL.

• Unfortunately, it's mot possible (or it's not documented) how to get rid off ZODB completely and to use PostgreSQL as the primary DB backend.

You can't get rid of the ZODB per se, but you can switch out the ZODB back end, the storage driver that handles the physical data storage. People have written database back ends that store the database as simple files and in BerkeleyDB databases. Don't think anyone has written a generic RDB-based storage implementation, though.

Re:Good times.

[znaps]

Very long lines. I saw a few that were about 160 characters long, twice what they should be.

Not to nit-pick, but in this day and age I don't think we need to have the 80 char limit for a line of code anymore. I personally use a 120 char limit in Eclipse.

Re:Good times.

[axxackall]

The main practical difference between ODBMS and RDBMS is that ODBMS is good for object persistence, not for querying. Despite indexing, arbitrary queries (ad-hoc, based on partially know structured context) in Zope are very weak (and they will be always weak until ZODB will become a real DBMS project). To make power queries I need some algebra (like relational). Object model doesn't have such. Perhaps ZODB should do the trick opposite to a typical OR-mapping in RDBMS - it should map persistent object to virtual relations based on available information about relations between persisted objects. ZSQL helps a bit but not really yet.

On the other side RDBMS is better to store arrays of data of the same structure (same relational model) - millions (even billions) of records in few (dozens) tables. RDBMS is not good to store few records each in billions of tables. That's why it requires OR-mapping for persisting arbitrary application objects, and that translation makes it work slower.

ORDBMS is supposed to combine both benefits and solve both disadvantages. In practice, all commercial ORDBMS I know (i.e. Oracle) have object layer on a top of relational model, hiding such OR-mapping inside, but still suffering from slow translation. PostgreSQL is an exception (is it b/c it's not commercial?) - in PostgreSQL relational model is implemented being based on a object model since the beginning, without OR-mapping. In PostgreSQL everything is obejct of some class. And as far as I know inheritance is not dropped and actively supported and actively developed further.

Coming back to the practical life, I see one of the main ZODB problems in a lack of ability of being integrated with legacy systems. As for now it is possible to add an external relational datasource to ZOPE (not ZODB) applications. But it is not easy to give the access for exisiting ZODB content to backend legacy applications in a same way as I would do with RDBMS (or ORDBMS). RDBMS is a very important part of a real life and it will be so longer than perhaps a life of ZODB project.

But the main problem of ZODB - it reinvents the wheel. It must be implemented on a top of PostgreSQL since the beginning.

Re:Good times.

[Anonymous Coward]

Aha, writing C in Python will usually lead to disappointment. As an interpreted C without curly brackets, it will certainly be much slower...

Specifically, you don't want to repeatedly append to strings like that unless you use the specializing compiler, psyco.

The common idiom is to convert the string to a list, manipulate the list, and then make it a string again, like this:

l = list(sys.stdin.read())
#manipulate l
print "".join(l)

But in this case, the translate function in the (otherwise archaic) string module seems to fit the bill. Something like this (untested)

import string
# define koi...
table = [chr(n) for n in range(0xc0)]
table.extend([koi[n] for n in range(0xc0,0xe0)])
table.extend([chr(ord(koi[n-0x 20]) - 0x20) for n in range(0xe0, 0x100)])

print string.translate(sys.stdin.read(), "".join(table))

Re:Good times.

[listen]

I was refuting the parents idea that casting strings around proved python was "stronger" typing than perl...

>>> class A: ... def __init__(self, crap): ... self.crap = crap ...
>>> class B: ... def __init__(self, monkey): ... self.monkey = monkey ... ... def __repr__(self): ... return self.monkey ...
>>> something = A("thing")
>>> something.__class__

>>> something.__class__ = B
>>> something
Traceback (most recent call last):
File "", line 1, in ?
File "", line 6, in __repr__
AttributeError: B instance has no attribute 'monkey'
>>>

I can't reconcile that with my view of languages that are strongly typed...

Guido agrees:
http://www.artima.com/intv/strongweak2.ht ml

Notice that strongly typed is always used in opposition to python.
Here he seems to use it as a synonym for statically typed, as most do.

I love python, I just wouldn't classify it as strongly typed. Its possible to mess around with types a lot, and really screw yourself up. Thats before you go poking in the stack frame. But this is not a normal thing to do in python.

Python is what it is, a dynamically typed language.
And thats good for a whole lot of programming domains.

Re:Good times.

[Earlybird]

• The main practical difference between ODBMS and RDBMS is that ODBMS is good for object persistence, not for querying.

Please describe how an ODBMS is "not [good] for querying". There are several ODBMS implementations that have excellent query capabilities. There is nothing inherent in the model preventing it from being appropriate for querying, even ad-hoc querying.

ZODB does not support queries, and relies entirely on an indexing engine (ZCatalog) layered above it.

• On the other side RDBMS is better to store arrays of data of the same structure (same relational model) - millions (even billions) of records in few (dozens) tables. RDBMS is not good to store few records each in billions of tables. That's why it requires OR-mapping for persisting arbitrary application objects, and that translation makes it work slower.

If your relational model requires billions of tables, you have designed it wrong. The difference between RDBMS and ODBMS models have nothing to do with size differences, but with the models themselves.

• ... in PostgreSQL relational model is implemented being based on a object model since the beginning, without OR-mapping

This still does not eradicate the impedance mismatch between objects and tables. Objects can be implemented in the relational model, and probably should, but modern database systems, PostgreSQL included, implement the model badly. To store object-like structures in PostgreSQL, you still have to map sequences and associative arrays to tables, for example. In short, you cannot implement a typical application object model in PostgreSQL without resorting to relational constructs such as many-to-many tables.

• Coming back to the practical life, I see one of the main ZODB problems in a lack of ability of being integrated with legacy systems.

The phrase "legacy systems" implies a system that is using outdated and deprecated technology. If your goal is to integrate with such databases, use Zope's relational database support (Z SQL Methods etc.). What's the point in massaging a legacy system into being the persistence storage for Zope? It's like saying you have this 20+ old mainframe, and Zope is crap because it can't store its data in it. That's silly.

You seem to have sucked up the wrong kind of terminology. PostgreSQL is not a "legacy" system. That is not the issue.

• But the main problem of ZODB - it reinvents the wheel. It must be implemented on a top of PostgreSQL since the beginning.

"Must" is a strong word. Why must the ZODB do the things you want? It already solves the problems it's designed to solve. This sounds like cognitive dissonance to me; it's seems to me that you're desperate to use your PostgreSQL database, even if it's not useful. Have you studied the internals of the ZODB? Can you honestly say that PostgreSQL would do a better job? Exactly which wheel does the ZODB reinvent? It's not an RDBMS. The only functionality overlap with PostgreSQL is its ability to store data persistence. But the data it stores is wildly different from the data models that PostgreSQL support.

Re:Good times.

[hoggy]

Notice that strongly typed is always used in opposition to python.
Here he seems to use it as a synonym for statically typed, as most do.

It is not correct to use "static" and "strong" as synonyms. That would imply that "dynamic" and "weak" are synonyms.

A line from an interview does not an academic argument make. In that interview Guido also says:

Weak typing is not really a fair description of what's going on in Python. It's really runtime typing because every object is labeled with a type.

Every object in Python has a type. Python typechecks all method calls at runtime, raising runtime exceptions where a typecheck fails. But it still typechecks! One object cannot be mistaken for another and no memory corruption can occur from using the wrong operation on an object.

The trick you pull with changing the __class__ of an object is a feature of the dynamic typing of Python. You have changed the method-resolution order at runtime, that doesn't mean that the method-resolution order will not be enforced. The AttributeError exception you see is proof positive that Python is strongly typed - a type error has been caught and has created a runtime exception.

Strong/weak and static/dynamic are orthogonal issues in typing.

Re:Good times.

[axxackall]

Please describe how an ODBMS is "not [good] for querying". There are several ODBMS implementations that have excellent query capabilities. There is nothing inherent in the model preventing it from being appropriate for querying, even ad-hoc querying.

Please, call a name of ODBMS that supports a query language based on some algebra (like SQL based on the relational algebra) *AND* lets me persist objects of new classes without recompiling the schema (generally/practically without stopping the DBMS server).

ZODB does not support queries, and relies entirely on an indexing engine (ZCatalog) layered above it.

Then what's wrong was to support any query language aka SQL, OQL or XPath?

If your relational model requires billions of tables, you have designed it wrong. The difference between RDBMS and ODBMS models have nothing to do with size differences, but with the models themselves.

I might exaggerated with billions of tables, but one of major differences between object and relations databases (when it comes to practical issues) is still related to sizes. I can lean my models to specific model (or implementation) limitations of a particular database, but that is not exactly what I want to do as an application designer. If I want many, slightly-different-from-each-other tables then I have my reason for that. Mixing all such tables to one table (with another one for "generic" attributes) is a sort of generic programming which is not good in RDBMS as the relational algebra doesn't reflect it well and thus an aplication has a problem of queriing from such "generic" database.

ODBMS lets me use inheritance, but as I mentioned above, there is no good, algebra-supported queriing against inheritance.

This still does not eradicate the impedance mismatch between objects and tables. Objects can be implemented in the relational model, and probably should, but modern database systems, PostgreSQL included, implement the model badly. To store object-like structures in PostgreSQL, you still have to map sequences and associative arrays to tables, for example. In short, you cannot implement a typical application object model in PostgreSQL without resorting to relational constructs such as many-to-many tables.

I am not sure about what's wrong you see with sequences, but as for assotiated arrays... Did you try nested tables? In short, object model in PostgreSQL is not perfect yet (although, they are working on it to improve and they have a very good progres in it!), but if you know such limitations then you can minimize a possible OR-mapping and posiible usage of M-2-M tables. The good new is that in PostgreSQL you sacrifice less than in other ORDBMS, and that's b/c the object model in PostgreSQL is better implemented than in other ORDBMS: all schema objects are already classes.

Coming back to the practical life, I see one of the main ZODB problems in a lack of ability of being integrated with legacy systems.

Let me define the "legacy" term. It's like who comes first. Usually SQL-based applications are already designed and work, while web applications are developed later and has to adopt. Most likely a "legacy" application has some other reasons that some part of the technology cannot be changed when we have to integrate it with new, web-based applications. What about a situation when IT has to extend their reports, which are implemented queriing across several SQL databases and they (reports) are not web-based (Oracle Reports?), to include to the query some information from Zope? Would ZODB support SQL - that wouldn't be a problem.

At last. I'd like to ask the question: if ZODB is so good as a DBMS, then why there are so many attempts to improve it in situations when I need one (or all) of the following? -

• arbitrary depth of the folder tree (try it is as deep as 1000);
• very frequent (massive) changes in the folder tree (i.e. inventory in a big warehouse);
• huge collections

Re:Good times.

[Earlybird]

• Please, call a name of ODBMS that supports a query language based on some algebra (like SQL based on the relational algebra) *AND* lets me persist objects of new classes without recompiling the schema (generally/practically without stopping the DBMS server).

Matisse, Caché and FastObjects are only some products that come to mind. Though I can't speak for products I'm not familiar with, I don't know of any mature ODBMS that requires a restart in order to catch schema modifications.

• Then what's wrong was to support any query language aka SQL, OQL or XPath?

You're the one who brought it up.

• If I want many, slightly-different-from-each-other tables then I have my reason for that.

Read up on the relational model and the term "normalization".

Granted, currently relational-like databases don't optimize the normalized forms very well -- leading to so-called database experts recommending denormalized tables and null columns for performance -- and combined with the tight relationship between logical and physical table layouts in such database products, which is further compounded by SQL's awkwardly literal join semantics, properly normalized layouts with lots of tables is often painful. But that's the fault of current implementations, not the relational model.

Interestingly, Caché's SQL implementation adds some proprietary syntactic sugar to do away with awkward joins: You can do things like select e.employer.stock.shareCount from employees e where symbol = 'MSFT', in lieu of the traditional natural join syntax, select si.shareCount from employees, stockInfo si where si.company_id = employees.employee_id and si.symbol = 'MSFT'. As C. J. Date and others have pointed out repeatedly, SQL sucks.

• I am not sure about what's wrong you see with sequences, but as for assotiated arrays... Did you try nested tables?

Afaik, nested tables is another deprecated remnant of the ancient "object-relational" stuff in PostgreSQL, and probably for good reason. (If the PostgreSQL guys are reviving the OO-ish stuff for some application, that's interesting -- do you have a reference?)

What the world needs, though, is a true relational database -- which, I'd like to point out yet again, does not exist -- not more pollution of the relational space. The relational model is extremely powerful and based on fundamental mathematical principles, yet it is not widely, or well, implemented. An object database layered on the relational model would be even neater.

• ... What about a situation when IT has to extend their reports, which are implemented queriing across several SQL databases and they (reports) are not web-based (Oracle Reports?), to include to the query some information from Zope? Would ZODB support SQL - that wouldn't be a problem.

You're talking about a problem that Zope and the ZODB is not designed to solve. Certainly it would be nice if Zope could integrate more seamlessly with relational data, but the idea is to reap the benefits of writing a Zope app from scratch -- and dispense with the "legacy" stuff. If you need to slap a front end on an existing "legacy" Oracle sales database, consider a "legacy"-oriented tool like PHP or AOLserver.

• At last. I'd like to ask the question: if ZODB is so good as a DBMS, then why there are so many attempts to improve it in situations when I need one (or all) of the following? - ...

Because ZODB was created a few years ago, whereas relational-like databases such as PostgreSQL have had years to mature. ZODB is essentially the work of one person. If you need those features in Zope, I suggest you contribute to the ZODB project.

This thread is already pretty off topic and attached to an old Slashdot story, and a waste of energy besides, so I'm not going to continue responding.

Who else thought

[Anonymous Coward]

that someone was leaving zombo.com ?

I was sad

Re:Who else thought

[The Cydonian]

Anything is possible. ;-)

(I know a guy who sleeps daily listening to that voice.)

Security...

[Kai_MH]

I'm not a big fan of Python, but I'm glad he's moving to a security group. The guy is close to being a genius, so let's hope they get some good stuff out.

Guido's goodbye message

[pen]

http://mail.zope.org/pipermail/zope3-dev/2003-July /007598.html

Guido van Rossum guido@python.org
Wed, 09 Jul 2003 10:24:54 -0400

Dear Zope 3 developers,

Last night at OSCON I announced that I am moving to California. I
have accepted a new job at Elemental Security, a security software
startup in San Mateo. You may have heard of one of the founders, Dan
Farmer, who is the (co-)author of several well-known free security
checking programs: Satan, Titan and The Coroner's Toolkit.

Elemental is a brand new company, and I can't say much yet about the
product, except that it will be aimed at enterprise security and use
Python. I'm very excited about working with Dan on its design and
implementation.

I'm also excited about moving to California, which has long been a
dream of mine. I'm looking forward to getting together with the many
local Python users and developers once I'm settled; right now, my life
and that if my family is total chaos because we're trying to find a
home and move into it by August 1st.

I will still have time for Python (it's in my contract) and I will
continue to lead Python's development. The other PythonLabs folks:
Fred Drake, Jeremy Hylton, Barry Warsaw and Tim Peters, are staying at
Zope, by the way.

But unfortunately, this move pretty much ends my involvement in Zope
3. I've signed a contributors agreement, but with the new job and my
Python work I don't expect to have much time for Zope. So this is
also a goodbye, of sorts. I've enjoyed working with many of you, Zope
3 developers, and I expect we'll run into each other at some future
Python event.

In the mean time, I'm here at OSCON with a busy schedule and limited
access to my email, and the following weeks I will be in transition,
so please be kind if I don't reply immediate when you write me.

--Guido van Rossum (home page: http://www.python.org/~guido/)

PS. guido@zope.com no longer works. Please use guido@python.org!

Re:Guido's goodbye message

[jo42]

Oh, good, almost thought that Guido "The Killer Pimp" was leaving the business...whew!

Re:Guido's goodbye message

[Anonymous Coward]

Zope's response follows:

Dear Zope 3 users,

As many of you know Guido van Rossum, who was our chief Python advocate within our development community, has left Zope to work on other projects. Despite our differences, we wish him well in his future endevours.

Guido's departure leaves our team more focussed than ever, as we can finally put together a sensible, agreed upon, product based upon a clear and consensus driven design. As part of this, we announce that we are switching to Perl for Zope 3 with immediate effect.

This change means that Zope will be based upon the scripting language that, arguably, built the Internet. Perl is widely known, is extremely flexible, and has the support that Enterprise level Web based applications require.

We will issue a revised timetable shortly, but our intentions are to coordinate the final Perl-based release of Zope 3 with Perl 6, with the release of the former being within a week or two of the point-zero release of the latter.

We are sure all of our developers will be glad to hear of the changeover, as this will bring Perl's benefits while losing the well documented problems related to our use of Python. Everyone stands to benefit from this change,

Zope.com

Surpassing Perl?

[gavri]

Excuse me, but that's ruby's job!! :)

"Python is 'already quite secure,'"

[TheGreenLantern]

That sound you are hearing is a thousand hackers and script kiddies going "Oh yeah?" in unison.

Re:"Python is 'already quite secure,'"

[DeltaSigma]

It sounded more like 5% hackers going "Oh yeah?" and 95% script kiddies scratching their heads...

Re:"Python is 'already quite secure,'"

[notque]

That sound you are hearing is a thousand hackers and script kiddies going "Oh yeah?" in unison.

No, That's this.

Re:"Python is 'already quite secure,'"

[Just Some Guy]

I think he was referring to its existence, not any inherent invulnerability. As in, it's firmly entrenched and will continue to be developed.

Re:"Python is 'already quite secure,'"

[Pxtl]

Hell, I'm a Python coder, and I'm already going "oh yeah"

IMHO, it won't be secure until they bring back Bastion and Rexec and get them right this time. Actually, all I want is to be able to remove all the builtins that access the system directly (so Python can't crash your computer, delete files, or otherwise access the filesystem) - but while the language and API documentation is pretty good, the compiler variables are wholly unkown.

Re:"Python is 'already quite secure,'"

[arkanes]

What the hell use is a scripting language that can't access the filesystem?

Re:"Python is 'already quite secure,'"

[Pxtl]

For embedding into applications - the application should be handling all the content moving in and out of the scripting engine. Alternately, to allow the user to develop a secure, proprietary filesystem or file access or system calling system within an extension module, independant of the unsafe main filesystem. This puts the burden of security on the person building the application - not the end user who will be scripting (which is unsafe) or on Python itself.

Re:"Python is 'already quite secure,'"

[spRed]

IMHO, it won't be secure until they bring back Bastion and Rexec and get them right this time.

read the python mailing lists for a full explanation. They were yanked because they not only didn't do the job right _it is not possible_. Restricting disk/CPU/memory usage is an operating system job. Trying to build it into the language (like java) just makes things really complicated (for both core developers and users) and still doesn't work.

Re:"Python is 'already quite secure,'"

[sketerpot]

Let's say that you download python gui scripts for a web browser---python applets. I believe this is something that Grail can/could do. How would you run them safely? I'm not attacking you; I'm curious.

Re:"Python is 'already quite secure,'"

[Evan]

It's rather tangled up in Zope, but there *is* a way to execute untrusted Python code safely (for certain definitions of "safely"). It's used by "Script (Python)" objects, and involves compiling the code into a semantic tree, walking the tree applying transformations and looking for forbidden operations, then generating bytecode. The generated bytecode is also executed with a globals dictionary that contains a custom builtins dict. Zope's security framework is used to control access to packages and modules. Zope 3 takes a totally different approach based on proxy wrappers, but there it is.

Re:"Python is 'already quite secure,'"

[Anonymous Coward]

If you enable it, you can use Python for client side scripting for Internet Explorer in Windows, since it works with the Windows Scripting Host.

It's certainly not safe toady to run untrusted Python scripts like that. I'm not sure any non-trivial system for running untrusted code has ever been proven safe though...

Stay!

[blackmonday]

..known from several security tools such as Satan ..."I'll be working from the West coast".

Please, stay where you are, sir. We have enough problems out here already.

His Website

[Captal]

Here is his personal website:

http://www.python.org/~guido/

Who names this stuff?

[Laur]

We have the Yopy 3700 and now someone's leaving Zope.com. Has Disney been put in charge of naming things lately? Try the new Dopey 2003(C)!

possible improvements to python?

[PhysicsExpert]

Hopefully the job change will allow him to concentrate a bit more on python, its a great language that we in the lab are using to replace all our old apps that were written in VB and java.

One thing I would like to see would be python to become even more object oriented which would give it greater flexibility and would mean that the code would not be so long (our Vb code is about 2-3x shorter than the python code). Perhaps they could do this by borrowing a few tips from perl, which although slower has code that looks much neater.

Re:possible improvements to python?

[vivek7006]

"Perhaps they could do this by borrowing a few tips from perl, which although slower has code that looks much neater."

Perl code looks much neater than Python?
Are u nuts?

One of the strong points of Python language is its clean and intuitive syntax. Perl is a very powerful language, but its strong point is *NOT* neat syntax.

Re:possible improvements to python?

[William Tanksley]

Could you clarify what you mean? Python is already fully object-oriented (although it doesn't _force_ you to write object-oriented code, but then neither does VB).

And are you joking about Perl? Perl is widely known for having MUCH messier-looking code than Python, but running slightly faster on certain tasks.

-Billy

Re:possible improvements to python?

[mjsiley]

Python _is_ more object oriented then VB. VB6 is object based, since there is no inheritence. (and python supports single and multiple inheritance) Perl neater then Python? I love both languages but Python programs are amazingly more readable then Perl programs. Perl slower then Python? not in my experience. They are really close in performance. see, http://www.bagley.org/~doug/shootout/ And have you done OO in Perl? compared to Python it's a pain. VB code 2-3x shorter then the Python version? I've had the exact opposite experience and usually the Python version is 5-10x shorter then the VB version.

Re:possible improvements to python?

[Zathrus]

PhysicsGenius is a known troll... and it's amusing to see just how many moderators get caught by him. All of his posts have just enough in them to sound intelligent, but they're all very deeply wrong -- usually twisting the facts backwards (such as this one) or flying off into realms of thought usually reserved for the insane.

Maybe some moderators with a clue will beat the grandparent post down now.

On topic - I've known Perl for awhile and am starting to code in Python... the syntax is certainly cleaner, but the docs certainly aren't. To put it kindly, they suck. Yes, if I was sufficiently motivated then I could contribute instead of just bitching, but: A) I'm not, B) I don't know nearly enough Python yet to do it right. I find Perl's documentation to be layed out in a much more rational and useful structure. Shrug.

Re:possible improvements to python?

[Anonymous Coward]

Are u nuts?
U must $be a prl.prgrmr 2'

Re:possible improvements to python?

[Jason Earl]

That's funny. I switched from Perl to Python several years ago and one of the things that I like best about Python is the documentation. Perl's Camel book made a pretty fair reference, but I didn't really like busting out a hard-copy book every time I wanted to look something up. The electronic Perl documentation was pretty nice, but it wasn't quite as comprehensive as the Camel book, and the POD format simply can't compete with Python's documentation. The PDF and HTML formats are nice, but I really like the fact that the Python documentation is available in info format for easy reading in Emacs (complete with a comprehensive index). The indexes in Python's electronic documentation really make a heck of a difference once you start using them. Perl's pile o' man pages simply can't touch Python in this regard (IMHO).

Perl's TIMTOWTDI style means that every time you edit someone else's Perl code you will encounter four or five new Perlisms that you have never seen and that require the Camel book for deciphering. When I was hacking Perl, that meant carring around the Camel book in my laptop bag "just in case." With Python that's no longer a problem.

My guess is that you have gotten use to the structure of Perl's documentation. You know where to find Perl information, and are simply frustrated by the fact that Python requires that you start from scratch with a new set of documentation.

On the other hand, it is possible that we simply have different documentation requirements. What precisely is the problem? "They suck," is not particularly descriptive.

Re:possible improvements to python?

[Dr. Smeegee]

My Gh0d you can troll! You are subtle like Fu Manchu, erudite like Christopher Hitchens and a real smart feller, besides.

Always nice to have your brain leave skidmarks

Re:possible improvements to python?

[Mantorp]

Just went to read a few of his last posts, wonderful stuff. Really funny.

Re:possible improvements to python?

[Anonymous Coward]

That's not PhysicsGenius, it's PhysicsExpert, a cheap knock-off. Accept no imitation!

-a PG fan

Re:possible improvements to python?

[Zathrus]

Dang it, I meant to put in some concrete examples but apparantly forgot. Blergh.

First off, I'm using the Python 2.1 docs -- they may be outdated and the more recent 2.2 or 2.3 docs may be better, but 2.1 is what's installed on our development and production boxes, and we dislike changing those kinds of things unless we need to.

The C API docs stink. There's not a single complete example in the doc tree (on python.org) that I've found -- just snippets here and there. There are references that extending Python is very simple (and, indeed, it does appear to be now that I've found sufficient docs) and there's even tools to automate most of it. But nowhere are the actual tools referenced/linked to, there are calls used without explanation or links to explanation, and the docs suddenly shift between extending and embedding without adequate differentiation.

I dislike the break between the "Extending and Embedding" section and the "Python/C API" section. Yes, one's a tutorial and one's a reference, but the tutorial is thus missing vast amounts of info that are only present in the reference section. Bad.

I'm not real happy with the organization of the Global Module Index. There's a couple hundred default modules, and sometimes you have to go hunting through several different ones to find the desired function. The Library Reference is often lacking in reference as well -- for instance, section 4.2.4 (Regular Expression Objects) describes the re.sub() function which is "Identical to the sub() function, using the compiled pattern". That's nice. Where's the built-in sub() function? It's not in section 2.3 - Built-in functions. Nor is it a string.* function. I've looked in the places that made sense to me, and gave up, using string.replace() instead (which is what is appropriate for my usage, but I'm still wondering). I finally found some documentation on the print statement. In the "Language Reference" section (which makes sense... except that it's subtitled "for language lawyers"). And I'm still wondering about a 'print "bleh %s bleh" % (val)' construct I used... copied from elsewhere, since I can't figure out what the % is doing except by reference. I'm sure it's documented... and I'll eventually find it... but it's annoying right now.

By and large I suspect you're correct -- I'm used to the Perl docs and know where to find things. I'll eventually get used to the Python docs as well. But in the meantime I'm finding it annoying to learn. I should probably go out and pick up the O'Reilly Python book... I learned Perl from reading the Camel (1st ed) and hacking away at things. Doing much the same with Python, but the online docs are frustrating me at the moment due to a lack of global indexing (beyond site wide search which is vast overkill).

Re:possible improvements to python?

[Jason Earl]

Woah. Talk about concrete examples. As for your problems with the C API docs, I don't know what to tell you as I have done very little Python + C work, and the bit that I have done was mostly guided by Mark Lutz's book and the fine example of PyGreSQL. It's very likely that your criticisms of that part of the documentation are true. However, my guess is that extending Python via C is still easier than getting your mind around Perl-guts.

As for the rest, my version of python doesn't have a built in sub() function. The re module does have a sub() function, but that's fairly well documented. The '%' operator is covered very well in the tutorial, and it does more than you expect (or are likely to use). Print doesn't have much documentation because it is fairly straightforward. The tricky bit in your example is due to the '%' operator. This operator doesn't have to be combined with print statements either. I use it all the time to create SQL statements like so:

sql = "SELECT * FROM %s WHERE bar = '%s'" % (foo, bar)

If you haven't skimmed the tutorial all the way through I would highly suggest it. It starts out slow, but it gets better as it goes along.

I own the O'Reilly Python book, and it is good, but it isn't nearly as necessary as the Camel book (although the examples on extending Python with C would probably be worth your time :). The fact that you are hacking Python without buying the O'Reilly Python book actually speaks fairly well for Python's documentation. Try doing that with Perl.

Thanks for a very excellent post.

Re:possible improvements to python?

[Ricin]

Ever tried pydoc? Built in. Browse the APIs. Usually with some explanatory text (that's built in also if you use docstrings). Once you grok the language this is all you need most of the times.

pydoc -g

Re:possible improvements to python?

[Peaker]

The C API docs stink. There's not a single complete example in the doc tree (on python.org) that I've found -- just snippets here and there. There are references that extending Python is very simple (and, indeed, it does appear to be now that I've found sufficient docs) and there's even tools to automate most of it. But nowhere are the actual tools referenced/linked to, there are calls used without explanation or links to explanation, and the docs suddenly shift between extending and embedding without adequate differentiation.

You can find C extension examples in the Python source code (Modules/xxmodule.c, Modules/xxtype.c, etc.).

Also, you might find writing extension Python modules much easier with Pyrex.

This is a superset of Python that compiles down to C code, that compiles to extension modules.

Its a very neat language, and makes C extensions very easy and useful.

The disadvantages over using C directly that I see (I have by no means used Pyrex extensively):

Python object calls will be less efficient than extension C code. For example, calling my_list.append in Pyrex, where my_list is a Python object, will look up "append" in the object's dictionary in runtime, where a human programmer would use PyList_Append() avoiding the lookup.

It may require a bit of work duplication, requiring Pyrex declarations that duplicate existing header files of C functions and types you want to use.

Re:possible improvements to python?

[Zathrus]

Heh. Well, I'm quite literally working on this stuff when not avoiding doing work by reading /., so it's quite fresh. :)

And yes, it is still easier than dealing with Perl-guts... the docs for that (last time I glanced at them, which was years ago) were quite horrid, and I've never tried it myself anyway. Still having issues at the moment (core dump upon import), but investigating the causes and solutions. Things are moving.

The re module does have a sub() function, but that's fairly well documented.

Yeah, but the bit of docs I quoted are from the re.sub() documentation! Like I said, really annoying when it references you to something that doesn't appear to exist.

I just looked back at the tutorial and found the section on the % operator -- which does exactly what I thought it did. I suspected that it wasn't tied to print, and it's definitely a nifty and good way to format things. Thanks for the heads up on where to find it.

As for books, one of my coworkers has the Python 2.1 Bible, which had far better info on some of the aspects of extending Python. It's at least gotten me to the core dump stage :). All we're really looking to do with Python is a load test tool and some Big Brother monitoring scripts (the latter of which is needing the extention -- that or rewrite a thousand+ lines of C++ for python and then maintain both whenever something changes) so it's not entering into our development in a big way. Yet. But it's unlikely that we'll use any other advanced scripting language at this point, since increasing the number of languages utilized (currently C++, shell script, SQL, and Python, with Java being used in another part of the project) just makes maintainence more and more difficult.

Doing Perl w/o a book is possible... but doing it without a book or the man pages/online versions of same would be a PITA. I don't actually own the Camel or Llama... the man pages are perfectly good for me. I also don't read other people's perl script though :)

Re:possible improvements to python?

[mwh]

"The C API docs stink."

These are better in more recent versions (I know, I wrote the new sections :-), and there are more improvements in 2.3.

"I dislike the break between the "Extending and Embedding" section and the "Python/C API" section."

Yep. I've been meaning to do something about that for at least a few years now...

Re:possible improvements to python?

[Troll_Kamikaze]

>> The re module does have a sub() function, but
>> that's fairly well documented.
>
> Yeah, but the bit of docs I quoted are from the
> re.sub() documentation! Like I said, really
> annoying when it references you to something
> that doesn't appear to exist.

No, you quoted the docs for the sub() *method* of compiled *regular expression objects* (which are implemented in the underlying C module _sre; returned from the re.compile function).

Look at the docs for the sub() *function* of the re *module*, and you'll find what you want. You can access it online right here:
http://www.python.org/doc/current/lib/node9 9.html#l2h-732

Prominently on python.org

[gavri]

"Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language." said Peter Norvig, director of search quality at Google, Inc

I should read more carefully...

[H0NGK0NGPH00EY]

...I was rather confused for a moment how a story on zombo.com would make /. front page.

Re: =You have obviously missed the point

[botzi]

I could see Python easily surpassing Perl as a strongly-typed effective scripting language.

Which unfortunately has nothing to do with the ideas behind Python.
It tends to be much more than "strongly-typed effective scripting language" and if there was some big corporation promoting it as development platform(not even providing support, the guys from the team are doing really good job) , you can bet that Java would had one more serious competitor to worry about...

How instrumental was he to zope?

[nurb432]

With python there is no question his importance, 'with out Guido there is no python'.. ( thankfully that wont change, that would be a tremendous loss to the community )

What his is level of involvement with zope? Does this spell a slow painful death or just a minor speed bump.. ( I admit I don't follow *new* zope development so I'm just curious )

Re:How instrumental was he to zope?

[Anonymous Coward]

He's been quite involved with some aspects of Zope 3 development, but it doesn't spell a slow painful death. Speedbump would be my (anonymous coward :) best evalution, though it certainly is a loss.

Re:How instrumental was he to zope?

[BitDancer]

Speaking as a Zope 3 contributor, though not one who's had time to
do much more than follow the mailing lists, here's my take: Guido
was a good occasonal contributor to Zope 3, and a useful voice in
critiquing design decisions and so on (his unique perspective on
the consequences of Python design on Zope design descisions was
particularly beneficial). Most of his Zope 3 contributions came
in the form of code whose needs originated in or were informed by
Zope 3, but which were actually developed under Python Labs. (I
could be wrong about this, but that's my impression). I'm guessing
we'll see his influence on Zope 3 continue through his Python work.

I don't think I'd even classify his departure as a speed bump in
the Zope 3 development process. Maybe the speedometer will drop a
few mph, but I'm pretty sure Zope Corp will assign someone to fill
in the gap in terms of code production.

Guido is the Python BFDL (Benevolent Dictator For Life). For Zope
(and Zope 3 in particular) the corresponding role is filled by Jim
Fulton, who is fondly known as the Zope Pope. It's Jim's vision
and drive that informs Zope 3 development, and always has been.

So, Zope is alive and well, and I for one wish Guido luck
and fun in his new persuits!

--RDM

and in other news

[British]

David Finkelstein has announced he is leaving McDonald's to work at Subway.

Elemental Security

[Call Me Black Cloud]

Great! I've been hoarding oxygen and have become increasingly concerned that my neighbors may try to liberate it. Damn free radicals.

Wait wait wait.....

[botzi]

... I have a better one:
"You...you...you(obviously having a hard time finding the word)........... moron!!!"
*going out with a smash for the door and a finger for the person*

...or is it too girly??? Well, anyway.....;o))))))

Re:Wait wait wait.....

[hesiod]

> *going out with a smash for the door and a finger for the person*
> ...or is it too girly???

Yes, it's too girly. Which makes it perfect! hehe

Re:Prominently on python.org

[Randolpho]

Er.... I know python pretty well. Perhaps I should send my resume? :D

Something fishy in his goodbye message

[Coventry]

PS. guido@zope.com no longer works. Please use guido@python.org!

If he was leaving on good terms with Zope corp (ex digicool), then why the sudden switch in email adr? I know, big corps cut you off the second they can when you leave, but not even forwarding his mail smells fishy - like there was some kind of falling out or disagreement behind the scenes.

Yes, I'm a paranoid freak, but there is more potential evidence in his goodbye - he never thanks Zope corp for his time there and thier support. In fact, except for saying that the rest of the PythonLabs people are staying, he never mentions Zope corp (though he does mention Zope the project many times). This could just be due to limited time and his forward-looking nature, but it just reads oddly to me...

Re:Something fishy in his goodbye message

[Anonymous Coward]

Yes, Guido is leaving on good terms. There is no conspiracy here, he just wanted to move to California. I'm sure his email won't just bounce, but this is his way of saying, please don't use it any more. He prefers his python.org address.

Re:Something fishy in his goodbye message

[Coventry]

This makes me feel much much better - I think the suddeness of the anouncement (for those of us who don't know the behind-the-scenes goings-on)triggered my conspiracy alarm.

Re:Something fishy in his goodbye message

[umoto]

No, there is certainly no disagreement behind the scenes. Guido sent a private announcement to an internal list. He expressed much appreciation for Zope corp. and everyone here.

He's only changing his email address because he no longer works here. His email will probably be forwarded anyway.

What we don't need in California ...

[Chromodromic]

... is yet another guy named "Guido" wanting everyone to admire his "Python".

SoCal is the land of double entendre and uber-image, Mr. Van Rossum. We don't care about your substance, we want to know about your style. So the question the really needs to be answered now is,

Python: Is It Sexy Enough? Join us on E! when we ask your favorite celebs just what scripting language they use for their daily information processing! We know Pamela Anderson loves Perl, and Carmen Daily is crazy about Java, but what happens when these two sexy stars get their hands on Python? Watch at 11 and find out!

Re:What we don't need in California ...

[leshert]

I think you have a typo in your post subject. It should have been spelled "Why we don't need California"; make this change, and your post makes perfect sense.

Re:What we don't need in California ...

[Anonymous Coward]

SoCal is the land of double entendre and uber-image, Mr. Van Rossum. We don't care about your substance, we want to know about your style. So the question the really needs to be answered now is,

Umm. San Mateo is in Northern California. The folks in Humbolt Co. might argue that it is really Central CA, but it is definitely not in SoCal.

Re:What we don't need in California ...

[Anonymous Coward]

Guido is moving to San Mateo, which is more NorCal than SoCal.

My Network security...

[Lord_Slepnir]

known from several security tools such as Satan

I tried satan for my network security. Cost me my soul, but it's damn good. One kid tried to hack around our proxy to play games at work, and he got engulfed in flame and dragged down to the 3rd layer of hell for the rest of the day! Sure, I have to use a massive water cooling system to keep the firewall (and I mean a wall of fire that I run the ethernet cable through) from melting the other servers, but when the dark lord is watching your back, you don't even have to think twice about security.

Re:My Network security...

[makapuf]

I guess this product implements the evil bit ...

Re:My Network security...

[Anonymous Coward]

IF you must abuse dante get the terminology right: its the third level of hell or even the third circle.

Re:My Network security...

[rthille]

Yeah, you don't have to worry about security, because you've already been 0wned.

Re:Prominently on python.org

[MikeFM]

I've tried and I even have friends already working there to use as references. My impression has been that for any kind of fun job there you need a PhD or at least a Masters. Oh well.. we can always dream.

A more interesting project would be to make a search engine that functions as well as Google on a much more modest budget. That's an ongoing game of mine. I figure if I ever succeed maybe they'll hire me finally. ;)

Quite secure, eh? Not according to Guido.

[Whip-hero]

Python is "already quite secure," he says, and will be the basis of an upcoming security product ("just getting started") from Elemental.

I'd like to point out a thread that I found a little while back on Python-Dev about Guido's decision to remove the rexec module (similar to the Java sandbox):

posting 1

and Guido's reply:

posting 2

A little bit further down that thread we find this:

posting 3

Since this last one is particularly telling, I will quote the relevant text for our impatient readers:

I think Guido's rationale for removing all these features will be widely misunderstood. Me channeling him: it is not that he believes that the architectures developed were inherently incapable of providing security. Instead, he feels that no "expert" for these matters has reviewed these architecture for flaws, and that the continuing maintenance of these things isn't going to happen.

If this understanding is correct, then any new approaches will likely suffer from the same fate. Unless somebody steps forward and says: "I am a security expert, and I guarantee that this and that feature is secure (in some documented sense)", then I think he will dislike any changes that mean to provide security.

So this not a matter of engineering but of authority. Somebody must take the blame, and Guido doesn't want to be that someone.

Disclaimer: I love python. However, I am working on a project that depends on rexec, and when I discovered that it was being removed, I was a little annoyed - especially at the reasoning behind the decision.

Re:Quite secure, eh? Not according to Guido.

[DavidNWelton]

As an aside, Tcl has a very nice sandbox that is secure and has been for a while. Check it out:-)

Re:Quite secure, eh? Not according to Guido.

[Pxtl]

Me too - the problem is that there is no longer any mechanism for running untrusted code. I would be satisfied with a bare-bones approach - the ability to compile the Python interpreter with no access to the system (no calling sys, no access to filesystem) so that everythin would be done through extension modules. This would be not nearly as complicated as Rexec, and should be doable with a reasonable degree of security.

Re:Quite secure, eh? Not according to Guido.

[Anonymous Coward]

I am working on a project that depends on rexec, and when I discovered that it was being removed, I was a little annoyed - especially at the reasoning behind the decision.


I can understand dissapointment at a "feature" disappearing, but his reasoning was the soundest decision that I have heard of in a long time.

Security is inherently hard. (In all other areas of programming, the enemy is entropy. When it comes to security, you need to be able to withstand malevolence) Coding your own security w/o taking the tome (years) to be come a security expert is like rewiring your own house by climbing up the nearest power pole with an extension cord. In both cases you're gonna get knocked on your ass.

It takes a wise and humble person to acknowledge this.

Re:Quite secure, eh? Not according to Guido.

[Whip-hero]

I can understand dissapointment at a "feature" disappearing, but his reasoning was the soundest decision that I have heard of in a long time.

I don't disagree with the decision itself - there is another thread on that site (lost the link) that implies that the new class semantics in Python 2 make it impossible to implement an effective rexec environment. In that case, rexec is a moot point.

But, after accepting that, I hear Guido saying that Python is secure and is being used for security projects. Is that wise, considering that he is removing features because he is afraid that insufficient security consideration was taken in the design? I always thought that the Open-Source development methodology was supposed to fill in those kind of gaps by leveraging the expertise of many people.

Re:Quite secure, eh? Not according to Guido.

[Zebbers]

he meant secure as in the development of python will continue

nice rant though!

Re:Quite secure, eh? Not according to Guido.

[Anonymous Coward]

with your logic the next thing you'll be saying is that because python can't guarantee rexec security that its a terrorist language and anyone who uses python is a terrorist. what next, rumors that guido isn't moving to CA but has really been disappearred by the govt and replaced with an eliza bot?

rexec doesn't belong in the main python distro unless someone is willing to do a full audit and maintain a full security test case. otherwise people will use it expecting protection without understanding what they're doing.

you can still use rexec if you like, but only as an add on module.

Re:Quite secure, eh? Not according to Guido.

[Whip-hero]

Whoa there, Anonymous! And perople were saying that I was looking for an excuse to strut!


rexec doesn't belong in the main python distro unless someone is willing to do a full audit and maintain a full security test case. otherwise people will use it expecting protection without understanding what they're doing.


What - unlike the Linux Kernel or OpenSSH? The source is open so that people can check it for bugs. I know that's not the same as a formal audit, but we couldn't do any worse than the closed source JVM from Sun. We both know that make check sets loose a whole battery of tests, and the Python-Dev thread I mentioned shows code that could go into a PyUnit test case. So, what's the problem?


you can still use rexec if you like, but only as an add on module.


No, you can't - that's the whole problem. Rexec wasn't removed because it had a bug; it was removed because the language changed. A new type of class was introduced, so-called new style classes, that inadvertently broke rexec. By using a new style class, you can break out of an rexec jail.

I don't care that a security hole was discovered. I'm just irked because Guido chose cute class semantics over an established security-related module. It wasn't even an either-or decision - he decided not to fix the module just because he didn't want to deal with it. My project will no longer use Python simply because it can't now that rexec is gone. If this happens to many other projects, Python's future won't be secure in either sense of the word.

Re:Quite secure, eh? Not according to Guido.

[Reality_X]

So, just copy the rexec.py and make it local to your application, then import it.

Problem solved.

Least ugly?

[Dr. Smeegee]

Looking at Guido's Home Page I noticed that his picture shows a clean, healthy looking guy with all his hair.
I hereby cast my vote for Guido VanRossum for Least Ugly Open-Source Project Leader.

Re:Least ugly?

[Anonymous Coed]

Believe me, I know from experience that Europeans of all kinds can be as fat, as stupid, and as you have demonstrated, as prejudiced as anyone else.

Re:Least ugly?

[Anonymous Coward]

I think you missed the thread on the relative attractiveness of Hans Reiser (not in the old photos, where he looks sketchy and gross, but the new ones where he's cut his hair and put on a few pounds). He's got my vote! Yummy!

Re:Least ugly?

[Pxtl]

Seconded.

Re:Least ugly?

[gavri]

I don't think so!!!

Reliable sources say that Tom Cruise is a closet geek and leads three projects on Sourceforge.

Oh! and BTW Pamela Anderson is one of the leading coders for apache. Works with a nick.

Re:Least ugly?

[Dr. Smeegee]

Well, if Hedy Lamarr can invent spread-spectrum radio, I guess Pam Anderson can code. (VIP is rather wry on occaison...)

A shame

[GeorgeH]

Zope is a very cool web application system, and while I don't know of Guido's specific contributions I have to assume that they were great. Still, I'm confidant that Zope will carry on.

For those not familiar with Zope, it is a web application server written entirely in Python. It features an object database that, for example, lets you create an image object, and then call it from other code to automatically build your image tag based on the dimensions and title of the image stored in the object.

It's open source, developed both by the Zope community and the Zope corporation. There are at least two kick ass, open source content management systems built on top of Zope Corp's content management framework that I know of: Plone and Silva. There are a ton of add-on products that are downloadable too.

Zope does have a pretty steep learning curve, if you don't do stuff with "real" web applications (stuff that needs access control lists, user management, templating, etc) it might not be right for you, but it's great for bigger applications. Edd Dumbill talks in a recent blog entry about why Zope is worth learning and DevShed (which runs on Zope) has a good overview.

Guido and Dan Farmer are both smart guys and I'm sure that we can expect good things.

Re:A shame

[axxackall]

By the way, what's so good about Silva? What can it give me that CMF cannot?

I hope it's not another BeOpen

[Anonymous Coward]

I hope it's not another stupid mistake like joining BeOpen.com at the height of the dot-com frenzy. No one knows Elemental's business model, but I would expect it is less fanciful than BeOpen's idea to sell advertisements to open source developers. I would bet the other PythonLabs team are not joining because they don't want to get stung again.

Then again, it could also be seen as a statement about Zope's (the company, not the technology) viability, or, alternatively, about the resurgent health of the startup world.

Whatever the case, best of luck Mr. Rossum.

Jumping WAY OT

[mhesseltine]

About your sig: how does bash.cx relate to bash.org?

Re:Jumping WAY OT

[pen]

Yes, bash.cx and bash.org are related, but they are not the same thing. They run different scripts that were written by the same person, but they are not the same site. Both are forks of the original IRC Quote Database that was located at geekissues.org/quotes/

list of new features at bash.cx

(Please don't mod offtopic; The parent's author doesn't provide any way to contact him privately.)

Re:Shut up NAZI!

[Anonymous Coward]

The French and Dutch were the biggest slave traders. Of course, the Africans themselves did the dirty work of rounding up competing tribes and selling them to the slave traders.

this was clear-cut

[Anonymous Coward]

The module advertised to do one thing, "restricted environment" but then failed to deliver. Guido had an obligation to mark it broken and/or remove it.

As for fairly secure, python does not have a sandbox... but I hardly think that the lack of a sandbox makes python insecure.

Re:this was clear-cut

[Whip-hero]

The module advertised to do one thing, "restricted environment" but then failed to deliver. Guido had an obligation to mark it broken and/or remove it.

As for fairly secure, python does not have a sandbox... but I hardly think that the lack of a sandbox makes python insecure.


I'm not disputing the decision - if rexec wasn't salvagable, it should have been dropped. And the specific issue of having a sandbox is not really the point. Guido is saying that he doesn't have confidence in his sucurity design skills, but then he says that Python is secure. Why should we trust the C runtime to not have buffer overflows?

If he wants to say that Python is secure, he should stand behind one of Python's only explicitly security-related modules.

Re:this was clear-cut

[Peaker]

Writing C code that works ok, and designing a secure sandbox require different skills.

According to my aquiantance with the Python C code, the first skill is there :)

As for the other, I am not sure.

I don't think so...

[Da VinMan]

Granted, badly written Python can be hard to read, no doubt about it. However, I will assert that it's simply not possible to obfuscate Python to the same extent as C or Perl. It just isn't possible.

Go ahead and show me some nested lambda + encoding of eval'ed source + pickle or some other monstrosity if you like, but it will have to be indented properly to even execute. ;+)

Re:I don't think so...

[rhaig]

you may have missed my point.

there's no reason to obfuscate python or perl. (or any other language) Readability should not be a question of what language you're using, but a question of what programmer is writing the code.

don't even get me started on the fortran-like indentation nazi-ism. That's not what we're discussing. That's a whole different rant.

Re:I don't think so...

[Da VinMan]

We may have to agree to disagree. I understand your assertion but I will maintain that the choice of programming language does in fact affect the readability of the solution. This is especially true when you consider that the choice of a language often goes hand in hand with participation in a given software sub-culture. That plays right into your idea of readability being more a question of the programmer in question rather than the language, so we may be saying the same thing from different perspectives.

If you don't believe that the choice of programming language affects readability, I can easily find programming languages which, no matter who the programmer, are not readable by any standard.

As far as the Pythonic indentation issue goes, I stand by that concept as well. It requires less typing, less reading, and it's more a question of suspending habits from other programming languages than anything. The only reason I see people objecting to it is because they're too used to brackets, which isn't much of a reason IMO. I will say though that I DO wish Python had a bracket option for the language. It wouldn't be hard to add and it would finally silence all the detractors who use this (minor) issue to bash Python. It gets old. Continuing to use that issue to bash Python is like bashing Perl because the variables look too much like QuickBasic.

Re:I don't think so...

[rhaig]

I think we're on the same side here. language selection shouldn't determine readability, but I agree it is a factor.

I've long though there needs to be a braces option in python. Like you say, it is a minor issue, and too many people harp on it. There are nits to pick with all languages (except maybe ruby, but I haven't looked at it enough yet to say). You can't please everyone, nor should you.

Re:I don't think so...

[sketerpot]

Python already has a sort of system in place for block delimiters. Mind you, it's rather ugly, so I don't use it.

Re:I don't think so...

[mapMonkey]

I think that's supposed to be funny ... no?

Re:I don't think so...

[Erich]

From the FAQ:

4.15. Is it possible to write obfuscated one-liners in Python?

And, yes it is.

Though I do believe it is much easier to write readable, maintainable Python code than it is Perl code. I certainly find that I can understand my Python six months later. Perl is typically a different story.

Re:I don't think so...

[Da VinMan]

Well, that *is* hard to read, but it's nothing compared to much of the obfuscated C code I've seen.

Try that in Python!

Re:I don't think so...

[sketerpot]

Hey---it was funny when I got modded as Informative for linking to a joke....

Fag

[Anonymous Coward]

I was watching The Learning Channel yesterday. They were showing all the anti-UFO movies, you know the ones with the euro-accent fat guy who discredits UFO's while having sex with a mare in-front of Area51; and then they cut to a close-up of that bug-eyed Nuclear Physicist with the American Lisp in his voice. Cut to the commercial... Some new fucking show called "Gay eye for the strait guy." One question, will you watch it? It has the fucking ass-fag hammered homosexual guys in Mob-style clothing, thinking they are all sexy because they're the gays out of a normal job requiring perspiration, and they run around saying heterosexuals can't clothe themselves correctly. Is that fucking great, or what? That's just what I want...a homosexual cumming over to my end of town, and telling me that I should be wearing a $200.00 coat and tie as I clean and package lobsters to be sent to restaurants.

Beam me up!

Emmental security?

[imAlive]

emmental is a swiss cheese known for it's big holes.

Re:Emmental security?

[Anonymous Coward]

goatse is a french guy known for his big hole.

Somewhere, on a distant server

[Anonymous Coward]

Python script: Don't mess with the sexy

Welcome Guido

[nytes]

Dear Guido:
Welcome to California.

Your share of this year's $38 billion deficit is estimated to be approx. $5000.

Thank you.

Pseudocode?

[rRaminrodt]

I guess you don't like pseudocode very much then...

Personally, I couldn't be bothered writing out brackets when scribbling stuff by hand. Yes, it takes a little bit of getting used to, but after using psudocode a little while (for me it was in school) you get used to indenting your code blocks.

Good God!

[Anonymous Coward]

I was reading a post about three or four posts above this one you are reading, and I discovered a URL to the python website's index of projects that actualy use python. Great list of projects, until you reach one at the near-bottom...

COAS
Caldera, a prominent Linux distribution and development company, is developing the Caldera Open Administration System (COAS), to provide a comprehensive and coherent framework for implementation of Linux system administration mechanisms. Among other things, COAS is designed to provide a plug-in framework for administrative-task modules which are written in Python or C++ (or both).

Damn you SCO! Defiler of technology! Damn you to hell!
(For those who don't understand, Caldera is a product of SCO. SCO is the recent bastardizer of Linux. EOF)

NEWSFLASH

[Anonymous Coward]

Girlfriend! I don't like your tone!

That's just what I want...a homosexual cumming over to my end of town, and telling me that I should be wearing a $200.00 coat and tie as I clean and package lobsters to be sent to restaurants.

If you're a fish packer, then you shouldn't be reading Slashdot. It's WAYYYYYY above your head. Style is EVERYTHING if you want to get laid. I'm willing to bet your stinking carcass doesn't get any action gay or straight. Well i say talk to the hand cause the face ain't listenin' sistah!

Re:NEWSFLASH

[Anonymous Coward]

I work for me. I trap lobsters and fish to be cleaned and packaged for fresh-under-4hours delivery to local seafood restaurants.

Believe me...You are wayyy over your head. Using the latest GPS receiver and linux software, I keep track of the fish with precision and the secret sub-surface lobster buoy markers as well with precision.

Hey, who the fuck do you think stocks your Sizzler and Red Lobster restaurants with the fish and lobsters that don't smell like fish and lobsters? Me. A little hint: if it smells like fish, it ain't fresh; same for lobsters. Only a fag wouldn't know either of the points i've placed. You fag trolls can keep your "Gay eye for the strait guy" tv show. It ain't worth a phillandering of davie's locker worth traulin' up after it sinks to the bottom! ARgggh!

Re:NEWSFLASH

[Anonymous Coward]

Any fucker stupid enough to make his life's work fishing obviously doesn't have the intellect required to use a computer beyond poasting messages on chat boards and using e-mail. You sir are a failure in everything you do including this poast and youre life. Get a fucking clue. No one eats fish and no one cares about you. But your too stupid is to understand that. Idiot fucker. Gay men have hundreds of times the style and fashion sense that a goat like you would'nt understand. You seem to forget, it's what women want that's important. I'll bet you never get laid at all. Even your captain butt pirate wouldn't want to touch your fish infested cavernous anal cave. Fucker. I'll clobber you to death if I ever meet you.

Re:NEWSFLASH

[Anonymous Coward]

I'll clobber you to death if I ever meet you.

Meet me at 12:00 AM:
Mother's Bay/Los Alamitos Bay Launch-Ramp
of Huntington Beach--California

Wear your contact lenses. I like the cracking noise they make as I grind them into the backs of skulls.

Zope is very close to Russian 'zhopa' which means

[melted]

Zope is very close to Russian 'zhopa' which means 'ass'. Just so you know.

Break the GIL!

[Second_Derivative]

Agh, look I love Python but the Global Interpreter Lock's got to go. Threading is severely crippled as long as it's still there... I mean, failing that can't we at least have independent interpreters?

Please? I've looked around for efforts to sort this out but the last of them seems to have died around 1997...

Re:Break the GIL!

[Whip-hero]

Agh, look I love Python but the Global Interpreter Lock's got to go. Threading is severely crippled as long as it's still there... I mean, failing that can't we at least have independent interpreters?

Please? I've looked around for efforts to sort this out but the last of them seems to have died around 1997...


Amen, Brother Derivative! I've actually played with the idea of just removing the GIL code myself to see what breaks (although I suspect quite a bit would). After all, you should use locks to regulate access to variables anyway. It would be dangerous because it would open up the possiblity of a bug crashing the interpreter instead of just the application, but I'd at least like a run-time option to disable it.

And independent interpreters would would make my life a whole lot easier when it comes to embedding Python as a macro language (to which Python is supposed to lend itself easily). It would also allow me to use teminable threads...

I think Perl suffers from these same minor deficiencies. I suspect that's due to the inevitable switch to the Parrot interpreter.

Re:Break the GIL!

[Second_Derivative]

Perl as of 5.8.0 has a stable and complete threading system. Well... almost. Perl doesn't have a global lock but you can't share objects across threads (you can share the underlying hash/whatever, but the blessing on the reference is lost)

Then again I hate Perl. @_ and $_ ??? gimme a break, those have got to be the ugliest variable names I've ever seen and they're a core part of the language. Yep, great language that Perl: parameter pass by reference? pass by value? Nope, pass by bog roll!

Re:Break the GIL!

[scosol]

Amen indeed-

Until that happens, threading provides nothing.

My personal opinion is that if you're using threading you *will* be taking care of the associated protection and locking. There's no reason the interpreter itself can't use this as well.
(The concept I mean)

Re:Break the GIL!

[nas]

fork() works fine (assuming your using a real OS). ;-)

Re:Break the GIL!

[alangmead]

He seems to have little sympathy on the matter, and you probably won't get more out of him than a politely worded patches welcome .

Re:Guido, a geek with a girlfriend...

[Dr. Smeegee]

That's his girl, friend. :-)

Correct

[Anonymous Coward]

Yup.

This a win-win situation for Zope and Python

[Ursus Maximus]

As an active Pythonic, and a most interested observer over the last two and a half years, it seesm to me that Guido leaving Zope should not raise any fears whatsoever about the future of Zope. I will explain below. Secondly, Guido's joining the new company is a positive for Python, which I will also explain. When Guido joined Zope a while back, I was very happy because it was good for Python, as it gave Guido a safe and comfortable corporate home and presumably a good living, while still allowing him to devote a lot of time to Python. I viewed it as a great goodwill move by Zope because they would be helping to support the future development of Python at their own expense. While Guido no doubt contributed a lot to Zope's efforts, Zope was a breakthrough and great product long before Guido joined Zope, Zope development team is extensive and capable, and Guido was till devoting a lot of time anyway to Python. Therefore Guido leaving is not a bad thing for Zope. Guido joining Elemental Security is great for Python, because that company will base an important new product on Python, and because it still gives Guido a secure corporate position and salary, and because he may be allowed even more time to develop Python at the expense of a good corporate citizen. This is a win-win situation. I say thanks to Zope, to Elemental Security, and to Guido and team. Ursus Maximus aka Ron Stephens

Odds?

[/dev/trash]

Any bets on when the startup will go belly up and he's back doing full time Zope and Python work?

Re:Odds?

[Anonymous Coward]

Any bets on when the startup will go belly up and he's back doing full time Zope and Python work?

Transmeta will buy Elemental, and Guido will join Linus at OSDL.

Bzzt. Not entirely in python...

[Anonymous Coward]

Some time-critical bits of Zope are implemented in C.

I found 56 C files in my (fairly recent) zope source tree, doing things like BTrees, XML, caching, and searching/splitting.

Still, zope is awsome. It has a sigmoidal learning curve: Easy at first, than hard and frustrating, then the light dawns and you see how it all should work.

There is so much built into Zope: you don't realize how good it is until you need those bits, like the permissioning system.

We run our bug tracking on zope. Rock stable, runs forever, and easy to extend.

-- ac at work

Wrong "secure"... Don't Panic.

[blunte]

I believe the word "secure" meant "well established, healthy".

But hey, you got an opportunity to strut, and show some linkage!

Re:troller alert

[WeeLad]

Yeah, Even I made her list. She was my first Freak. Good times....

Re:Surpassing Perl? No, surpassed Perl. Note tense

[Anonymous Coward]

Happened long ago. Spend a week or three with it and you will agree.

More readable?

[scosol]

We've all heard these "more readable" comments-

But readability isn't the issue here- once you have your own style, your code becomes readily readable.
It's more that with Perl there are many many different ways to do the same thing. Python does not suffer form this.
So while absolute "readability" can't really be argued too much- the issue comes in to play when you have to look at *somebody else's* Perl code, and they do something differently than you do it yourself.

DC loses Another

[freeworld]

This is slightly OT, but as a DC-area resident, losing a person of this stature is just another sign that NoVA's glory days are drawing to a close. For the past two years it's been nothing but that old standby defense (with its new handle, "homeland security") doing the hiring (if you have the clearances), with Internet, eCommerce, and telcos doing their well-publicized death dance.

Couple this with 9/11, anthrax, the Beltway sniper, and a few uncharacteristic deadly tornados, and this place has turned into an incredibly uptight and unhappy place.

Not that California is quite what it was, either, but for a season there, DC was the "Silicon Swamp," and it was intoxicating.

The Zope Learning Curve

[jesterzog]

I was experimenting with Zope last year and again during the first half of this year. It's definitely a cool product, but what threw me for now at least was that the documentation is abysmal, at least online.

From what I've been able to tell, there are several editions of the Zope book -- the only up-to-date version of which (currently 2.6) is still work in progress. The rest of the documentation is a mish-mash of user-written howto's, some of which are excellent, some of which are dupes of others, many of which are out of date, and others of which are just badly written. Searching the database of these is hard, and it's very difficult to distinguish well written old ones that are still relevant from newer ones that aren't very useful.

My main problem with it though is that although it focuses hugely on the differences between zope development and regular web development without seriously dealing with implementation examples of common tasks. On and off it took me about a month to figure out how to make a simple form-based login system (similar to slashdot's) and tie it into Zope's user folder system. Co-incidentally The only zope-based website I could find that actually did this was zope.org itself.

I really like Zope and I've shown off how it works to people many times over. But I'll only seriously consider using it more once the documentation is more coherent. At the moment I think that's one of the main places where itfalls over.

Re:The Zope Learning Curve

[GeorgeH]

I read the Zope Bible which I recommend. I haven't looked at the other Zope books, so I don't know how good it is in relation to the others, but it walked me through the basics and I figured the rest out on my own. A lot of time I needed to look at the source code to see how things were working, which speaks poorly for the documentation, but I got the job done.

Also, the way zope.org's login is overridden is default in CMF with the Cookie Crumbler product. I don't know if this is available outside of CMF but you can look at the source to see how they do it.

Re:The Zope Learning Curve

[jdfox]

We use Zope a lot where I work, so we have ALL the books. The Zope Bible (mentioned by GeorgeH above) is my favorite. However, most printed books make heavy use of the semi-deprecated DTML tags, rather than the more "strategic" ZPT tags, an approach which made sense back when they were written, but not now.

And there is still no introductory documentation on Zope CMF: not even on a web page, anywhere, no, not even on the Zope CMF site. They do have some nice outlines of what needs to be written, along with some vain pleas in the comments for it to actually get done sometime. When will it actually BE written? What is CMF? What do you use it for? What do all its components do, in a nutshell, and why and when should you use them? Zip. To understand that, you'll need to delve into the source and fsck around with it 'til it makes sense. Zope was intended to be a Web CMS for web developers, not for Python hackers. We're a little afraid for its future now, especially now that Guido is moving on.

Jesterzog is right: its doesn't matter how good Zope is, if mere mortals can't use it.

I'd really like to write some CMF documentation myself, now that I finally understand it. But I'm doing 2.5 jobs at the moment, and every day wears me out. Maybe when my team's current project finishes I can persuade my boss' boss to let me have a little time to do this, to protect our heavy time investment in Zope and CMF.

Re:bittorrent doesn't represent all of python

[Splork]

don't read just one popular program and assume that its a good representation of how to do things in the language.

Re:RACISM is alive and well in Open Source Communi

[Anonymous Coward]

http://www.opensource.org/docs/definition_plain.ph p

Official Gentoo Zealot

[subzerohen]

Gentoo's paackage manager Portage is written in Python.

Monolinguism and Polylinguaphobia

[SimHacker]

Your hard time with Python is caused by your own reading disability and your fear of learning a new language, not by any flaw in the Python language.

Indentation without brackets makes block nesting much more readable and obvious, than brackets without indentation.

Perl code is fundamentally unreadable, and readable Perl code is the extremely rare exception to the rule. Perl does nothing to encourage people to write good code -- just the opposite. But Python supports and encourages clean maintainable readable code.

Most vociferous Perl advocates are sadly monolinguistic (they aren't proficient with any other languages), or else they would realize how horrible Perl is in comparison, and how much time and effort they're needlessly wasting. Monolinguestic Perl programmers are usually quite polylinguaphobic (afraid of learning new languages like Python), because Perl was so hard to learn, and they assume out of ignorance that all languages are just as compex, messy and hard to learn and maintain as Perl.

Like the Senator from South Carolina argued against bilingual education: If English was good enough for Jesus, then it's good enough for the students of our state.

-Don

Re:Monolinguism and Polylinguaphobia

[scotch]

Perl code is fundamentally unreadable

This is the stupidest thing I've read all day. Take it outside, zealot. The rest of your post is either troll or ignorance.

Re:Monolinguism and Polylinguaphobia

[SimHacker]

Oh, come on, deep down you know I'm right, and you're just getting all huffy because you've invested so much time and effort in such a badly designed language. You've painted yourself into a corner, and now you don't want to admit that it was a bad idea.

There's a damn good reason that the widely held opinion of people who know both languages, is that Python is much easier to read and maintain than Perl. I've known Perl since 1989, and program extensively in Python. When did you learn Perl, and how much Python code have you written?

If you could be convinced that Python was easier to read than Perl, would you use it instead? I bet not, because Perl zeallots use Perl for all the wrong reasons, and they actually enjoy its flaws.

Can you explain your reasons for believing Perl is easier to learn and read than Python? It's simply not true, so such a belief must be based on an unspoken fallacy. Does it have something to do with your job security? Are you afraid that if your code is readable, you will be more easily replaced? That's the main reason Perl is so popular, but Perl programmers hate it when people point that out. They worship and revel in the arcane syntax, thinking it makes them more manly.

You may be very manly and irreplacable in your job because you use Perl, but there's no way you could possibly make the argument that Perl is easier to read than Python. Go ahead, try!

-Don

Re:Monolinguism and Polylinguaphobia

[sig cop]

You made a bullshit hyperbole statement: "Perl code is fundamentally unreadable". I called you on - it's not true. Things that are fundamentally unreadable can't be read. Lots of people can read perl. Hence, you come across as a zealot, one that will make any absurd claim to promote his agenda.

Now you're backing off your claim that perl is "fundamentally unreadable" in you rebuttal with this: " There's a damn good reason that the widely held opinion of people who know both languages, is that Python is much easier to read and maintain than Perl ". Wow, talk about moving the goal posts. This may be true, python might be easier to read on average and might be easier to maintain on average. This is pretty fucking meaningless, IMO, and I never claimed otherwise. You can't paint my position however you like, but I won't defend it. Here's what I think is important: the differences in fundamental readability and maintainability between python and perl (and other languages) is usually dwarfed by the difference you see from programming practices, individual code quality, and other artifacts of skill, policy and discipline. There's a reason people frequently say "you can write obfuscated code in any langauge" after all.

Here's the another thing I think is important. I use perl as a toolsmithing language. It's ideally suited for this task, IMO, and with care, maintainable tools can be written. Other people undertake more serious endeavors with perl - and with the right approach, I'm sure this is a manageable task. Personally, I prefer C++ or Java for more serious / longlived / formal endeavors. Why does it piss python evangelists off so much that there is no niche for python in some programmer's worlds?

So now about the rest of you unfounded assumptions and zealotry:

you're just getting all huffy because you've invested so much time and effort in such a badly designed language

What!!! You don't know this. I've used perl for years, but it's not my "main" language or anything.

You've painted yourself into a corner, and now you don't want to admit that it was a bad idea

Again, unfounded offensive bullshit assumptions on your part. Perl isn't my main language. I've used other scripting langauges, tcl, ruby, unix shell stuff, even played with python some. I'm in no way painted into a corner. If perl ceased to exists tomorrow I'd be ok. Methods, paradigms, and experience transcend language boundaries. I have no compelling reason to add YASL to my repretoire, and with no demostrated serious deficiencies with perl for my purposes, your hot air is a waste of time.

When did you learn Perl, and how much Python code have you written

I first touched perl in about 93. I've only played with python. Your point? There's more than perl and python in this world. And there are no perfect languages, your crusades notwithstanding.

If you could be convinced that Python was easier to read than Perl, would you use it instead? I bet not, because Perl zeallots use Perl for all the wrong reasons, and they actually enjoy its flaws.

This is a strange question. I can read perl fine. If I could convince you that esperanto was easier to read than english, would you use it instead? I bet no, because Engline zealots use English for all the wrong reasons, they actually enjoy its flaws. ROFL. The irony here is that you definitely are the zealot in this case - read the whole thread. And, on average, it seems like the python guys are the zealots. Sometimes it seems like the only reason python was created was to attack perl. Seriously, python has some nice stuff in it, but why some many zealous users? My use of perl and other languages doesn't diminish your utility of python, so get off your soapbox already.

Can you explain your reasons for believing Pe

Re:Guido, a geek with a girlfriend...

[Anonymous Coward]

Dude, that's Guido's son. He's married to an adult female American-type person.

Python supports the Californian programming style

[Anonymous Coward]

Python is the ultimate Californian programming language. You can write piles of Python code when you're stoned out of your mind, then totally forget all about it, and then come back months later and easily pick up where you left off, still stoned out of your mind.

Re:Python supports the Californian programming sty

[Anonymous Coward]

And the best part is, you're still twice as productive as any other state in the union. ta dum!

Ada??! Only good for wireless robots.

[SimHacker]

Ada??! Isn't that the Wireless Robot Programming Language designed by the U.S. Government, and promoted by IBM? Ada's main feature isn't just strong typing -- it's specifically designed for flipping out and killing people! After all, robots are mammals!!!

Ada's a much better programming language for destroying Microsoft than Java, because Ada has built-in support for cutting off heads all the time without even thinking about it, instead of silly promises about "write once run anywhere" and those totally homosexual inner classes!

-Don

People always confuse the many meanings of secure

[SimHacker]

The word "secure" is just as misunderstood and abused as the word "love". It has many different meanings in many different contexts. Programming in Java doesn't protect your children from terrorists.

Unless the security product allows untrusted users to enter and execute Python code, then there's no contradiction in using Python to develop a secure application. Security isn't something that springs from the programming language itself -- it depends on what you do with the language. Security is largely a social issue, which is why it was a good call to remove the "rexec" module for the reasons Guido stated.

The idea of adding "data tainting" to Python or any other language is a misguided attempt to force the programming language to guarentee a kind of security that you can only get by designing, implementing and debugging your program properly. No programming language can protect against lazyness or stupidity, and it's misguided to try to provide a false sense of security at the linguistic level.

-Don

Zope is great, but too complex and hard to learn.

[SimHacker]

I've developed a production web site in Python and Zope (http://www.Connected.TV), and I like Zope a lot, and absolutely love Python. But Zope is much more complicated than it needs to be, and not well documented at all. The Zope developers are certainly aware of those problems, and working to correct them. I don't agree with all the directions they're taking (like the messy dtml and crippled xml page templates that want to be a programming language but aren't quite -- didn't they already make that mistake with XSLT? Why repeat the mistakes of the past?), but since it's written in Python, you don't have to use the crazy stuff, and you can just drop down to Python and program the hell out of it to do whatever you want.

Zope's DTML is a pain in the ass, and the xml page templates are lame and bizarre. What I would really love, would be an elegent xml based and fully functional web templating and programming language like Water, implemented in open source Python, embedded in an interactive dynamic object publishing content management web server framework like Zope (but simpler).

If you're interested in language design, definitely read the white papers like the Water Rationale on the Water web site. They're to the point, brilliantly written, and hit the nail on the head.

-Don

[Interesting excerpts from http://www.waterlang.org/doc/water_rationale.htm]:

Water Rationale
Fry, May 2002
Overview

Water is a language for the web that embodies the three primary functionalities needed for general purpose information manipulation into one unified language:

- Code: Water is a general purpose object oriented programming language that is, at its core, more flexible than Javascript, Visual Basic and Java.

- Data: Water permits the description of persistent structured data on the web via an XML syntax yet having the capability of computing values that may contain self-referencial interconnections.

- Markup: Since Water is a superset of HTML, it inherits all of HTML's capabilities.

The syntax of Water is a superset of HTML, or, more properly, a superset of XML. HTML has proven to be an easily understandable markup language since it has been learned by millions of people in the several years that the web has existed. XML is a standard for putting structured data on the web. Water extends the syntax of XML to make a language less cumbersome to write code in. Water provides a way to define functions and call them in addition to defining and instantiating objects. The object system is a multiple-inheritance, prototype-based object system with annotations. This will be described below, but for now it's sufficient to say that it is more powerful yet simpler than the class-instance object systems currently in vogue in languages such as Java and C++.

[...]

We Need Another Language Like A Hole in the Head

Right now the plethora of languages on the web causes more than headaches. New ones seem to be born monthly. Having to learn two or more to get a task done is more than twice as hard as one language because the interface between the languages is always additional hair which is, more often than not, poorly documented.

Why do we have HTML, XML, Java, Javascript, C++, Visual Basic, VRML, XSLT, PHP, etc? Because none of them are flexible enough to give programmers the functionality they need in building a modern Web application. Looking within the scope of what each of the above intends to cover, we often find serious flaws. But when we try to move outside of that scope, say doing markup in Java, we have a full-fledged disaster on our hands.

We do not need a new language for implementing some specialized functionality. Sooner or later that specialized functionality will need general purpose utilities like condi

Re:Zope is great, but too complex and hard to lear

[alext]

Very interesting, thanks!

I had a feeling that such an effort - making XML a complete general purpose language - must be out there (as opposed to the myriad of things like SAML which are actually complete but specialized).

I would have started with Scheme - not obvious why Self was chosen but it looks alright. Does it have macros though?!

Re:Zope is great, but too complex and hard to lear

[alext]

Uh, unfortunately I'm obliged to retract my endorsement - it's not XML at all!

In fact, Water is pretty eccentric all over.

I'm afraid it's back to Scheme and SXML for me...

Water and ConciseXML

[SimHacker]

Water certainly is XML, but it supports an additional syntax: ConciseXML.

Water uses an extended XML syntax called "Concise XML", that's compatible but more general and concise than XML. Here's the description of Concise XML from the Water web site. They discuss some interesting observations and the rationale behind Concise XML in the "The Trouble with XML article. And here is a chapter of the Water book describing ConciseXML.

What is ConciseXML?

ConciseXML(TM) is a language-independent markup syntax compatible with XML 1.0, but designed to handle every type of data including non-hierarchial data, program logic, document markup, and binary data. ConciseXML is both concise and precise, eliminating two major limitations of XML and extending the use of XML.

Features of ConciseXML

Conciseness

Many people avoid XML in many circumstances because of its verbosity. ConciseXML is as concise at representing logic as the "semi-colon" syntax of C/C++/Java/C#. ConciseXML can also be as concise as the Comma Separated Value (CSV) syntax for data.

Precision

ConciseXML has no ambiguity of meaning. There is only one way to represent parts/fields of an object. This stands in contrast to XML where there can be many syntactic forms for the identical meaning or semantics.

XML Compatibility

Is ConciseXML compatible with XML?

ConciseXML maintains both forward-compatibility as well as backward-compatibility with XML. Any XML document is also a valid ConciseXML document. Any ConciseXML document can be represented in XML without any loss of information. For each ConciseXML extension to XML, there is a corresponding form in XML. A ConciseXML expression or document can mix and match ConciseXML and XML syntax at all levels.

ConciseXML Extends XML

ConciseXML makes XML more flexible by eliminating many of the constraints of XML. Here are some examples.

Attribute values can be any expression

Example: <input size=3/> or <person birth=<date 2002 10 2/>/>

XML requires that all attributes values are quoted. That effectively requires that all values are of type string. Elements are often used to work around this limitation, but that presents another set of problems. Attribute keys can be non-strings

Example: <thing 0="foo" 1="bar"/>

XML does not let an attribute key start with a digit. That effectively prevents integers from being attribute keys. ConciseXML makes it possible to easily represent array-like fields with integer keys.

Tagname of an element can be any expression

Example: <foo.bar/>

XML Namespaces are a step in this direction, but ConciseXML makes it possible to have any expression as the tagname of an element.

Attribute keys are optional

Example: <date 2002 month=10 day=28/>

In the CSV (Comma Separated Value) syntax and in all major programming languages, field or argument values are given by position, not by keyword.

Closing tagname is optional

Not only does this remove unnecessary clutter, but when ConciseXML is used as the syntax for dynamic languages, the tagname may not be known until runtime, and therefore the closing tagname must be optional.

[...]

projects being done in Python

[aleax]

Mitch Kapor's OSAF (Open Source Applications
Foundation) is using Python for "Chandler", their
"lotus-agenda-plus-outlook-plus-tons-of-stu ff"
megaprogram.