Python 2.3 Final Released

An anonymous reader writes "Nineteen months in the making, Python 2.3 has just been released. With a plethora of changes since version 2.2, this release is definately worth the upgrade. Be sure to read the Release Notes and the Highlights file for more information."

Comments

impact...

[alienhazard]

I wonder what this means to the people at blender who just updated the python API

Re:impact...

[Lupulack]

I doubt this has any affect there at all. The language has changed , but that only changes the way that one accesses the Blender API. It's not like it breaks everything ...

Re:impact...

[sketerpot]

Pthon 2.3 was designed with backward compatibility in mind. All your old programs should work with 2.3 if they work with 2.2.2, and you'll get some speed improvement. Of course, if you use 2.3-specific modules like logging (based on log4j) and sets (set operations, using dictionaries internally), those won't be compatible with 2.2.2 unless you copy the files from the standard library, which should work.

In short: don't worry about it. The python developers already have.

Re:No takers for "subscription"? [Somewhat OT]

[winkydink]

Subcribers can't reply any sooner than non-subscribers

Re:No takers for "subscription"? [Somewhat OT]

[Ack_OZ]

from what I understand, comments can't be posted until it goes live to the general public

Countdown to Gentoo zealotry.

[Anonymous Coward]

In 3... 2... 1...

Python 3

[Alan Holman]

Wow, finally Python 3! Are they as good as the original Monty Python? I didn't see the second Monty Python...Err... Is John Cleese still in Python?

Whitespace trolling...

[Omicron32]

I'm just waiting
for the trolls to start
complaing about
whitespace usage in
Python.

That, and what does this mean for improvments to my favourite distro's package management? (Gentoo!)

Re:Whitespace trolling...

[mackstann]

I honestly doubt it's gonna have any noticeable effect on portage. Or maybe it will. Python 2.3 now has a great logging package built in :)

Re:Whitespace trolling...

[mackstann]

Wait a second... that gentoo comment was a JOKE! HAHA! I GET IT!!

Re:Whitespace trolling...

[axxackall]

trolls=[post for post in posts if post.complains(whitespace)]

USE="brains" emerge joke

Re:Whitespace trolling...

[Dausha]

Don't you mean?

def waiting (trolls) :

for troll in trolls :

complain(troll, whitespace_usage)

Re:Whitespace trolling...

[XNormal]

Python:
Programming the way
Guido
indented it.

Re:Whitespace trolling...

[peterpi]

*bite*

You've got to admit, it's a fucking stupid thing for a language to do. What's wrong with { and }?

Re:Whitespace trolling...

[BigJimSlade]

What's wrong with { and }?

What's wrong with it is that it's the syntax for dictionaries. Similar to hashes in Perl, it is a built-in type for Python. Anything wrapped in {} would probably be viewed as an attempt to make a dictionary by the parser.

I've discussed this with all my software engineering colleagues, and most of them have white space as their only hang up about the language. I thought this was pretty petty at first, given the other strengths of the language, but one person brought up an extremely good point. A co-worker at his company is blind. He said that having to deal with white space while coding was near impossible (maybe he uses a "pretty printer" or code beautifier after the fact? I don't know) Has anybody on /. had experience with a blind user of Python? How did they work around this issue (if at all?)

I do think it would be nice if there was a way to open and close a block (someone later down in the comments suggested preprocessor comments of

#begin

and

#end

) such that one could use either method. Perhaps there would even be a built in function of the interpreter to spit out the code one way or the other.

I must say I've gotten used to the whitespace over the past year. Using a decent editor makes life much easier in this respect. I would encourage anyone who hasn't tried out Python for this reason alone to give it a shot for a few weeks and see what you think.

Re:Whitespace trolling...

[Fweeky]

Ruby uses { } for hashes (h = {'foo' => 'bar', :wibble => :wobble}) and blocks (h.each {|k,v| puts "#{k} => #{v}" }), although do..end is more common, and general stuff like methods and classes use def..end, class..end etc.

In general I find Ruby's way easier to read than Python's, especially in the case of weenies who haven't yet learnt to indent properly and have tabs/spaces randomly mixed in with their indents (a practice that seems so common as to outnumber the more traditional spaces OR tabs methods many times over).

It doesn't bother me that much though.. I just find Python less natural than Ruby. I think I'm spoiled by it ;)

Re:Whitespace trolling...

[ProfKyne]

In general I find Ruby's way easier to read than Python's, especially in the case of weenies who haven't yet learnt to indent properly and have tabs/spaces randomly mixed in with their indents (a practice that seems so common as to outnumber the more traditional spaces OR tabs methods many times over).

Interesting... seeing as how Python doesn't let weenies indent improperly, and you can run Python scripts with a flag (-O) that gives warnings if tabs and spaces are intermixed in the whitespace... you would think that Python's way would be easier.

Re:Whitespace trolling...

[sketerpot]

As for the blind person comment: I would think that a decent editor for blind people would be able to annotate the language to make it easier for blind people to deal with. If you've got an editor that reads the screen aloud, it could say "open/close block", or you could have it automatically insert #begin and #end in braille.

Re:Whitespace trolling...

[shizowell]

Since Python's use of whitespace is intended to increase the language's visual appeal, you might not find it surprising that it sacrifices usability for non-visual people such as your friend's blind colleague. I don't buy it, though. I think the problem with Python for blind people isn't the language itself; it's the lack of good tools for reading Python code to the blind.

Try reading this code over the phone to somebody:

for name in ('fred', 'george'):
for greeting in ('hello', 'goodbye'):
print greeting, name
greeted[name] = 1
print 'all done'

Use vocabulary like "indent once" or "dedent twice" and it's not too painful. If you, the human, can infer the indent/dedent levels, couldn't a tool for blind folks do the same thing?

I am one of countless people who avoided Python at first--due to being comfortable enough with Perl and distrustful of whitespace--but who then gave Python an honest try and loved it.

Re:Why Python is good at our university

[Kumkwat]

"f proper establish language like C , C++ , Perl, etc and other must be modern experimental choice like Python , Java , etc"

I assume including "Java" as an "experimental" language was a typo?

DDoS

[TheIzzy]

Seems the new release suffers from a certain DDoS bug.

Reviewing a book 101

[Anonymous Coward]

What did it help you do? Work on your reading skills? Start your camp fire? Reach the top shelf?

How did it help you? Did you really need help? If so was this book uniquely helpful or do you think others would have helped too?

Are there other reasons why it was great? Was the author witty and entertaining? Or was he dry and to the point? Was his writing unusually clear and illuminating? Did he "speak to you"?

I'm not saying every comment here has to be a full book review, just that yours was devoid of any helpful content.

Re:Reviewing a book 101

[Sir Haxalot]

Ask any Python aficionado and you'll hear that Python programmers have it all: an elegant language that offers object-oriented programming support, a readable, maintainable syntax, integration with C components, and an enormous collection of precoded standard library and extension modules. Moreover, Python is easy to learn but powerful enough to take on the most ambitious programming challenges. But what Python programmers have lacked is one concise and clear reference resource, with the appropriate measure of guidance in how best to use Python's great power. Now Python in a Nutshell fills this need.

In the tradition of O'Reilly's "In a Nutshell" series, this book offers Python programmers one place to look when they need help remembering or deciphering the syntax of this open source language and its many modules. This comprehensive reference guide makes it easy to look up all the most frequently needed information--not just about the Python language itself, but also the most frequently used parts of the standard library and the most important third-party extensions.

Python in a Nutshell focuses on Python 2.2 (and all its point releases), currently the most stable and widespread Python release. This book includes:

A fast-paced tutorial on the syntax of the Python language itself

An explanation of object-oriented programming in Python, covering both the classic and new-style object models

Coverage of other core topics, including exceptions, modules, strings, and regular expressions

A quick reference for Python's built-in types and functions, as well as the key modules in the Python standard library, including sys, os, time, thread, math, and socket, among many others

Reference material on important third-party extensions, such as Numeric and Tkinter

Information about extending Python and embedding it into other applications

Python in a Nutshell provides a solid, no-nonsense quick reference to information that programmers rely on the most. This latest addition to the best-selling "In a Nutshell" series will immediately earn its place in any Python programmer's library.

Synopsis
In the tradition of O'Reilly's "In a Nutshell" series, this book offers Python programmers help remembering or deciphering the syntax of this open source language and its many modules. This comprehensive reference guide should make it easy to look up all the most frequently needed information - not just about the Python language itself, but also the most frequently used parts of the standard library and the most important third-party extensions. The book includes: a fast-paced tutorial on the syntax of the Python language itself; an explanation of object-oriented programming in Python, covering both the classic and new-style object models; coverage of other core topics, including exceptions, modules, strings, and regular expressions; a quick reference for Python's built-in types and functions, as well as the key modules in the Python standard library, including sys, os, time, thread, math, and socket, among many others; reference material on important third-party extensions, such as Numeric and Tkinter; and information about extending Python and embedding it into other applications.

Happy? :)

Re:Reviewing a book 101

[FattMattP]

Yes. http://www.oreilly.com/catalog/lpython/

Re:Reviewing a book 101

[teslatug]

Damn, I just bought this book on the 15th. Time to find that receipt. I wonder how long it will take them to realease the 2.3 edition.

Re:Reviewing a book 101

[nagora]

an elegant language that offers object-oriented programming support,

If you want OO, use Smalltalk. OO "support" is a wate of time: look at C++ or Perl; the result is half-arsed programs that lapse back into non-OO anytime the programmer hits a tricky bit and decides to just copy the code out of some C book somewhere.

Either use OO all the way through your program or not at all, the same goes double for your programming language.

TWW

Re:Reviewing a book 101

[William Tanksley]

Smalltalk is a beautiful environment and a simple and elegant language (although the reverse is not true). But it's not the last word. Python does an excellent job at object orientation, and the fact that it doesn't enforce it doesn't cause any more bad code than the fact that Smalltalk doesn't enforce the Law of Demeter causes bad code.

-Billy

Re:Reviewing a book 101

[nagora]

and the fact that it doesn't enforce it doesn't cause any more bad code than the fact that Smalltalk doesn't enforce the Law of Demeter causes bad code.

Idealistic. In the real world with real people working to real deadlines, it does.

Another example of this sort of thing is found in modern Forth systems which allow flat files for source code. There's no reason not to continue write small, well tested, tight code with 2 to 15 lines of code per routine but most people don't and as a result their code sucks. But it's easier to write (but not to debug or understand) and that's why they do it.

Human nature beats idealism every time.

TWW

Re:Reviewing a book 101

[William Tanksley]

I normally write Forth using files, and try to constrain my definitions to one line. (I bet you didn't expect THAT response; I sure didn't expect to see a Forth example used here!) But that's not relevant :-), I know what you mean.

OO is easy to write if your design calls for it. It's not "natural" to slip out of OO within a design; but the mistakes that are natural within OO aren't prevented by Smalltalk any more than they are within Python. Violating the Law of Demeter is just one example.

The difference is that in Python, you can start out doing something completely non-OO if you want. And you know, sometimes that's appropriate.

-Billy

Re:Reviewing a book 101

[nagora]

