FSF Awards Guido van Rossum For Python

bkuhn writes: "The FSF today bestowed its fourth annual Award for the Advancement of Free Software upon Guido van Rossum . The two other finalists were L. Peter Deutsch and Andrew Tridgell." Developing Python seems like a good reason :)

Comments

Great

[__past__]

This is really nice, especially after all this fuss about the Python license not being GPL-compatible.

I really like Python, and the style Guido and the other core hackers manage it. Best example are the PEPs (Python Enhancement Proposals), a very open and community-oriented way to deal with language evolution.

And that in turn...

[Anonymous Coward]

makes it possible for me as a probably far less advanced programmer to be able to *read* your code :-)

Python deserves all credit it gets really, mostly because it's really really simple. They should ditch tk as default windowing/widget environment though and switch to wx but other than that I love it.

And it is NOT true that any stuff one can do on 2 lines in perl would take 6 in python. Not at all.

for some perspective on lightweight languages

[markj02]

I recommend reading this article on DDJ on the lightweight languages workshop at MIT. It talks about Python and similar languages, and their role in the world. Note that both the LL1 workshop and the FSF are at MIT.

congrats, Guido

[Anonymous Coward]

Although I've never programmed in Python, I've read the O'Reilly book and really respect what you've done to advance computer languages.

You got a lot of balls forcing people to indent their code in a standard way!

Python Topic!

[Anonymous Coward]

I realize slashdot is perl-centric, but this is getting ridiculous!

It's time for a python topic!

I realize a topic for every language out there is impractical, but there have been a TON of python related postings!

Things I love about Python..

[thesupraman]

- A clean, SIMPLE, powerfull core language
- Data types that make life easy (lists/dictionaries)
- A FANTASTIC set of cross-platform libraries
- A GREAT standard and simple GUI library (Tk)
- A GREAT powerful GUI library (WX)

Things I would love about python :)
- A compiler (very hard, but I can dream)
- Smaller/more tunable installs
- wxWindows built in

Python is the 'simple c++' I was always looking for and have now found ;), 90% of the functionality with 1% of the complexity, and great cross-platform support to boot!

As a developer, I just love it. Python reduces my development time significantly, and also allows me to express algorithms in a logic way, without fighting the language. This is a VERY important feature. It lowers development stress, so I can spend more time working and less time reading language manuals.

Re:Things I love about Python..

[fperez]

Things I would love about python :)

- A compiler (very hard, but I can dream)

Keep an eye on the weave project here. Currently it allows you to inline C/C++, and work is under way to have automatic acceleration of arbitrary python code via compilation to C/C++. It's *really* cool.

Re:Yes, but...

[Kirruth]

I love both Python and Perl, but they occupy different parts of my brain-space. Python is very much a well-thought out, systematic kind of language whereas Perl is more of a code party.

With Perl it's either, "My God, Larry, you are a genius" or "What exactly were you smoking, buddy" (more usually the former), whereas Python's strength lies in having a very solid core language sitting squarely across the areas people use for general purpose programming. If its text I use Perl, if its objects I use Python.

Using either of them, I am just amazed at how great they are, and definitely cheer on Guido for his award.

Python complaints

[Tablizer]

(* Python is perfect for large programs, because it is object oriented *)

How *exactly* does OO help large programs? I keep hearing this cliche, but it is never demonstrated, besides comparing it to bad procedural design. The 1st Orielly Python book gave a lame, rigged menu example to justify OO.

Although I much prefer Python over Java, there are some annoying things about it IMO. First of all, it has too many collection "types". These should be rolled into one protocol so that one can scale clear up to RDBMS's without changing access syntax. (Perhaps the engine will be switched, but the access syntax should not have to be.) OOer's don't "get" scaling collection protocols IMO, stuck in the artificial make-a-taxonomy-of-collections-because-
Smalltalk-did-that mindset.

Further, it is too easy to mix up tabs and spaces in scripts. Scripting should *not* assume a controlled editor environment. When you can mix up tabs and spaces, then WYSIWYG indentation goes out the door. The compiler cannot know how tabs *appear* to you. Think about it.

Re:Python complaints

[Anonymous Coward]

I wrote "Python is perfect for large programs, because it is object oriented, modular, easy to read, especially easy to maintain, and powerful."

