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.

His goodbye posting

[VladDrac]

You can read his goodbye posting to the zope3 list here [zope.org]

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.

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

Re:Prominently on python.org

[Randolpho]

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

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. ;)

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 we

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.

[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.

[dagarath]

The obvious reference to Python Web Site [python.org] 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.

[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 [asbahr.com]
  
• Freedom Force [pyzine.com]
  
• Humongous's "Backyard Sports" series [onlamp.com]
  
• Disney's ToonTown [toontowncentral.com]
  

Re:Good times.

[Merk]

Well, maybe, until you use Ruby [ruby-lang.org]. 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 [rubygarden.org] 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 w

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

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.

[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 [pythonology.org], Python Users [python.org], and Python Projects [python.org])).

Remarkable language, Python. Lovely plumage!

-Billy

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.

[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 [zope.org] - IMHO the best ever written application server, thanks to laziness and OOP of Python;
• Plone [plone.org] - 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 [gentoo.org] - the best ever written package management system; I doubt ebuilds and eclasses would be that flexible and power without Python;

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 sam

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

Re:Good times.

[Andy Dodd]

EVE Online [eve-online.com] uses a modified version of Python called Stackless Python.

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.

[listen]

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

Re:Good times.

[Ikari Gendo]

Guido seems to disagree. [artima.com]

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 [python.org] 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.

[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.

[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.

[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.

[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.

[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 str

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.

[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.

[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...

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 read

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.

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 perspective

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 [python.org] in place for block delimiters. Mind you, it's rather ugly, so I don't use it.

Re:I don't think so...

[Erich]

From the FAQ:

4.15. Is it possible to write obfuscated one-liners in Python? [python.org]

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 [ioccc.org] I've seen [ioccc.org].

Try that in Python!

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.

[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! ;+)

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 ho

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.
/ /_\\/

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: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: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.

[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 we

Guido's goodbye message

[pen]

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

Guido van Rossum [e-mail]
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. [e-mail] no longer works. Please use [e-mail]!

Re:Guido's goodbye message

[jo42]

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

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.

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: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 [bash.cx]

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

"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. [cnn.com]

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.

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.

Who names this stuff?

[Laur]

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

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 )

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.

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.

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

[rthille]

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

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 [python.org]

and Guido's reply:

posting 2 [python.org]

A little bit further down that thread we find this:

posting 3 [python.org]

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.

[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.

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:Quite secure, eh? Not according to Guido.

[Zebbers]

he meant secure as in the development of python will continue

nice rant though!

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.

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 so

Least ugly?

[Dr. Smeegee]

Looking at Guido's Home Page [python.org] 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?

[Pxtl]

Seconded.

Re:Least ugly?

[Dr. Smeegee]

Well, if Hedy Lamarr [harvard.edu] 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 [zope.org] and the Zope corporation [zope.com]. There are at least two kick ass, open source content management systems built on top of Zope Corp's content management framework [zope.org] that I know of: Plone [plone.org] and Silva [infrae.nl]. There are a ton of add-on products [zope.org] 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 [usefulinc.com] and DevShed (which runs on Zope) has a good overview [devshed.com].

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

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 [zope.org] of which (currently 2.6) is still work in progress. The rest of the documentation [zope.org] 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 [zopebible.com] 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

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 [zope.org]. They do have some nice outlines of what needs to be written [zope.org], along wi

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 [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

Re:A shame

[axxackall]

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

Emmental security?

[imAlive]

emmental [astradyne.co.uk] is a swiss cheese known for it's big holes.

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 de

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: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?

[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,

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?

[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 Pyth

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(

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

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 adequ

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 h

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

[Dr. Smeegee]

That's his girl, friend. :-)

Re:Break the GIL!

[alangmead]

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