I normally write Forth using files, and try to constrain my definitions to one line. (I bet you didn't expect THAT response;

You're right! (although the low user id should have been a warning). Personally I aim for two lines but anyway,

The difference is that in Python, you can start out doing something completely non-OO if you want. And you know, sometimes that's appropriate.

I write a lot of Perl and I always do it non-OO. I've tried various OO-languages and I do think that, especially when starting out, the more constraints that force you to use objects the better. Although that might be a result of having been brought up on non-OO languages (and being a keen assembler).

TWW

Re:I see whitespace is still syntactically relevan

[Anonymous Coward]

There's a feature I'd like to see removed.

Why ? What would the benefit be, beside breaking all existing python code ?

Re:If anyone wants a good python book...

[Sir Haxalot]

Heh... another useful book just sprang to mind, try Learning Python. There isn't really much between the two books... although a see Amazon offer a discount, wheras with the other one you don't get a discount... anyways your choice :)

question to practical programmers

[Maimun]

At the top of the list of new features they have sets. The first paragraph says that sets are implemented by hashtables. I wonder whether it is really meaningless from the "practical" point of view to implement sets with data structures like red-black trees or Fibonacci heaps. The advantage of the latter over hashtables is a solid bound on the worst case running times.

Re:question to practical programmers

[SilentStrike]

Essentially, hash tables are preferred over balanced trees because they are usually faster in practice.

Python developer showing preference to hash tables over balanced tres.

I would also like to see balanced trees in the library, if for nothing more than sometimes ordered iteration is more useful than fast lookup, but oh well. I believe having hash tables but not balanced trees is much less bad than the other way around (like standard C++), in which there are balanced trees but no hash tables.

Re:question to practical programmers

[elflord]

The advantage of the latter over hashtables is a solid bound on the worst case running times.

Another key advantage, is that RB trees are automatically sorted.

I'd suppose they use hashtables because they're interested in good average case performance, especially for large tables. I doubt they'd care about worst-case performance -- I suspect that most time-critical code is not written in python.

Re:question to practical programmers

[jcr]

I suspect that most time-critical code is not written in python.

Depends on which time is critical: CPU time, or programmer time?

-jcr

Re:question to practical programmers

[elflord]

I wasn't trying to dis python, but the point is that most python programmers (even the ones who are interested in performance) are probably thinking "I want this to be as fast as possible on average", not "someone (possibly the programmer) will die if this code does not run in 0.05ms. In one case, you're interested in average case performance, in the other you're interested in worst-case.

For most web applications, you only care about average case, but for embedded systems, medical equipment, air traffic control systems, etc, worst case may also be very important.

Re:question to practical programmers

[smallpaul]

I'd suppose they use hashtables because they're interested in good average case performance, especially for large tables. I doubt they'd care about worst-case performance -- I suspect that most time-critical code is not written in python.

If the code is not time-critical then why optimize for average case performance?

Re:question to practical programmers

[miu]

Another key advantage, is that RB trees are automatically sorted.

Most stl map implementations are based on a RB tree, and often cause memory fragmentation. That's not the end of world for most programs, but data being located on many different pages can trash average access times for threaded programs (although constant use of the memory allocator probably harms the program itself more).

A hash gives good memory locality and good average lookup performance, if data is constant (or near constant) a sorted vector gives you excellent lookup performance and very good memory locality.

But I don't think flat out optimization is that important to python, otherwise they'd use low level hacks like perl reading directly out of the stdio FILE buffers to optimize IO.

Re:question to practical programmers

[elflord]

You're wrong. The real reason is that for most data sets the Python hash implementation outperforms a balanced tree solution.

Yes -- that's what I said. It outperforms the balanced tree in the average case (but not the worst case) This almost certainly outweighs the benefits of a guarantee for most python programmers. The main advantage (as I also pointed out) of a balanced tree approach is that the data is automatically sorted.

Re:question to practical programmers

[elflord]

If the code is not time-critical then why optimize for average case performance?

I meant, time critical as in "must run in less than 0.05ms".

A lot of python code may need to run as fast as possible, but python coders are more likely to be interested in average case (for example, you are really interested in average case with a web application, text processing program, or most scientific computing applications, not worst-case)

Re:question to practical programmers

[scj]

I believe the reason is that sets in Python are implemented in the Python language itself. Since Python already has hash tables implemented in C, it was easy to write a good set class by using a hashtable. To get the same level of performance with another data structure would mean writing and maintaining a bunch of C code.

The Python developers could always rewrite the set class in C using Fibonacci heaps at some later time. By writing it in Python, they get a reasonably good implementation now where people can use and experiment with it and suggest improvements to them before commiting to a harder to maintain C version.

Re:question to practical programmers

[Ed Avis]

After the recently-implemented algorithmic complexity attack against many hash table implementations (story on Slashdot a couple of months ago), many more programmers have reason to be concerned about the worst case. If you are hashing inputs taken directly (or perhaps even indirectly) from the user, then by choosing the right strings an attacker can DoS your system by making lots of hash collisions, so each lookup becomes effectively a linear search.

I don't know what Python (or other scripting languages) are doing to address this; many on the Python newsgroup seemed not to care and said that the operating system should deal with any process which is using too much CPU time, but I don't know if this attitude is shared by the real Python developers.

Perhaps for security-conscious applications you could choose to use red-black trees or some other implementation of associative arrays, at least in cases where strings sent by the user are used as part of a hash key. Perhaps Perl's tainting mechanism could help with this.

Re:question to practical programmers

[JordanH]

• If the code is not time-critical then why optimize for average case performance?

If the code is not time-critical why optimize at all?

The choice of hash tables may have been convenient for implementation, but not taking into account any performance issues. The fact that it's good for average cases is a unintended benefit.

Re:question to practical programmers

[TheTick]

someone (possibly the programmer) will die if this code does not run in 0.05ms.

You simply don't use Python in this case.

You use something else for the parts for which it can be shown that Python is insufficiently fast. You use Python for the rest.

Re:question to practical programmers

[Matts]

Perl has fixed this in the soon-to-be-released perl 5.8.1

Re:question to practical programmers

[scrytch]

If you want to see an interesting container implementation (based on a trie, behaves like a hashtable) check out Judy Arrays. Judy is bogglingly complex, but it boils down to optimizing for the CPU cache.
Judy looks fairly promising for some applications I'm looking at. The benchmarks I ran are sort of bogus though since I'm not causing fragmentation by doing other things between inserts and deletes. I suppose the moral of the story is, preallocate if you know your structure is going to get big.

Re:question to practical programmers

[grassy_knoll]

If you're taking input from the user, a sanity check on that input is in order.

I use regular expressions for this. Example code is perl ( since I use that more often, not to dis python ):

unless ( $ARGV[0] =~ m/\p{IsAlpha}+$/ ){
die "Bad Input!\n";
};

print "Input\: $ARGV[0] is good\n";

Checks for all alpha input, while

unless ( length($ARGV[0]) <= 5 ){
die "Bad Input!\n";
};

print "Input\: $ARGV[0] is good\n";

Checks that the input is no greater than 5 characters, but can be less.

Re:question to practical programmers

[Ed Avis]

I'm not 100% sure that uour sanity checks protect the program from excessive hash collisions. Well, maybe restricting to five characters or fewer would do it - but even in the space of five-char-or-shorter strings there must be an awful lot which hash to the same value. Maybe five alphanumeric characters would be a small enough space.

Still, there are cases where you need to allow fairly long and diverse inputs, but still worry about DoS hashing attacks.

Re:question to practical programmers

[miu]

Thanks for that link. I've written trie structures based on the description in Perlman, the MIX-code in Knuth, and the diagrams in the MIT algo book - but this is the first chance I've had to look at an actual implementation done by someone other than myself.

Re:question to practical programmers

[grassy_knoll]

Code snippets were ment as examples, not a be-all end-all solution.

The point I was trying to make is "check that the input is as expected", and there are a number of ways to do that. For command line input in perl I like regex, for web / gui apps I prefer list boxes, radio buttons, etc. to limit user input.

Of course, the only 100% sure way to prevent hash corruption is "dont use hashes". ;)

Re:question to practical programmers

[Ed Avis]

The trouble is that the input can be 'as expected' yet still cause hash collisions (which are not corruption - just a slowdown). You can check that every value looks sane, but if you are allowing more than very short strings, it won't help you.

You're right that the only absolutely certain way to avoid hash collisions is not to use hashes; however you can make a probabilistic argument that the chance of really bad collisions happening is close to zero, and less than the computer being struck by lightning. But that is only true if an attacker doesn't know your hashing function and so isn't able to purposely generate strings with the same hash value.

Re:question to practical programmers

[smallpaul]

Tim Peters, one of the top developers, believes that the threat is over-hyped relative to similar well-known attacks against qsort and regular expressions. Guido felt that the cost did not justify the benefits.

Re:question to practical programmers

[Ed Avis]

FWIW, I think that the problem of maliciously constructed input is a good enough reason not to use an unmodified qsort, at least not in cases where you sort large inputs provided by an untrusted user. There are sort functions which have bounded worst-case performance, even though they may be slower (say, twice as slow) than qsort in most cases.

With regular expressions you have to either write a complex regexp (a true regular expression can take only polynomial time in the string length, I think) or allow the user to provide both the regexp and the string to be matched, so that attack is less likely to take you by surprise.

Re:question to practical programmers

[smallpaul]

With regular expressions you have to either write a complex regexp (a true regular expression can take only polynomial time in the string length, I think) or allow the user to provide both the regexp and the string to be matched, so that attack is less likely to take you by surprise.

Perl and Python programmers hardly ever write "true" regular expressions in the Chomsky/CS sense. It doesn't matter whether you are doing something complex or not, you are unlikely to restrict yourself to that subset.

Re:question to practical programmers

[Ed Avis]

You sure? I only rarely need to use backreferences, lookahead, or other 'irregular' features. Nine times out of ten a regexp needs only ?, + and *, plus alternation and simple anchors like \b. As far as I know this can be straightforwardly translated to a true regular expression.

Excellent PICKLE enhancements

[bobo333]

picle

Sounds like a Vlassic picle. More crunch.

Well, this is good, but I'm hoping for more.

[vkg]

Not, necessarily from this particular release, but in general the whole objective/functional thing which Python is doing really is very interesting and ought to be pushed further.

Some way to use Perl libraries would really kick ass too but I guess that's impossible without Parrot coming into reality.

Re:Well, this is good, but I'm hoping for more.

[murple]

Some way to use Perl libraries would really kick ass too...

Google for pyperl.

Platform Competition?

[Chromodromic]

Check out Artima if you want to see Bruce Eckel's take on the Python language which, incidentally, with the addition of things like a logging API, and with long-existing additions like Jython, is beginning to look more and more like a viable competitor to Java.

Why?

Python carries a LOT of the same advantages, but with a dramatically accelerated prototyping and general development speed, and a few tricks of its own. Plus, via Boost, it interoperates with C++, too. I'm an avid Perl hack, but I have to admit that Python, which even has a whole API for basic game programming is looking more and more attractive for quite a number of things.

Download soon and often.

Re:Platform Competition?

[73939133]

[Python] is beginning to look more and more like a viable competitor to Java.

Python is a great scripting language and development in it is much easier than in Java, but it is not a competitor to Java. Java achieves close to C/C++ performance on low-level code (for loops, arrays, etc.); Python doesn't even get close. That really matters in many applications because it means you don't have to "drop down" to C. And Java has static type checking. Static type checking is a nuisance for prototyping, but it is crucially important for building large system.

Java and Python are just very different tools for very different applications. Both are probably misapplied a lot.

I should also mention that I don't actually recommend you use Java: it is a proprietary language and has a number of serious design problems. If you want a Java-like language, ECMA C# (not .NET) as implemented by Mono is a better choice in every respect. But there are many other statically typed language choices out there if you don't like C# or Java.