From which you quoted only the first part
(* Python is perfect for large programs, because it is object oriented *) and attacked it.

Well, it is the combination of qualties and characteristics that make a programming langauge good at large programs, not just any one part. I actually agree with you 100% that merely being object oriented does not guarantee that a language will be good at large projects. In fact, extreme purity that puts all emphasis on object orientation or any other one kind of programming leads to very poor languages, in my opinion.

Indeed, one can program in Python in a purely procedural way, or even a functional way, without ever even using classes or object orientation at all! Newcomers to programming often start out this way in Python and do just fine, creating wonderfully useful programs without classes or any notion of object orientation entering their brains, until they are ready for it. This helps to make Python a perfect first language for new programmers, and yet Python eventually leads them to a clear understanding of even the most advanced programming concepts, in a painless, enjoyable, and useful process.

Python is very practical, pragmatic, and takes a middle course. This middle way, the Python way, just happens to be a great way to program. And Guido's leadership of the development process is a shining example of open source development that really works well. Python is continuing to evolve into a better and better language all the time.

The evolution of the Python langauge is a great Work of Art in and of itself.

learn Python

Re:Python complaints

[Tablizer]

(* Inheritence allows you to take an object and modify it, using existing behaviour with little effort. *)

Often the differences are not on method boundaries. IOW, the change granularity often does not match the method granularity in reality. Plus, you end up with the "fragile parent problem" in that changes to the parent may break many children. Thus, nobody wants to clean up the creeping inheritance vine.

Many seasoned OO proponents suggest using inheritance sparingly. They agree that inheritance is way oversold in the "Learn X in 21 Days" kind of books. (However, their alternatives are often even messier IMO.)

I don't quite follow your example. Maybe after some sleep I will have more patience with it. I don't use C, especially in a big project setting, so I guess I cannot relate to managing header files. I tend to use relational tables. If I need a Path column or BaseDir column, I simply add a path column. Code that uses other columns usually does not need any changing. (Note that not all relational systems are as bulky as most SQL API's.) I also find it easy to study the table data in a table browser and table structure without writing RAM dumps. The structure and data usually exist outside of the program, so I can inspect, study, grok, and filter it any way and time I want.

(* species_dict = bsddb3.rnopen( "/tmp/db_file" )
No other code in my program had to be changed. This is a lot faster data store than any RDBMS that I've used *)

Well, but dictionaries only have *one* index. That is an arbitrary limit. It is like, "I declare a new collection taxonomy type called the Zork. It has 3 indexes and 13 columns." Listen, everybody likes different things. For me, having every collection able to potentially have full relational capabilities is a good thing. I hate rewriting code just because my collections grow up. I can also sort, view, and filter the data into tables any way I want without writing RAM dumps.

The judges simply think kinda like Guido. My own pet language would be different. Collection "types" are a pet peeve of mine.

(* From my python experience there are only two collection types in python. They are: list and dictionary. *)

I thought it had 3. Anyhow, even 2 is too many. I don't think there should be *any* sharp syntactical boundary between the smallest and largest collection. I see no excuse for such, other than historical habit. Smalltalkers have repeatedly failed to objectively justify it. I doubt Python fans can pull it off also. It will eventually come down to, "you just get used to arbitrary boundaries and then they won't bother you so much. You take the boundary penalty in stride, like New Jersey weather."

(* Python doesn't beat the "how many spaces is one tab" thing. However, errors are as easy to spot as missing semi colons. *)

I am not a semi-colon fan either. However, block-ender syntax and line separator syntax are two different issues anyhow. You are intermixing two independent syntax issues it appears.

(* However python code is made a lot easier to code once you have an editor set up for it( and there are many ). *)

But that is *counter* to the very idea of a scripting language IMO. I *have* had tab problems in other languages because one editor or one computer was set up different than a prior editor. Requiring a strict editor setup is a feature that I would expect from one of those stuffy languages, not a programmer-friendly one.

BTW, another Python fault is not consolidating dictionaries and classes. A class is simply a dictionary of methods and attributes with an inheritance option thrown in. Other scripting languages have successfully consolidated these two concepts. Python blew the opportunity IMO. (Dictionaries are great as interface mechanisms, such as passing and storing dynamic parameters. However, as a data container, they suck IMO because they don't scale in complexity, as already described.)

Thanks for your feedback.