Re:Platform Competition?

[mixmasta]

Maybe you are right but I have written several apps in python and java, and the ones in py left java in the dust. Much less memory for the runtime too.

Re:Platform Competition?

[wdr1]

ava achieves close to C/C++ performance on low-level code (for loops, arrays, etc.); Python doesn't even get close.

Wait, now Java people are saying other languages are too slow?? ;-)

-Bill

Re:Platform Competition?

[Malcontent]

It seems to me that everything Bruce praises about python also applies to most other dynamic typed scripting languages. Certainly ruby and even php or dare I say it perl.

He seems more in love with the idea of typeless, brief, dynamic and expressive languages in general. it's just that he learned python first and has gotten good at it. If he picked up Ruby first he would be saying the same things about it.

Re:Platform Competition?

[GooberToo]

This is a common saying when you talk with Python/Java programers. Plus, with something like wxPython, you can have a slick client application to boot.

Last time I saw unbiased performance comparisions, the difference between Python and Java wasn't really worth talking about.

Re:Platform Competition?

[Anonymous Coward]

No, Python is not a competitor for Java. The reason why is because Python does not have a monstrous, hulking corporation shoving it down peoples throats. Python does get close to Java performance for a number of things, and for those which it doesn't it is easy to incorporate C or C++ code into it(remember the 80-20 rule here). I'm really starting to think that the whole static type checking as a requirement for large systems thing is just dogma.

Re:Platform Competition?

[Baki]

For a "kind of" interpreted language, Java is really relatively fast. It comes quite close to C, something that cannot be said of tcl, perl, python etc.

Java is known for is slowness only due to

• old versions used to be slow
• the "pure" i.e. non native-library GUI API (AWT, swing) are slow, however nothing stops you from binding Java to native GUI such as GTK or QT.

JDK 1.4 has seen good improvement once again, especially in the area of multithreading, less global locks needed.

Re:Platform Competition?

[73939133]

Maybe you are right but I have written several apps in python and java, and the ones in py left java in the dust. Much less memory for the runtime too.

There is no contradiction: the Java libraries and the Java runtime have numerous design flaws that cause people to build bloated and sluggish applications in Java. In fact, the same can be said for many C++ frameworks.

But if you just look at the languages and their implementations, it's easy to compile Java into tight, efficient machine code, while the same is just not possible for Python. Python is a great language with many applications, but it simply is no substitute for statically typed languages like Java, C#, or C++.

Re:Platform Competition?

[archeopterix]

I'm really starting to think that the whole static type checking as a requirement for large systems thing is just dogma.

In fact, Java is a proof of that. Static type checking with most collections being Object holders? If you want typechecking, use a language with some decent type constructors (C++ templates will do, but ML-derivatives have much cleaner type systems). If you implement generics with Object, you defer typechecking till runtime, when your Objects get downcast to whatever you hope they really are.

Re:Platform Competition?

[GooberToo]

Was nice of you to post as AC. Seems your reading skills need some work. Which makes it obvious why you posted as AC. I said, "it's not worth talking about". I never said Java wasn't faster. That's actually a fairly old version of Python and Java in that comparision. Now then, throw in a benchmark which actually allows for Java's GC to kick in, then you'll see Java's performace stumble, fall and simply cry. In turn, it significantly closes the performance gap. That's the biggest problem with by-n-far, most Java benchmarks. That is, they are short enough to prevent GC'ing from occuring. As such, it looks good on paper but performs much worse in real world applications. Python, on the other hand, constantly pays its collection dues when something falls out of scope. As such, most Java versus Python comparisions heavily bias toward Java. Create a benchmark which runs long enough for Java's collector to kick in, and you'll see a world of difference. Oddly enough, many real world applications help show this difference without problem.

The fact that python constantly collects is one of the reasons why python has a much smaller memory footprint than java. Don't forget that Python just got 10%-30% faster too. That too should significantly help close the remaining performance gap. Still even more funny, Python has not been significantly optimized to date. That means you can continue to expect python's performance to increase. Java, on the other hand, is pretty much about as fast as it's going to get.

You need to learn how to compare apples to apples and even know what you are talking about. All of the above is why, in real world terms, the performance differences between Java and Python s not worth talking about. Want to compare performance of wxPython with Swing? Be prepared to laugh until you pee.

Re:Second fucking post

[Sir Haxalot]

If you dislike the posts he makes, it might be a good idea to set him as a Foe, and browse at Foe -5. That way you will never have to look at his huge limp phallus again!

Its 20-30% faster !!

[vivek7006]

According to a couple of simple benchmark, Python 2.3 is about 20-30% faster than Python 2.2.3. Some of this speed-up was obtained by removing the SET_LINENO opcodes, which means that the difference is less impressive when comparing "python -O"; the rest was various careful tune-ups.

This is a big improvement. The biggest advantage of using a programming langage like python is the fast development time (5X-10X faster than C++). If the speed of execution of python scripts can be made comparable to compiled C/C++ code, then it would be awesome. Python programs can never be as fast as compiled code, but if the difference in the speed is not significant, it will be a big win for Python

Re:Its 20-30% faster !!

[elflord]

If the speed of execution of python scripts can be made comparable to compiled C/C++ code, then it would be awesome.

Out by an order of magnitude, and not getting closer any time soon. Last I checked, it's out by a factor of 100 or so for small operations (loops, etc) But this isn't a problem in practice -- one can code the speed-critical stuff (whether that be objects, or functions) in C or C++, then wrap them in python, and enjoy all the benefits of python.

Also, it often happens that 1% of the speed of C and C++ is actually good enough. Sounds slow, but only compared to C and C++ which may be well over 100x faster than what's required.

Python programs can never be as fast as compiled code, but if the difference in the speed is not significant, it will be a big win for Python

It is much slower, and unavoidably so. It's a very dynamic language, and this has consequences as far as performance is concerned.

Re:Its 20-30% faster !!

[Anonymous Coward]

Most desktop applications spend almost all their time either waiting for user input or reading from disk. Having written applications in python, I can attest that it is plenty fast.

For big programs, python's greates weakness tends to be its biggest strength - its dynamic nature. The fact that there is no strong type checking done by the compiler (i.e. one can enter i=1 and later change the type of i to a string via i="hello") can introduce a lot of confusion.

I'd really like to hear about a python tool that could at least generate warnings at compile time about these type changes.

Re:Its 20-30% faster !!

[ansible]

Out by an order of magnitude, and not getting closer any time soon. Last I checked, it's out by a factor of 100 or so for small operations (loops, etc)

Well, regular Python code can see some dramatic speedups, with just a little bit of extra work. Check out Psyco if you firmly believe that interpreted languages will never ever be as fast as C.

With sufficient cleverness, it may be possible to boost Python beyond the speed of the most highly optimized pre-compiled program.

Psyco and approaches like it do have drawbacks, but there is some very interesting work going on now with high-level languages.

Re:Its 20-30% faster !!

[Alan Shutko]

Check out Psyco if you firmly believe that interpreted languages will never ever be as fast as C.

Or you could use Common Lisp, and realize that you're a few years behind....

Re:Its 20-30% faster !!

[jgardn]

Python is running on a virtual machine that uses a stack. This is what pretty much every high level modern language does, including Perl and Java.

However, with the addition of Parrot, Python, as well as Perl, will be running on a virtual machine that uses registers rather than a stack. Register based machines are much faster than stack based machines.

Damian Conway, in a presentation at the Seattle Perl User's Group, demonstrated that you can actually get code that is written in perl that runs only a small factor (like 4 or 5 times) slower than C, rather than many orders of magnitudes (like 100 or 10,000 times) slower. This speedup will benefit Python as well, when it is ported to Parrot.

In short, Python and Perl, and every other language that is ported to Parrot, will kick some serious butt, and put a lot of C programmers out of work.

Re:Its 20-30% faster !!

[occupant4]

It is much slower, and unavoidably so. It's a very dynamic language, and this has consequences as far as performance is concerned.

Perhaps this is a dumb question, but I don't know how interpreted languages work. If it were possible to compile Python (or any other interpreted language), would this make it anywhere near the speed of C/C++? Is Python's slowness the result of the overhead of the interpreter? Or is it just an inevitable side effect of abstracting programming to such a high level?

I know a huge benefit of interpreted languages is that they can run anywhere. But I've often been impressed with the ease of coding in such a language, and thought to myself, "It's a shame it has to run so slow. Now if they could just compile it to machine code..."

Re:Its 20-30% faster !!

[elflord]

If it were possible to compile Python (or any other interpreted language), would this make it anywhere near the speed of C/C++?

Compiling alone wouldn't bridge the gap. Python already reduces interpreter overhead by using a pre-compiled byte-code. A large part of the problem is in dynamic typing: for example, when you say
a+b
in python, it's not equivalent to doing the same in C++. In python, you need to do a runtime type check and then decide what operation to perform, and only then can you add a and b. In C++, the dispatch can be performed compile-time.

What you really need to get a big speedup is some sort of mechanism that can eliminate a lot of this type checking (the other guy posted a link to an interesting approach to this problem)

But I've often been impressed with the ease of coding in such a language

It's a bit of a two-edged sort for the same reason -- the lack of type checking makes it easy to write code quickly, but it also makes it easy to code incorrectly.

Re:Its 20-30% faster !!

[samih]

For big programs, python's greates weakness tends to be its biggest strength - its dynamic nature. The fact that there is no strong type checking done by the compiler (i.e. one can enter i=1 and later change the type of i to a string via i="hello") can introduce a lot of confusion.

I'd really like to hear about a python tool that could at least generate warnings at compile time about these type changes.

PyChecker (http://pychecker.sourceforge.net/) is a tool for catching the most obvious errors, but I'm not sure if it handles your specific case.

But in reality, how many (and especially hard to find) problems does the dynamic typing cause? Even primitive unit tests (or manual testing) catches errors like typos right away. Static type checking by itself guarantees very little about the correctness of the program.

And Python's competitor Java doesn't really isn't any different in this regard. Until JDK1.5 comes out, the minute you use the Collection API, you forgo any (small) benefit static type-checking might give you.

Re:Its 20-30% faster !!

[GnuVince]

Quote from elflord:
It is much slower, and unavoidably so. It's a very dynamic language, and this has consequences as far as performance is concerned.

Common Lisp is a very dynamic language, but compilers like CMUCL and SBCL produce programs whose performances match those of C and C++. See http://www.bagley.org/~doug/shootout/ and see how well CMUCL performs.

Re:Its 20-30% faster !!

[Homburg]

Can you expand on this:

However, with the addition of Parrot, Python, as well as Perl, will be running on a virtual machine that uses registers rather than a stack. Register based machines are much faster than stack based machines.

Surely the main advantage of registers on real machines is that they are on-chip, and so avoid a memory lookup. That isn't going to apply for a virtual machine, so I'm not clear why register-based VMs would be quicker. I guess you might avoid a level of indirection(in pseudo-C, you access vm->register, rather than vm->memory[address]), but would that have a significant effect on speed?

I'm not denying that Parrot is a good thing, and it may well be faster than CPython (I've no idea). I'm just not sure I follow your reasoning.

Re:Its 20-30% faster !!

[AMK]

Note that Python on Parrot is complete vaporware at this point in time, and I don't know of anyone who's actively working on it. Given this, claims that Python-on-Parrot will have improved performance are really premature; what if some critical bit of Python's object model can't be implemented efficiently on Parrot, or relies on a particularly slow opcode? It's too early to form a judgement.

Re:Its 20-30% faster !!

[William Tanksley]

Register based machines are much faster than stack based machines.

Why do you say that? I've worked with stack machines that were faster than register machines I'd worked with. Stack machines are easier to generate code for, and easier to compile to efficient machine code; I don't see why register machines should be faster unless the number of virtual registers happens to exactly match the number of machine registers.

-Billy

Re:Its 20-30% faster !!

[fredrikj]

Agreed. My experience with Psyco is that a 100% speedup is the WORST case. On average, code seems to run about 4x faster!

I really hope Psyco gets implemented in the standard interpreter (or at least in the standard library) soon. There are some bugs and issues with it, but they don't look like they can't be fixed...

definately?

[derrith]

I dislike trolling (as I assume this post will be modded) however, the misspelling of the word "definitely" has begun to irk me greatly. As a high school student who sometimes has to view the writing of my peers, I have to lower my expected standards. But when I go to read /. I'd assume that The-ones-who-post-stories-from-on-high might be able to spell check their commentary. Thank you for listening to my grammar rant.

.

Re:definately?

[joe_bruin]

your new hear, i take it.
we definately do not waist are time with speling and grammer, you looser.

in the immortal words of homer*:
"if i spelled cat 'C', 'A', 'T', you'd know what i mean"

* simpson, homer j. not that other guy.

Re:If anyone wants a good python book...

[obsidian head]

Mind telling us in a diary or future post how much you were able to get from the referrer? Just curious, I'm thinking of testing this out myself.

Re:No takers for "subscription"? [Somewhat OT]

[larry bagina]

unless the story was posted by timothy, and it takes half an hour for him to unclick the "archived" button.

Re:Why Python is good at our university

[The Bungi]

He's a troll. "Fu-Ling Yu" Get it? Haha and all that. He just pastes some links from the quoted article and get modded +5 with alacrity because of his charming "engrish". The stupid mods always fall for it.

Re:Why Python is good at our university

[bsharitt]

At several schools Java is the language you start with in CS.

Re:Why Python is good at our university

[HBI]

When I was going to school (late 80s) Pascal was the language of choice.

Please don't assume academics know jack shit about reality. Despite the fact that Pascal was a not-bad way to learn procedural programming, it was an error - we should have learned C. Ditto for the people learning Java today, including my girlfriend who learnt Java on her way to her BACS and has a mean ass hard time with certain portions of C as a result.

Better than Learning Python.

[Big Sean O]

Learning Python is getting quite dated (it covers Python 1.5). I recommend Python: A Visual Quickstart Guide by Chris Fehily. It's a better book than Learning Python, at least.

I've been learning Python Language for a while, but since I don't work with other programmers, it's taken me quite a while. I learned python the usual way (a mix between the on-line tutorial and Learning Python) and my fluency is improving.

I picked up this book recently while I was at a convention in Baltimore. I liked its organization: the book features a whole chapter on each datatype (strings, numbers, tuples, lists, and dictionaries). There are also chapters on Control Flow Statements, Functions, Modules, Files, Classes, and Exceptions.

Because of its organization, it's as useful as a reference as it is a tutorial. Each chapter contains progressively advanced examples that end up demonstrating the finer points of each topic.

For example, one hint was to use the vars() function creates a dictionary of the local namespace. This makes it useful when string formatting:

>>> quality = 'color'
>>> thing = 'orange'
>>> print "What %s is an %s?" % (quality, thing) # useful for simple formatting.
What color is an orange?
>>> print "What %(quality)s is an %(thing)s?" % vars() # more legible and useful.
What color is an orange?

The book does not cover advanced topics like Tkinter, Jython, or extending Python with C. Nor does it cover the Library modules (the Python online documentation is actually quite good).

"Python" is newer, cheaper (22 USD vs. 30 USD), and longer (410pp vs. 368pp) than "Learning Python"

I would recommend this book to anyone who would like to learn Python. If you're an intermediate Pythoneer, I agree with the parent: you will want to get "Python In A Nutshell".

Re:Better than Learning Python.

[Big Sean O]

Your [sic] welcome...

Re:Better than Learning Python.

[moral kiosk]

For example, one hint was to use the vars() function creates a dictionary of the local namespace. This makes it useful when string formatting:

Even cooler than that, (thanks to O'Reilly's Python Cookbook) is the ability to evaluate expressions embedded in strings. My copy of the Cookbook is at work (I hack Python for a living, woo), but there's an 'Eval' recipe that I use constantly for converting run-time parameter values into input files for older codes that have to be run via the OS.

The Eval class uses three handy Python concepts. First, it uses sys._getframe(1) to get the namespace of the current frame (actually the caller's frame, since we are in an instance method). Then it uses the flexible typing of Python to 'act' like a dictionary, by defining the __getitem__ special method to evaluate whatever hash key (i.e., string) is passed in as Python code . Lastly, Python string formatting can be fed a dictionary, and the format arguments are looked up in that dictionary. But our 'dictionary' is actually (an instance of) the Eval class, which knows about the caller's namespace and which can eval() statements dynamically.

Obviously, if this were some kind of code where security was important, the Eval class is no good. But in our (trusted) applications, it is an insanely handy way to dump lots of different (but similar-looking) files without having to do a lot of weird variable naming.

So, assuming the Eval class exists:

>>> evaluator = Eval()
>>> x = 1
>>> y = 2
>>> z = 3
>>> print "%(x)d + %(y)d * max(%(z)d, 4) = %(x + y * max(z, 4.0))d" % evaluator
1 + 2 * max(3, 4) = 9

When I have to make a seventy-line input file that repeatedly combines trigonometric functions in several different combinations, this recipe allows me to skip (1) slowly piecing together the string one line at a time and (2) deciding on the operations that will define the string format arguments ahead of time. So I can make the metastring in an input file rather than having to open up a real module every time I want to change the way some (other program's) input file looks. Variations exist; sometimes I don't want to use the current namespace, but I do have a dictionary of values and I'd still like to embed the expressions in the metastring.

If you are totally new to Python, but have some experience in other languages, I recommend finding the Cookbook at a bookstore or library and just having a seat for a while and skimming through some of the recipes. It's a good way to find out why so many people like the language, as well as a good introduction into the 'Pythonic' way of things. The chapter 'Programs about Programs' has some neat tricks, as do the 'Algorithms' and 'Functional Programming' (or some variant) chapters.

Re:I see whitespace is still syntactically relevan

[wass]

There's a feature I'd like to see removed.

I hear this repeated fairly often, but I can not think of any really good reason why whitespace is bad. IMHO, any decent programmer worth his/her salt will whitespace their code anyway for sanity.

Just to be my own devil's advocate, here are some reasons I can think of off the top of my head. But I don't think any is sufficiently great for not using python strictly because of it's required whitespace syntax.

Actually, I want to become proficient in python, I've even got a few books, and just haven't gotten around to programming any application in it yet :-( But these are things I've wondered about (regarding the whitespace). Hopefully a seasoned veteran can point out why these aren't substantial problems.

• Putting a large block of code into a while or for loop.

  In C, if I am quickly hacking some stuff together and realize I want to put 100+ lines into a for loop, I can put brackets around the code and possibly indent it later if I wind up keeping the code for long-term.

  In python I'd have to manually go to all those lines and put the indent in. (I assume EMACS and other editors can do this automatically, if one knows the key combinations).

• TABS and order of whitespace

  This confuses me. Does python keep track of instances of \t in an input file? Are they distinguishable from spaces? If at some nested level of indentation I'm at [tab][space][space], is a line of indentation of [space][space][tab] at the same nesting level?

  If I'm at [space][space][space][space] can the next level of nesting be [tab]?

• For decently-complex programs there might be so many nesting levels that the indented code is spaced so far inwards that one needs ridiculously-wide displays for sanity.

  Personally, I don't think I've ever put more than 10 levels of nested blocks in a program somewhere, but I suppose it could possibly happen and might be a problem, especially of someone is restricted to 80-column screen for some reason.

Other than those rare or obscure issues, I can't think of any reason that mandatory whitespacing should hold someone back from python.

Re:*Why* should programming in Python be faster?

[Anonymous Coward]

Maybe for those who know Python it's faster, but that's no different than any other language: programmers work faster and better in familiar languages.

for the same reason that a perl hacker will get a reasonably complex task done upwards of 100x or 1000x faster than an assembly programmer.

Re:I see whitespace is still syntactically relevan

[Anonymous Coward]

There'safeatureI'dliketoseeremoved.Iguessit'sGui do'swayofjustbeingdifferent.

Isn't that better?

No cookie for you.

From relevancy to troll and back. Whitespace

[Anonymous Coward]

At one time people were really concerned with the whitespace situation in Python. While both sides made good arguments for and against having whitespace be syntactically important, it all boiled down to van Rossum's decision to make it so.

Then came the trolls. Lots of them. They saw that there could be bites to be had by just dangling the topic of whitespace out there. People were very willing to bite on the old arguments, but nothing was ever decided because all the arguments were just rehashes and the "experts" still saw mandatory whitespace as a crutch for stupid programmers, and Python "experts" said it helped them see where their blocks were. It didn't matter a whit, Guido went his own way.

But now, time has passed and Python's reliance on code beautifiers just to run has shown itself to be not quite the boon that it once purported to be. Yet Python enthusiasts still cling to the idea that whitespace ought to be syntactically relevant. So out come the old arguments, only this time the anti-whitespace crowd has more ammunition and the pro-whitespace gang is running out of bullets. But Guido goes his own way.

At some point the Python project will need to fork to release it from this whitespace requirement. In this day and age, only beginning programmers need such a visual crutch. Python has shown itself to be useful beyond Hello Worlds and Good Morning %s! It is time for the language to grow up. Too bad Guido still goes his own way.

Re:Why Python is good at our university

[HBI]

That's mostly it. She hasn't even messed with a lot of that as a result - give her an API with clearly defined functions and everything is ok, but the details of memory allocation and cross-language linking (say, x86 assembly) are way out of her league. They shouldn't be though - if they had grounded her in C this would be a piece of cake.

Maybe it's a generational thing too - I was hacking on DOS machines when I got home from school at night and had a lot of access to hardware. Bit fields and playing with registers were a necessary part of what I was doing. I was writing blocks of assembly code regularly just to get things done. She works on systems that are so heavily abstracted you never have to get that close to the hardware, in fact you can't.

Re:Why Python is good at our university

[bsharitt]

It could be worse, people could be learning Basic instead of Pascal and Java. At least they are slightly similar to C. I start programming with Basic and it's haunted me ever since.

Re:I see whitespace is still syntactically relevan

[jericho4.0]

For your first two points, a decent IDE helps a lot, or just being familiar with your editor of choice. It's much easier to figure out the key combo in emacs/vi than it is to indent 50+ lines.

For your second point, 10 levels of nesting is, IMHO, at least 7 too many. That's what subroutines are for. If you find yourself adding another level after three, it's probably time to look at your design.

psyco

[r6144]

The normal python compiler compiles to portable bytecode. I think you need some software that translate that to native (machine) code. It is called psyco, hosted on sourceforge.net. I don't know about its current status though.

Re:I see whitespace is still syntactically relevan

[Ian Bicking]

Putting a large block of code into a while or for loop.

Editor support is very useful in this case. In Emacs you can indent/dedent a region with C-C > and C-C < (i.e., control-C, then > or <); you mark a region by going to one end, hitting C-space, then putting your cursor at the other end (or dragging with the mouse).

TABS and order of whitespace

Python treats all tabs like 8 spaces, no matter the location. But mixing tabs and spaces is considered bad and potentially dangerous if you display tabs as something other than 8 spaces. You can use the -t flag to Python to warn you about this.

Discussions on tabs and spaces can lead to flamewars in Python circles. Many people hate tabs, and a significant majority of code does not use tabs.

As far as screen width, that's no different in Python than any other language. Deep nesting is a sign of a program in need of refactoring.

Re:I see whitespace is still syntactically relevan

[Big Sean O]

Most of your problems would be fixed with a good python-aware editor.

Putting a large block of code into a while or for loop.

Well, if you had a large block of code to insert, why not make it a function and call it. Also, when you're working with Python, you quickly learn (or assign) the "entab" and "detab" commands, so inserting the tabs aren't a problem.

TABS and order of whitespace

Most people have their editors convert tabs to spaces

For decently-complex programs there might be so many nesting levels that the indented code is spaced so far inwards that one needs ridiculously-wide displays for sanity.

Someone who is using 10 levels of nested blocks isn't effectively refactoring. Extract method now and then... :-)

Re:Why Python is good at our university

[HBI]

I used to use BASIC back in my CP/M days. Writing a 'Hammurabi' clone in MBASIC on a Kaypro 2+ never hurt me that much.

The lack of namespaces was the main hindrance - then again the programs could never get _that_ big on a 64k machine...

Most of the bad habits have gone away.

Nice Amazon scam buddy

[Voivod]

The only point of your post was to get your nice referral bonus for all the Slashdotters clicking through to Amazon.

Moderators should know to look out for this... it's way worse than karma whoring. Did you even read this book? I wouldn't be wondering this if your post wasn't so clearly a cash grab.

If so, it might help if you wrote something useful about why you're recommending it! (And I don't mean cut-n-paste from an Amazon review either...)

Re:Nice Amazon scam buddy

[Goldberg's Pants]

So what if he pimps a book at Amazon and gets a commission? If he makes a few bucks from posting that, good for him.

Boolean support

[jdfox]

Booleans in Python at last, hurrah. We should see Boolean support appear in Jython soon too then, and an end to fiddling with 0's and 1's.

Re:Boolean support

[mackstann]

Booleans were added sometime in 2.2... 2.2.2 I believe. But yes, very handy. :)

Re:Boolean support

[jdfox]

Booleans were added sometime in 2.2... 2.2.2 I believe. But yes, very handy. :)

2.2.1 added True and False constants, which were set to integer 1 and 0.
But 2.3 adds a true Boolean type.

Re:Boolean support

[Big Sean O]

what about:

if flag:
yadda yadda yadda

even quicker, eh?

Re:Boolean support

[jdfox]

For simple flags, yes, "1" is quicker to type than "True". But Booleans can make other kinds of code clearer:

"For example, if you're reading a function and encounter the statement return 1, you might wonder whether the 1 represents a Boolean truth value, an index, or a coefficient that multiplies some other quantity. If the statement is return True, however, the meaning of the return value is quite clear."

Re:Boolean support

[Meowing]

Sure, it can do that.

>>> i = 5
>>> while i:
... print i
... i -= 1
...
5
4
3
2
1

Re:Boolean support

[Meowing]

Darned if I know what that was about. Python's always had boolean operations on pretty much everything. Zero, the special value None (that's an object with no value assigned, kind of what C's NULL tries to be except that it really is different from zero), empty strings/lists/tuples, have always been false, any other value true. The new boolean type is really just there for people who want to do a little bit stricter run-time type checking, it doesn't really add any essential functionality to the language (which is exactly why its addition was resisted for so many years).

Re:Boolean support

[Big Sean O]

No, I'm just stupid....

I confused assignment with comparison.

flag = 1
flag == 1

Sorry, back to my hole.

Re:Boolean support

[Capsaicin]

The first one takes less time to write.

The second one takes less time to understand.

for example:

street_address = 1
"""does this mean a street address is 'on' (eg has been supplied), or that the street adress is 1?"""

street_address = True
#aha!

Re:Boolean support

[jdfox]

Clear function names are also a good idea. But one person's clear is another persons slightly-ambiguous: having the extra type is another string to your bow.
Code can never be made too readable, IMHO.

Re:I see whitespace is still syntactically relevan

[Anonymous Coward]

You don't seriously think that a tab/space/space is the same as tab/tab, do you?

That's the problem. Whitespace is INVISIBLE and there are MULTIPLE TYPES OF WHITESPACE. Relying on that kind of thing is dumb and blockheadish.

Luckily I don't have to work in the Python-using group. It's all Ruby for my team.

Shameless plug

[Lulu of the Lotus-Ea]

Alex Martelli has indeed written an excellent book. Actually, he almost wrote two excellent ones, since he is co-editor of _Python Cookbook_ too (but the latter is really more of a collaboration of dozens of people in the Python community than a book by an individual).

However, my book, _Text Processing in Python_, has at least one think over Alex's that is germane to this thread: I make a good effort to cover Python 2.3. I am quite confident that mine is the only book you can actually buy today that does so (I'm sure there will be more titles, and various updates, over time, of course). Don't let my title fool you, btw, I do a bit more than the title entirely admits to. But the title isn't a lie either, it really is focussed on the broad area called "text processing".

Anyway, there's nothing subtle in my plug. I really will get a couple dollars every time someone buys one (unlike the somewhat odd insinuation downthread about Sir Haxalot doing so). But then, I also invite everyone to read the entire text for free at:

http://gnosis.cx/TPiP/

So you can have something for nothing too, if you want.

David Mertz

Re:Shameless plug

[dtolton]

David,

I bought your book _Text Processing in Python_, I must say it is excellent so far (although I'm not too far into it). I've read Appendix A, which does provide a very good intro to the Python language (I've been using it at work for about six months solid now), and I'm wading through chapter one. There is a lot of material to digest in a short period in the first few sections. I have some background with Functional Programming from Lisp, but it's nice to see it covered in Python (as I have much more chance to apply it with Python). I particularly liked the introduction to Generators (new in Python 2.3) as I've already used them a couple of times.

I got the recommendation for your book here on slashdot, and I went to your site (the similarity to that troll link not withstanding). I was really impressed that you offered the full text of your book online, so I purchased it for several reasons:
1) it really is a well written book, which I got to really see by browsing through the chapters as opposed to the table of contents.
2) I want to support authors who are willing to make the text available online
3) I really did need a good Text Processing book, we process *a lot* of text at my job.

Thank you for this excellent Tome, I can already tell it's going to be used extensively at my workplace. Already several other copies are going to be purchased.

Re:Why Python is good at our university

[Kumkwat]

Why is she learning C now?

Unless ur an embedded applications developer/kernel hacker/lean and mean ....u can live ur whole programming life in ignorant bliss behind the facade that is the class library.

Re:I see whitespace is still syntactically relevan

[Cranx]

The reason I never bothered with Python is because of the whitespace issue, and I'll tell you why:

I don't trust that blocks are properly grouped.

When I program in C++, Java or even Ruby, and I create a new block, the first thing I do is close the block. Any code I put in the block I indent, but if the block grows, or my indenting gets goofy, I don't have to fear that my block is now improperly closing.

If I paste in a few quick lines of code for debug purposes, and it just happened to be indented differently than where I was pasting it, that would screw up the block closure unless I went and tabbed everything correctly. Sometimes, I *like* that the temporary code is indented wrong because it helps remind me to comment it out or remove it when I'm done debugging.

The whitespace thing is just too weird. It generates a lot of feelings that I might screw up my blocks. That sort of anxiety shouldn't be there; I shouldn't be so worried about blocks closing.

and it will be another 19 months

[Triumph The Insult C]

before i can get the new version after python.org is done with this slashdotting

post mirrors people!

how about lists

[Anonymous Coward]

It would be nice if python had lists with a head and tail. It would also be nice if it had non sequential threads, a collector instead of reference counting, and maybe a decent attribute analysis so that the expression "a"[1] is barfed on before being
run.

Re:how about lists

[Anonymous Coward]

• It would be nice if python had lists with a head and tail
  Python lists are a contiguous array. It's O(1) to get to the head or tail or anything in between. You might be thinking of lists from another language, like Lisp. Or you might be looking for a doubly-linked list implementation, which is easy to implement but rarely needed in real code.
• a collector instead of reference counting
  It has reference counting with a collector for cycles. What's wrong with that? BTW, it's an implementation choice. Jython uses Java's native gc. Python uses ref counting because that works better with C extensions
• maybe a decent attribute analysis so that the expression "a"[1] is barfed on before being run.
  Well, I've been known to insert "1/0" as a debugging aid. It's an easy way to raise an exception. Python deliberately aims for late binding and a clean, understandable implementation. What you want breaks both, especially since '''if 0: "a"[1]''' must not be barfed on.

Re:how about lists

[CustomDesigned]

Python lists have the functional equivalent of head and tail. What you probably mean is that you want to keep a reference to the tail and have the head get collected if not referenced elsewhere. Because Python lists are implemented as arrays, the whole array stays in memory as long as any part is referenced.

Python already has full garbage collection in both the C and Java implementations. The reference counting accelerates collection at the expense of runtime in C python. Since the reference counting overhead is fairly small compared to the overall interpreter overhead, it is a good tradeoff. Memory use is minimized, and circular references still get collected by the general collector. The Java implementation does not use reference counting, but relies solely on the Java runtime for GC.

Thanks to reference counting in the C implementation, you can write:

buf = open('infile','r').read()

and the file is closed as soon as it is read into buf. However, this is not recommended practice for maximum portability, since the file will not get closed right away in the Java implementation and future C Python version might drop reference counting.

While the python threading model does not easily take full advantage of multiple CPUs, it does make it easy to incorporate C code - even C code that is not written with threading in mind. Java supports full threading, but you have to be much more careful with JNI extensions. With python, all other threads are stopped when calling into C until you tell Python otherwise. So by default, non thread aware code runs just fine.

Re:how about lists

[axxackall]

head=list[0]
tail=list[1:]

Does it help?

Re:ATTENTION!

[larry bagina]

Upgrading to Python 2.3 will _not_ increase your skill levels, and will NOT make your AOL downloads faster!

Actually, it could. The PHP crowd blew every horn they could find when yahoo switched over to PHP, but AOL has been using python behind the scenes for a long time with little fanfare (or problems). So if it's AOL doing the upgrading, it might help your AOL downloads be faster.

Re:I see whitespace is still syntactically relevan

[Cranx]

Here's another one:

eval'd code.

Eval'ing anything more than complex than simple, pre-formatted blocks of text is going to cause a headache. One of the great things about interpreted programs is their ability to morph through eval calls. Having to ensure that blocks of text you paste together in code are properly indented to be interpreted via eval has got to be LOADS of fun.

To be fair...

[Big Sean O]

Alex Martelli has written an article that talks about the changes from Python 2.2 to 2.3.

David, thanks for making your book available on-line. I'll be sure to look for a 'dead tree' version.

Re:To be fair...

[Lulu of the Lotus-Ea]

Certainly. Alex' 2.3 update article is very useful, and covers a number of features that my book does not look at (mostly because they are peripheral to the text processing topic; but a few things I just did not know about in time for the various cutoff dates... I *did* add a word here and there even during proofreading to reflect updates). Far be it from me to suggest that Alex' doesn't know everything about what's in 2.3... or very nearly everything about everything sui generis. Andrew Kuchling's series on "What's New in Python X.X" is extremely useful for tracking version changes--he's done a magnificent job maintaining those.

Mostly it just boils down to the delays that go into publication, especially in dead-tree form. _Nutshell_ came out about three months before _TPiP_, so I had a window to look at some betas that Alex did not. FWIW, it's not in my book, but I did an article for IBM developerWorks that looks at the new [itertools] module in some detail. But even that is slightly out-of-date, since a few functions were changed prior to final release, and a few added that I did not know about when I wrote the article.

Yours, David...

new features?

[MikeFM]

Some of these features look useful enough but the one that stands out most as having a minor problem is importing modules from zip archives. That's all well and dandy but why not also support from other archives? tar + gzip or bzip would get better compression. The syntax looks like it could be a little clearer. Why not just 'import example.zip/mymodule' instead of messing with sys.path.insert() ? That sounds cleaner to me.

Re:new features?

[reddish]

The answer to your first question is easy; zip-files have a table-of-contents, making random access to a certain file contained in the file fast. Tar files don't have this, and bzipped/gzipped tar files are still more difficult to use for this kind of application.

By the way, a little known (and sometimes useful) property of gzip is that it is allowed to concatenate gzip-files, and the resulting file will gunzip to the concatenated originals. This is not just a quirk, it's by design, and works for bzip2 too. Not for tar though which is a bit of a pity.

Re:new features?

[MikeFM]

How many modules are you planning to pack? I can grab a desired file from a tarball with 1000 files in no noticable time. I don't understand why that'd be a problem.

I didn't realize gzip could concatenate files. How does that work? Just cat the resulting files together?

Re:new features?

[Simon]

Supporting gzip and bzip would probably be overkill. Besides I don't think that the main motivation for allowing zipped modules is compression and disk space. The real advantage is being able to distribute complete mulit-file modules as just one file, ala java's .jar files. (Easier installation, less mess on the filesystem, etc)

--
Simon

Re:new features?

[boa13]

I didn't realize gzip could concatenate files. How does that work? Just cat the resulting files together?

Absolutely. Read the "Advanced Usage" section of its manual page.

Re:new features?

[reddish]

I don't understand why that'd be a problem.

Sure it could be done. However I was answering your original question: "why not also support from other archives?"

For things like this (dynamic module loading) the obvious choice is simply to use a format that has a TOC. For this kind of application, that is a far more important consideration than saving a few percents of compression. That's also why Java's Jar files are in Zip format. It's just the right solution for this kind of problem.

For 1000 files you may not get burnt but I just did a benchmark on extracting the middle file from a 100,000 file ZIP, TAR, TAR.GZ, and TAR.BZ2, each file holding 1000 random bytes, no special compression flags used (default compression levels etc):

• zip: 0.11 sec/retrieval
• tar: 0.65 sec/retrieval
• tar.gz: 3.1 sec/retrieval
• tar.bz2 48 (!!!) sec/retrieval

So this does really start to matter for large archives; ZIP is practically O(1) while TAR and variants are O(length of file), on average cases, since they have to read (decompress) the entire file up to the point where the compressed data resides. Note also that BZip2 is really really slow.

I didn't realize gzip could concatenate files. How does that work? Just cat the resulting files together?

Yes. Cool, eh? :-)

Re:new features?

[MikeFM]

Only a mentally disturbed person would write a Python program with anywhere near 100,000 modules. Even my 1000 modules example sounds farfetched. :)

Sure bzip2 is slow but it'd still be useful. Of course it'd be more useful for storing bulkier data than modules but sometimes people will store large amounts of data as pickles and similar Python data. :)

Could just define a special indexed cat'd file type that lets you use any filter Python supported. So if you imported gzip it could read gzip'd modules.. if you imported an encryption module it could read encrypted modules, etc. Could be useful.. even if overkill. :)

Re:new features?

[reddish]

Only a mentally disturbed person would write a Python program with anywhere near 100,000 modules. Even my 1000 modules example sounds farfetched. :)

Sure. Still I fail to see any good reason why tar.gz or tar.bz2 would be preferable over zip for this particular situation. In cases like this, I would always favor the approach yielding O(1) behavior over the approach yielding O(number_of_files) behavior, even if number_of_files were usually small. it's a matter of software engineering ethics I suppose.

Really, the tar approached yield performance linear to the offset in the compressed file (that is just loosely approximated by the total of number of files. Now suppose your desired module file sits right after a 100MB file containing generated data that's also contained in the module (this kind of applications do exist in my line of work at least) - with tar.bz2 you would be in deep shit.

Ah well let's just agree to disagree or something :-)

Hexadecimal floating point yet?

[Thinkit3]

If anything decimal shouldn't be there.

Python 5

[intermodal]

three, sir

Three!

Re:Why Python is good at our university

[talleyrand]

I start programming with Basic and it's haunted me ever since.

Haunted? Leave it to dearly departed Edsger Dijkstra to say how it really is:

``It is practically imposible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.''

Re:ATTENTION!

[lawpoop]

And note that yahoo maps use python.

http://maps.yahoo.com/py/maps.py?Pyt=Tmap&ed=2eq1M up_0TpxXa5UN63mjyUSVQJsX5Sk2q8YXq2EXTawW.mGFYV8AHt JOL7B4CsQWw--&csz=Washington+DC&country=us

(purposefully not anchored)

Re: Why Python is good at our university

[gidds]

Personally (and knowing both languages well), I'd consider that a problem with C, not with Java...

Re:Why Python is good at our university

[axxackall]

Well, Java is not less experimental than Python. It might have a lot of hot air around it, but it is still breaking compatibility on every minor releases, it's still memory leaking like a ...

C and C++ are much more stable in both language reports and compilers, but Perl must be in the same so-called "experimental" group as Python and Java.

On the other hand, all of them must be in the experimental group, comparing to LISP (Scheme included), the language that survived since 1957 (amazingly - even still actively used, despite newfollowers like ML and Haskell), and FORTRAN, the language that existed for awhile since 1957 (well, perhaps too long for "awhile", but thanksfully it's dead anyway). And all of them are very real, comparing to really exotic languages. And they are practical, comparing to languages from our future.

Perhaps your school should give four groups of choice:

• dead languages from musiums: FORTRAN, Pascal, PL/1, COBOL, ADA, Smalltalk;
• practical languages for daily programming: Lisp, C, C++, Java, Perl, Python, Tcl, VB, Prolog, SQL;
• newcoming standards: ML, Haskell, C#, Mozart, Erlang, XML;
• real experiments, never came to real business, and barely will come: Icon, Snobol, Dylan, Curry, APL, Mercury;

However, I wonder, what's the academical point to separate artificially languages instead of requiring that students will take two language with at least two different parigms, like OOP vs FP?

Re:The dynamic duo.

[Billly Gates]

The ascii art is cool. Question did you download the ascii generator here or how about here?

Re:I see whitespace ... autogeneration a problem

[ajm]

My major object to whitespace instead of { and }, or similar, is that it makes generating code using XSLT an absolute nightmare. It may not be a big problem to other people but it is to me. Using { and } you don't have to worry about the indentation, which is a pain in the ass to get right with XSLT. For hand written code it's not a problem, any decent IDE, i.e. emacs, will solve the problem. For autogenerated code I think it's a real minus.

Really, Dr. FoolingYou

[thelexx]

This guy is a TROLL people. All the others calling his bluff got modded into oblivion. Read some of them, and/or take a quick look at this dudes posting history. I've given up the -1 mod I had used to point this out instead, karma be damned. Anyone who makes a hobby of publicly mocking other racial groups while hiding behind an internet connection deserves to be called out.

Re:I see whitespace is still syntactically relevan

[smoondog]

I love python, I use it alot. That said, I hate the whitespace problems with the language. I cannot figure out why they don't at least *give* you the option of not using that horrible, horrible design. Why is it flawed? In my opinion it is flawed because a miss tabbed document cannot be reliably retabbed without knowledge of the code. For example:

while 1:
---->while 1:
--------->dosomething;
xxxxx>i+=1;

Now where did the i+=1 go? I don't know. The way I deal with it is by doing this:

while 1:
---->while 1:
---------->dosomething;
---------->pass;
--- ->somethingelse;
---->i=i+1;
---->pass;

But that's a poor solution, because it isn't a standard. Add f*ing c-like bracket block notation already! It isn't that hard and if you don't want to use it then don't. I don't get it they add all of these wierd obfuscated lets-see-how-long-we-can-make-a-single-line-of-cod e additions but not this. Dumb, IMO. /rant

-Sean

Re:From relevancy to troll and back. Whitespace

[brian_olsen]

I really don't understand the problem here, and why people must cavil over a non-issue like required whitespace. If you don't like it, don't use it. End of story.

Nobody Expects the Whitespace Inquisition

[jefu]

Our chief weapon is trolling

Our two chief weapons are trolling and casting nasturtiums

Our three chief weapons are trolling and casting nasturtiums and not paying attention to what we're saying....

So your favorite language is whitespace neutral - completely so, right?

No preprocessor lines (C, C++) that terminate on an end of line (which I consider whitespace).

No comments that terminate on the end of line? (Java, C#, C++, Perl, and so on )

How about end of line embedded in strings? Is that legal (in which case is the newline part of the string or not)?

Extra credit to anyone who can name a language that treats whitespace either as completely neutral in all situation (including tabs and end of line markers), or as meaningful in all cases. (And for slashdot regulars I'll rule out WHITESPACE up front).

And, of course, there is a solution. Just use
#begin
at the beginning of a block and
#end at the end of the block. Of course, like any sensible programmer you'll indent the block as you do.

And while you are at it, if you like semicolons, you can always add #; to the end of statements.

Re:Nobody Expects the Whitespace Inquisition

[Gumshoe]

Extra credit to anyone who can name a language that treats whitespace either as completely neutral in all situation (including tabs and end of line markers

Rexx, or at least the ARexx variant, completely ignores white space, IIRC.

Re:Nobody Expects the Whitespace Inquisition

[ProfKyne]

And while you are at it, if you like semicolons, you can always add #; to the end of statements.

Actually, Python allows the user of semi-colons at the end of statements in most cases. Think of it more as if Python doesn't enforce them.

Re:I see whitespace is still syntactically relevan

[Tyler Eaves]

easy solution.

while something someval: #{
do.something()
while x 10: #{
print x
#}
#}

Re: Why Python is good at our university

[HBI]

If all anyone throws you is a straight pitch, you'll never learn to hit the curveball.

Re:Why Python is good at our university

[H.G. Pennypacker]

FORTRAN is most assuredly NOT dead. Just ask anybody involved in scientific computing. One good example of a modern scientific code, that is under heavy development, and is written in FORTRAN is FLASH.

Re:ATTENTION!

[smallpaul]

Do you have a reference?

Re:Why Python is good at our university

[Anonymous Coward]

Everything I've read that came out of Dijkstra's mouth or pen reminds me of my English grad school days.

"Your undergrad professors taught Hemingway/Joyce/Fitzgerald/Some other author we don't like? You have a lot to unlearn before you can even grovel at our feet. Your mind is tainted."

Typical ivory tower bullshit. Granted, some teaching methods and ideological positions lend themselves to learning better than others, but this is typical academic posturing.

Sorry for the diatribe, but this is what's wrong with American education at all levels. You don't get promoted and you don't get tenure by defending the status quo, no matter how effective it is. You get attention by pushing a platform that is different and strident. It doesn't matter if you're right or not because the administration only cares about the bottom line (grants, enrollment, university prestige). If your college of whatever attacks the other university's college of whatever, you have the upper hand.

This, of course, plays right into the hands of the majority of professors who are pompous windbags, whose chief pleasure in life is fucking TAs and putting down the frosh to make themselves look smart.

Take the word of academics with a grain of salt. They have agendas too. For that matter, take all authority with a grain of salt. Use authority as a starting point if you must, but approach it with scepticism and develop your own opinions. If somebody tells you goto is harmfull, try it out. If it works for you, use it. In the case of goto, you'll probably find that it is harmful. But if you find the answer yourself, you've learned more than the answer. You've learned more than how to pass the exam.

Bastion disabled

[Sloppy]

Bastion and rexec - these modules are disabled, because they aren't safe in Python 2.3 (nor in Python 2.2). (New in 2.3a2.)

Uh oh. What's unsafe about Bastion in 2.2?

Re:Bastion disabled

[samih]

The new introspection facilities introduced in version 2.2 allow one to go around Bastion and rexec restrictions.

Re:I see whitespace is still syntactically relevan

[Courageous]

If I paste in a few quick lines of code for debug purposes, and it just happened to be indented differently than where I was pasting it, that would screw up the block closure unless...

Actually, the chances are it would generate a Syntax Error.

C//

datetime module

[_|()|\|]

I'm looking forward to playing with the datetime module. The old C-based API is just gross.

Re:I see whitespace is still syntactically relevan

[jfx32]

Actually it's not that difficult. You can build the block you want to evaluate as a string seperated by semi colons.

eg: while something: do_this(); do_that(); i += 1

Re:I see whitespace is still syntactically relevan

[Cranx]

Which is still bad, but not as bad as the program quietly operating incorrectly, which is still possible.

Re:I see whitespace is still syntactically relevan

[smoondog]

You are correct, I didn't think my answer/solution through fully. That said, I'm still not a fan of the whitespace requirement. It frustrates the heck out of me when I switch between vi and emacs on new/different systems.

-Sean

Re:I see whitespace is still syntactically relevan

[Cranx]

But often when a sophisticated bit of eval work is going on, you are loading the code from a file; a file that was hand-edited by a developer.

it's a feature

[mkcmkc]

I'd consider the (slightly) increased difficulty in autogeneration to be a feature rather than a problem. 99% of the time, autogenerating code is a really lame idea. The other 1% of the time, you ought to be generating the indentation, too, for readability/debugability. So Python doesn't really lose here.

--Mike

Re:it's a feature

[Hognoxious]

I'd consider the (slightly) increased difficulty in autogeneration to be a feature rather than a problem.

I most certainly would not refer to increased difficulty in doing something as a feature. Especially if that thing was the thing I was trying to do.

99% of the time, autogenerating code is a really lame idea.

I've seen it not used when it should have been more often than I've seen it misused. YMMV.

The other 1% of the time, you ought to be generating the indentation, too, for readability/debugability.

What if it's one-shot code?

Re:it's a feature

[Hognoxious]

You pipe your code through pindent.py which is shipped in Python source code. What is the problem?

I don't use Python; I was speaking in general terms.

If I caught anyone who worked for me doing something as non value-adding as prettying one-shot code, I would boot their sorry ass out the door.

Re:Why Python is good at our university

[Ianworld]

At my school the basic programming course teaches 3 languages

The first is NetLogo because its really awesome and you can do great things with it very easily. Ever try to simulate the spread of diseases in a C program??? The second is Dr Scheme which is a newer form of LISP. Teaches kids how to use functions and recursion. And the tortures of syntax. I just love () now. Rather i love (((()))) now. That portion of the course is concluded by us making our own number system with simple arithmetic functions. I think we used A's to represent a unit. Finally we conclude with Python. Basically it teaches us how to use a liner programming language.(none of the others really read top to bottom.) Overall a very good course. They also teach an introductory course that spends a whole term on python. Python has everything the more advanced languages have and its free in everyway. Plus it is much easier to read and teach with. I love it as does everyone who takes the course.

Re:Why Python is good at our university

[Anonymous Coward]

Unless ur an embedded applications developer/kernel hacker/lean and mean ....u can live ur whole programming life in ignorant bliss behind the facade that is the class library.

this of course coming from somebody who uses "u" and "ur"...

Not a PLETHERA of Changes! - but useful bugfixes

[langles]

I often wonder how great Slashdot could be if it had a good editorial staff, but I digress...

To quote the Python 2.3 release page:

Nineteen months in the making, Python 2.3 represents a commitment to stability and improved performance, with a minimum of new language features. Countless bugs and memory leaks have been fixed, many new and updated modules have been added, and the new type/class system introduced in Python 2.2 has been significantly improved. Python 2.3 can be up to 30% faster than Python 2.2.

Pyrex also is worth considering

[bockman]

Psyco has been already mentioned. Another interesting approach to opptimising python code (only if and where it is too slow) is Pyrex". Unlike Psyco,it requires small changes (adding some type information) to the code of the python modules you want to optimize, and then produces an equivalent (but faster) C module.

Still a work in progress, but interesting.

Makefiles require tabs too

[Kashif Shaikh]

Makefiles also require proper tabs for inputing rules.

Re:I see whitespace is still syntactically relevan

[Courageous]

Which is still bad, but...

Not particularly, as in Python you know not to do that. Myself, I have VIM macros for intenting and outcommenting and incommenting code in a wide variety of programming languages. What you are describing is what I call a "theoretical problem that does not turn out to be a problem in practice."

C//

Speed of parrot might get Guido a pie in the face

[Reinout]

On Guido's weblog you can read that he's made a wager on parrot's speed:

And let's not forget the opening lightning talk, which I presented together with Dan Sugalski: the Great Python Parrot Challenge. Dan believes that at OSCON 2004, Parrot will be able to execute Python bytecode faster than CPython can. I don't give him a chance. Dan bets me ten bucks, a round of drinks, and a pie at ten paces.

So the power of parrot against the regular python-interpreter-written-in-c. Nice wager, though!

Re:I see whitespace is still syntactically relevan

[golan]

Well, It is said in the linux source code documentation. I know, it's C, but it simply says in /usr/src/linux/Documentation/CodingStyle:

[...]
Rationale: The whole idea behind indentation is to clearly define where
a block of control starts and ends. Especially when you've been looking
at your screen for 20 straight hours, you'll find it a lot easier to see
how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.
[...]

So, listen to the masters ;-). I suppose this piece of advice is worth noting in python too, well, at least the force indentation...

Re:Second fucking post

[jericho4.0]

I guess I should have said 'DON'T MOD THIS AT ALL!!', man people are idiots.

Notebook?

[marcopo]

Does anyone know of a notebook interface for python as for Mathematica?

Running python in an emacs shell allows for erasing previous I/O but new input can only be added at the bottom, and old inputs can't be edited and rerun.

Re:Notebook?

[costas]

Google for IPython, it does some of what you want and a lot more.

Re:Notebook?

[marcopo]

IPython appears like a nice environment, but is not quite what I seek. One of it's main features (from the IPython site is:

"Macro system for quickly re-executing multiple lines of previous input with a single name."

I would like to be able to edit previous input and re-execute it.

Additionally, IPython has a logging mechanism, but it appears from their site that these can only be edited after the session, and not during the session.
so far the closest I got is by running python in an emacs shell, and writing the input in a separate buffer with some key-combination for executing a block of code.

Re:I see whitespace is still syntactically relevan

[boa13]

You should use sts=4 instead of ts=4. ts is best left to 8.

Re:I see whitespace is still syntactically relevan

[boa13]

You don't seriously think that a tab/space/space is the same as tab/tab, do you?

Of course not. But as I understand (and as I do, and probably as the majority of Python programmers does), he meant that he only uses the tab key and the backspace key to indent his code. He has set up his editor so that there's only ONE TYPE OF WHITESPACE in his source files (":set expandtab" in Vim).

Besides, whitespace is not necessarily invisible. Using ":set list" in Vim can reveal the different types of whitespace in your file, and is very useful to spot trailing whitespaces, tabs and other problems.

Re:Why Python is good at our university

[kruntiform]

Dijkstra was half joking, trolling even, in that remark about Basic. In the same piece are other hyperbolic comments such as "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." Have you really read any Dijkstra? He always seems level headed to me. Your rant seems to be about a different kind of person entirely. Are you seriously suggesting he should have been defending the status quo of Basic (and Fortran and Cobol)? That Basic is effective? If someone tells you goto is harmful, by all means try it out yourself, but also go and read the careful reasoning behind that little quote.

Python is actually strongly typed.

[XNormal]

Python is definitely not typeless. It's actually strongly typed. But it uses dynamic typing.

Take a look at this article for clarification on typing models.

Re:Python is actually strongly typed.

[Fweeky]

Ruby is also strongly typed. Compare:

-% perl -e 'print "5" + 42;'
47
-% php -r 'print "5" + 42;'
47
-% ruby -e 'print "5" + 42'
-e:1:in `+': failed to convert Fixnum into String (TypeError)
from -e:1
-% python -c 'print "5" + 42;'
Traceback (most recent call last):
File "<string>", line 1, in ?
TypeError: cannot concatenate 'str' and 'int' objects

In cases like:

-% ruby -e 'foo = 42;puts "Number is #{foo}"'
Number is 42

Ruby's actually calling foo.to_str to get the String representation of the object.

Re:Python is actually strongly typed.

[William Tanksley]

I can't say that you'll _never_ see what you're asking for from Python (there are some variants that have it, such as IIRC "Psyco"), but it is unlikely. The problem is that Python's data is typed, not its variables. A lot of people like that, and there's sound reason for it, both theoretical and practical.

-Billy

Re:Python is actually strongly typed.

[Earlybird]

• I consider allowing this behavior to be rather untypeful: ...

In your example, you're not "changing the type of a", you're assigning a different value to the symbol a. In Python and other strongly-dynamically typed languages such as Ruby and Lisp, values, not symbols, have types.

Python is strongly typed -- it provides a powerful typing system and enforces typing rules -- and it's also dynamically typed, meaning that any symbol can assume any value, so type errors cannot be detected at runtime. A statically typed language, as the name implies, requires that symbols be declared as a specific type, and type rules will be enforced on syntax at compile time (statically-typed languages such as C++ and Java require additional runtime type checking due to their support for late binding support, ie. polymorphism).

There is at least one proposal for an optional, static type system for Python (something like symbol: type like Pascal). There is also a proposal, by the Zope Corp. people, for adding interfaces to the language.

Now even more stuff from Lisp!

[Anonymous Coward]

Yes, you too can use a half-baked lisp without admitting to yourself, with the new improved Python 2.3!

Remember, Greenspun's 10th is not just a rule, it's the LAW!

Re:Why Python is good at our university

[chriseyre2000]

morgan stanley use APL

Re:I didn't see a 'do not feed the trolls sign'

[Daath]

Uhm, emerge supports binary packages.

Re:I see whitespace is still syntactically relevan

[xr6791]

For your second point, 10 levels of nesting is, IMHO, at least 7 too many. If you find yourself adding another level after three, it's probably time to look at your design.

This is the same kind of bullshit as saying goto is always evil.

Re:I see whitespace is still syntactically relevan

[xdroop]

You come back in and type in those last 3 lines, but you forgot the indentation because the firealarm has completely broken your train of thought.

:set ai

emacs users probably have something similar.

All this said, I am of two minds regarding the whitespace -- enforced consistancy makes it a lot easier to decipher when reading at 3AM, but it means that the programmer has to do all the work when moving code around (ie there is little chance of there ever being a python equivilent to 'indent' or 'perltidy').

Unit Testing....

[t482]

Check out guido's reponse to that exact question. Unit Test - "Everything"....

Anthony

Re:I see whitespace is still syntactically relevan

[ProfKyne]

Putting a large block of code into a while or for loop.

Do what you should be doing in any other braces-based language like C or Java -- refactor a big chunk of ugly code like this into its own private function or method and put an invocation of this method in the while loop instead. If you need to act on local variables, pass them into the function/method as parameters.

TABS and order of whitespace

When would you ever use both tabs and spaces in your whitespace in any other source code file? Some people standardize on tabs of a certain width (2, 4, or 8 chars), others such as myself standardize on spaces, but I never mix them up simply because I can't "see" the difference. All of my editors and IDEs are configured for this. (The official recommendation in the Python style guide is to use 4-space indentation, but this is not enforced.)

Also, there is an option that will generate warnings if you run the program using differing whitespace characters to let you know you've been bad.

For decently-complex programs there might be so many nesting levels that the indented code is spaced so far inwards that one needs ridiculously-wide displays for sanity.

Again, if you find this to be the case, then you are not refactoring appropriately. Read Fowler's Refactoring and learn how to break up your code into more-manageable chunks (plus other great tips).

Beginners MUST learn C

[duck_prime]

It could be worse, people could be learning Basic instead of Pascal and Java. At least they are slightly similar to C. I start programming with Basic and it's haunted me ever since.

I have to weigh in here... it is my sincere belief that it is a huge mistake to start students in on high-level languages. If you start by learning that the JVM or the interpreter will "take care of it for you", it gives poor incentive to write carefully, with the real machine limits in mind.

I suggest that all students be forced to learn C and assembler first, to get an idea of what's really, really going on under the hood. Students need to build moral fiber by implementing Yet Another Linked List, by tracking down memory leaks, and going through the agony of allocating a multi-dimensional array.

After this experience, they will:
a) Appreciate the glories of Java, Perl & co.
b) Realize that even with memory-managed platforms memory is still a limited resource, and that leaks can still happen.
c) Be able to harrumph at the next generation for forgetting what programming to the bare metal is all about.

Hey I've gotta run, my dad is waving some IBM punch-cards and a soldering iron at me.

Re:Beginners MUST learn C

[bsharitt]

At my school the CS majors started with Java, but us computer engineering majors started with C++.

Re:Beginners MUST learn C

[smallpaul]

I have to weigh in here... it is my sincere belief that it is a huge mistake to start students in on high-level languages. If you start by learning that the JVM or the interpreter will "take care of it for you", it gives poor incentive to write carefully, with the real machine limits in mind.

Probably the right way to learn is to learn a high level language to get the basic concepts of programming, logic, abstraction, control flow, data structures etc. Then drill down through C to assembly. Then go back up to get useful work done. If you start with the low-level language you give people an inaccurate impression of how boring and nit-picky computer programming is. "Hundreds of lines of code to do some simple graphics? Computers suck!" Better to start them out with pygame and let them see the fun and easy side before hitting them over the head with the details.

Re:Beginners MUST learn C

[Chemicalscum]

I learnt in the order:

Dartmouth Basic, Fortran IV, Z80 assembler, ISO, Python.

Over the years

I dont think it was the right order I wish had learnt C first - but I gues I might still be preferring Python now

The real way to get some head and tail

[sblack]

Not to nitpick but the correct way to reference the head and tail of a list in Python is as follows: head = list[0] tail = list[-1] Please don't defile this beautiful language by posting incorrect code snippets.

Re:The real way to get some head and tail

[ameoba]

list[-1] is the last item in the list. To anyone coming from a functional programming background (such as lisp), the head of the list is the first element and the tail is everything else.

Lisp style cons lists are essentially a big nested set of tuples

[1, 2, 3, 4, 5]

translates to

(1, (2, (3, (4, (5, _)))))

so head (the lisp CAR) is the first element of this two item tuple, tail (lisp's CDR) is the 2nd element, or the rest of the list.

Re:Why Python is good at our university

[IpalindromeI]

Let me guess. You're still in high school or college and have never given a thought to the fact that your first real job will be as a maintenance programmer for an app/system that is probably older than you are. Those apps/systems were written in C. But I guess you'll just convince your boss to let you rewrite it in Java, right?

Re:Second fucking post

[jericho4.0]

My point still stands, though. You're going to see it anyway.

Re:I see whitespace is still syntactically relevan

[Cranx]

I have my own indention procedures as well, but if I don't follow them precisely, my code doesn't gain unwanted "features" as a result.

Just use Ruby

[Cranx]

Give Ruby a good, solid try folks, really. Python has NOTHING on Ruby, trust me.

on whitespace

[strombrg]

Whitespace that doesn't reflect a program's structure is a bug waiting to happen.

In that case, {'s and begin's are just an annoyance that take up extra space in many indentation styles, and introduce a class of errors.

People say that whitespace significance introduces its own class of errors. However, I've been bitten multiple times by bad indentation and bad {'s, while I've not once been bitten by python's usage of whitespace.

The easy rule is, don't use spaces in your indentation - only use one tab per nesting level. That way the 3 columners can see things at 3 columns, and the 8 columners can see things at 8 columns, and everybody gets to see things the way they most like, all from the same code. If you mix in spaces, then you end up stuck with one tabstop width unless you use a software formatter like gnu indent (which gives some people fits).

Re:I see whitespace is still syntactically relevan

[Courageous]

I have my own indention procedures as well, but if I don't follow them precisely, my code doesn't gain unwanted "features" as a result.

"In theory, there is no difference between theory in practice, but in practice there is."

Sir, I have never had a python program gain "unwanted features" using the *theoretical* weakness that you believe exists. Further, I would assert that this problem seldom ever actually arises, amongst beginners and experienced Python coders alike.

C//

Re:I see whitespace is still syntactically relevan

[Cranx]

I believe you. But I don't believe I would be as lucky.

Between whitespace problems and my fear of whitespace problems, I don't know which is worse. Even if, in actuality, there were NO whitespace issues at all, my reasoned fear that there are is just too much stress to have while programming.

I liked everything I have heard about Python, except for that one thing, and it's too much to overlook.

Re:I see whitespace is still syntactically relevan

[nobbis]

Your sole point is that a "miss tabbed document" (sic) breaks the code. Could you explain where this altered tabbing comes from? Would you similarly deride a language for not being impervious to random removal of characters?

I've written 10's of thousands of lines of Python code and have never had (that I can recall) a single problem with indentation, blocking or scope. I must admit, I had exactly the same knee-jerk reaction to Python as you before actually trying it -- it took all of one day of using it to wash away any doubts. This is after years of coding C++ and Java, BTW.

Side note: if you're terminating lines with a semicolon in Python then I doubt you "use it alot" (sic).

Re:I see whitespace is still syntactically relevan

[Courageous]

This was my feeling for years, before I picked up Python. Your fear is an irrational fear. The only legitimate problem I've run into with python programs are when functions get very long, and you'd like to quickly jump from begin-to-end of scope (or vice-versa). While a python-aware editor could do this for you, I don't use one, will never use one, and so have to occasionally tolerate that annoyance. Usually it's a good sign that the function needs to be refactored a bit, but so it is.

And the white space problems aren't as extant as most people think. For example, in Python, this is legal:

>>> a = [
1,
2,
3,
]
>>> a
[1, 2, 3]
>>>

Note that Python, at cetain points, actually becomes white space (newline/indent) *insensitive*. As it turns out, it does so at all the places where you might want it to.

Python is about the most readable programming language ever written. That's saying a lot for it, and implies something about how it handles white space as well. For one, your eye is not overloaded with tons of symbols as it might be in, say, Perl. :)

C//

Re:I see whitespace is still syntactically relevan

[smoondog]

What if you had to retab a large block of code because you added another while, an if statement, or a handler? Where do you stop tabbing? Also, have you ever tried editing python code in vi and emacs? It doesn't work with default settings. Your statement, however, is the perfect example of why this annoys me. You simply wipe your table clean by saying it isn't important. It *obviously* is important or it wouldn't have hung around this long...

-Sean

Re:I see whitespace is still syntactically relevan

[Cranx]

The fear probably is irrational, I can't argue that because I ran away from Python before I really found out. I have to admit that I'm just too much of a Ruby fan to even want to address the issue.

Beginners must learn Scheme.

[rjh]

Strangely, many of the world's preeminent CompSci institutions disagree one hundred and ten percent. At MIT, the CompSci curriculum begins with--and throughout remains heavy influenced by--Scheme. Why? Because hardware changes. Because the things you learn about computers by programming in C are really limited (not every computer is a register-based machine). Because learning how a specific computer works doesn't teach you bupkis about how computation works.

For that you need a formal model of computation. There are two principal formal models of computation: there's the Turing Machine and there's the Lambda Calculus. We don't have very many languages with explicit support for Turingisms. On the other hand, we've got several languages with explicit support for Lambda--from LISP and Scheme to ML and ... etc., etc., etc.

First learn about computation. Then learn about how to apply computational theory to a specific architecture.

That's the way MIT, Stanford, et al. are teaching CompSci nowadays. That's the way I was taught CompSci at the university level--our Intro to CS course was taught in Pascal (yes, I went to college that long ago), mainly because of demands that students learn something "practical" in CS141, but as soon as you got past Intro it was heavy on functional languages and lambda.

I wholeheartedly endorse it.

Re:If anyone wants a good python book...

[zopeuser]

I have read a number of books on python over the years. Last year I bought 'Python Programming Patterns'. I would strongly recommend this book to anyone who is already experienced in programming. It literally goes into very deep detail about many many features of the language.

Bruce hates Ruby

[sorbits]

He has later retracted his statement, but it is not positive.

And this post sums up what Ruby thinks of Bruce :-)

Re:Why Python is good at our university

[Hognoxious]

this is what's wrong with American education at all levels

You do realize that Dijkstra's not an American

You do realise that American Education is not Dijkstra?

Re:From relevancy to troll and back. Whitespace

[Hognoxious]

At some point the Python project will need to fork to release it from this whitespace requirement.

Couldn't you build a preprocessor to turn python-with-brackets into python with and ?

Re:I see whitespace is still syntactically relevan

[nobbis]

OK, I'll make this simple so that the logic is completely transparent:

In Java, program structure is defined by the programmer inserting appropriate "{"s and "}"s. Indentation can be implicitly determined by the editor based on this structure.

In Python, program structure is defined by the programmer inserting appropriate indentation. (If you wanted to), "{"s and "}"s could be implicitly determined by the editor based on this structure.

Your argument is that, with Python, an editor cannot magically retab the document as it can with Java. An equivalent statement would be to deride Java based on the fact that an editor cannot magically insert (redundant) "{"'s and "}"'s based on the indentation as it could in Python.

You ask "where do you stop tabbing?" after inserting an if statement. The answer, of course, is that in all languages, creating a new block is changing the structure. In Java, you do this by inserting your braces. In Python, you do this by changing the indentation. Your question is really: "how does an editor determine this implicit presentation based on the structure given by the programmer?". In Python they are the same thing so the answer is trivial.

To answer your question: I've exclusively used emacs as my Python editor for several years and have never touched any emacs settings w.r.t. Python.

Re:Speed? Perl vs. Python

[Meowing]

Yep. Python does a little startup dance looking for and loading default modules and directories, so it has more startup overhead. You can probably see from the syntax that the language isn't really intended for one-liners though.