Python 2.5 Released

dominator writes "It's been nearly 20 months since the last major release of the Python programming language, and version 2.5 is probably the most significant new release of Python since 2.2. The latest release includes a variety of additions to the standard library, language extensions, and performance optimizations. This is a final release, and should be suitable for production use. Read the release announcement, the highlights, what's new, and download it."

Comments

How appropriate...

[markana]

for Talk Like A Python Day....

oh wait, .... never mind.

Re:How appropriate...

[MightyYar]

You are thinking of Talk Like Cobra Commander Day.

Re:How appropriate...

[Tackhead]

> for Talk Like A Python Day....

AVAST! Ah've had it with these landlubbin' memes on this landlubbin' website!

Languages continue to evolve into ... Lisp

[Intron]

"Python copies even features [from Lisp] that many Lisp hackers consider to be mistakes." -- Paul Graham

Re:Languages continue to evolve into ... Lisp

[Scarblac]

Because 90% of programmers only know the simplest languages.

Re:Languages continue to evolve into ... Lisp

[ltbarcly]

C isn't simple, and in fact lisp is pretty simple.

Lisp isn't used because it wasn't standardized until the late 80's, it uses much more memory than C (though it is almost as fast as C++) and most programmers until recently have learned to program Unix and not Lisp machines. Also, MS doesn't have a lisp implementation so that means that if you don't go to a research university you won't see anything but MS (little podunk colleges are notorious for teaching 'how to program Microsoft'. Any college with a class in Visual Basic should have it's accreditation revoked.)

Finally C gives easy hooks into the OS, which isn't the same at all with Lisp, although you can do anything you can do with C it isn't Lispy to do so.

Finally, C is good enough. If you really want to wonder about languages, ask why Perl is used for anything. Perl sucks.

Re:Languages continue to evolve into ... Lisp

[Scarblac]

I think C is too hard for most programmers too. I may be in a bad mood, but I think most programmers do PHP and Visual Basic, badly. They wouldn't grasp Lisp's macros. Of actually good programmers, a very small percentage know Lisp; I wouldn't start a professional project in it for that reason.

I personally love Python (used it for all the code I wrote for my thesis), but these days I program Perl at work. It's not that bad, really. It makes sense, in its own way and it's got a good solid set of libraries available out there. Java isn't half bad for bigger projects either, actually.

About half a year ago, I tried to get into Lisp. It sounds like the holy grail - execution speed and error checking of a compiled language with all the speed of development of more dynamic languages. Perhaps s-expressions should be perfectly suited for HTML too (I'm still stuck in this web app world, at the moment). So I picked up Practical Common Lisp, installed SBCL, joined some mailing lists, found some libraries, got experimenting...

Two things meant I got disinterested in a month or so: it has far too many slightly-differently-named functions in the standard language, many with non-obvious names too (that's what PHP gets its harshest criticism for); and also the huge library of things you need nowadays (internet stuff, databases, OS stuff, etc) is either missing or rather undeveloped.

But it's still promising. I'll probably have another look in a few more months :-)

Re:Languages continue to evolve into ... Lisp

[drinkypoo]

All programmers should study assembler. With an understanding of what kind of action is going on behind the scenes, programming makes a lot more sense. Then they should probably move straight on to OO :)

Re:Languages continue to evolve into ... Lisp

[cortana]

http://www.paulgraham.com/iflisp.html

Re:Languages continue to evolve into ... Lisp

[a.d.trick]

I don't like the idea that some people make intrisicly "good" programers, and the rest are all somehow "bad"; as if some of us had bigger brains or something. Two years ago, my programming experience was limited to QBasic and a short foray into Visual Basic. I was a bad programmer. Fortunatly for the sake of humanity I stayed away from the computer for the most part at that point, otherwise I'm pretty sure something of mine would have ended up on thedailywtf.com.

Then I started to play around with other languages (PHP, JavaScript, Lisp, and Python) and over the course of a year, two the way I saw programming, changed. No dove came down from heaven with a booming voice. It was just my mind getting practice at building beautiful algorithms. The samething happened to me when I took up piano, singing, woodworking, and many other things.

So the question is not so much are you good enough to learn C, but are you willing to take the time. In C, algorithms tend to be quite a bit more complex than they are in Python, and further removed from our common speach. But it's not impossible.

Re:Languages continue to evolve into ... Lisp

[the_wesman]

Hate to burst your bubble, but SBCL is now known as AT&TL

Re:Languages continue to evolve into ... Lisp

[John Courtland]

I tried to get into LISP. I tried so hard. I ended up falling for Scheme and Haskell instead, Haskell more so. If you find some time and want to try your groove at functional programming again, and just can't get into LISP, give Haskell a shot. Something about the way Haskell is put together, I found it more intuitive. Although Haskell's syntax is, to quote Tim Sweeny of Epic Megagames, "scary", it's a really straight-forward language, and I like that. I did struggle with the severe type restrictions at first, they are especially severe if you're coming from C where everything can be anything else so long as you cast it, but it's nothing that can't be overcome with a bit of practice.

Re:Languages continue to evolve into ... Lisp

[smallpaul]

I thought I dispelled this myth years ago.

Here is the story as presented by Paul Graham (a famous Lisp expert). Of the three languages he chooses to discuss, Java, Perl and Python, Python is considered cooler (if not more popular) than Perl and Perl cooler (if not more popular) than Java because Python is most like Lisp of the three. Unfortunately, Python is a sort of immature Lisp which may over time grow into its full Lisp-yness but why wait around when you could just be using Common Lisp today? I'm sure if you are a Lisp programmer, it is a compelling story. Unfortunately it does not ring true.

http://www.prescod.net/python/IsPythonLisp.html

Re:Languages continue to evolve into ... Lisp

[CaptainPinko]

We all know whats going on under the hood... the point of a programming language is to abstract out the "under the hood" and present it in a more semantically appropriate format. Our code doesn't remind us that memory is read into registers and then processed... but we all understand that. It's good to understand offsets, but there is no reason for our languages to reinforce that and make us say stupid things like "the zeroth element".

Re:Languages continue to evolve into ... Lisp

[fuzz6y]

I don't like the idea that some people make intrisicly "good" programers, and the rest are all somehow "bad"; as if some of us had bigger brains or something

Every skill is a function of talent and training. The cornerstone of elitism is to grossly overestimate the role of talent, but to dismiss it altogether is no less foolish.

Re:Languages continue to evolve into ... Lisp

[ciggieposeur]

About half a year ago, I tried to get into Lisp. It sounds like the holy grail - execution speed and error checking of a compiled language with all the speed of development of more dynamic languages. Perhaps s-expressions should be perfectly suited for HTML too (I'm still stuck in this web app world, at the moment). So I picked up Practical Common Lisp, installed SBCL, joined some mailing lists, found some libraries, got experimenting...

Two things meant I got disinterested in a month or so: it has far too many slightly-differently-named functions in the standard language, many with non-obvious names too (that's what PHP gets its harshest criticism for); and also the huge library of things you need nowadays (internet stuff, databases, OS stuff, etc) is either missing or rather undeveloped.

All very true criticisms. I too have switched my new code to Lisp for the purpose of being a better programmer (and because I've got two years in a MS program to get my basic math toolset switched over). It IS getting better, and faster at that. I think we're approaching critical mass of people adopting it and pushing it into the Python/Java/Perl/etc. space with sockets, threads, SQL, UFFI (now CFFI), etc.

I think the biggest problems I've got with Lisp are packaging, pathnames, and the REPL.

Packaging means ASDF, which I don't like at all compared to Java or Perl's filesystem packages. To get a package with dependencies to work OK, you've got to create a .asd file and add a defpackage to either a separate .lisp file or your main one, and the .asd specification is not documented well (the wiki page for setting up sub-modules is flat-out wrong).

Pathnames ... UGH. I've already had to write my own version of a java.io.File just to have a string that is guaranteed to refer to an actual file.

REPL. Well, it's very nice to be able to talk to a running Lisp, especially when the Lisp is an application server and you want to alter some values or force a reload of an app, or just to poke around and see what kind of stats have been collected. However, the distinction made in the spec between compile-time, interpret-time, and run-time for code makes some things difficult, e.g. defconstant is completely useless with SBCL. I like REPL, every book should mention it, but they should very quickly move OFF REPL and show people how to just load a .lisp file and run it. The implementations should also make it easier to tune the output of the Lisp (try to get compile-warning's squished in SBCL, it's not pretty).

I would LOVE (and gladly buy two) copies of a book that had this information in it:

1. What is Lisp, and where to find the community web sites
2. How to locate, download, and install all the major Lisps on Linux, Mac, and Windows
3. Basic language grammar, including CLOS
4. How to use ASDF (including complex examples)
5. How to fully interface with the operating system, including implementation-specific functions for file i/o, network i/o, command-line arguments, the environment, threads, and more
6. How to package a standalone Lisp application to deliver to customers
7. How to use UFFI
8. How to set up a Lisp web application server (modlisp or Araneida or ...)
9. How to use the most common libraries: CLSQL, OpenGL, SDL

I know Lisp'ers love (and I do too) the fact we've got a spec and multiple implementations, but dangit if it isn't really difficult to get it all together and be able to actually DO something with it within a couple weeks.

Re:Languages continue to evolve into ... Lisp

[epee1221]

I've seen more than a few people wonder why they have to declare arrays with their sizes in C and can't just keep writing past the end when they run out of space (like with a java.util.ArrayList).

Re:Languages continue to evolve into ... Lisp

[Waffle Iron]

there is no reason for our languages to reinforce that and make us say stupid things like "the zeroth element".

Array indices don't point at elements; they point between them. The "first element" doesn't make much sense either since it actually occupies the whole imaginary fractional space between 0 and 1. People who don't understand this saddle the world with things like date systems where the years are counted ..., -2, -1, 1, 2, ...

So a language arbitrarily picks whether an index refers to the element to the right or to their left. I've used both, and each way has annoying special cases. However, counting from 0 seems more natural for a lot of manipulations that combine ranges or use a modulo operator to create indices, and it has the advantage of not needing an extra bit in the index when handling arrays with a power-of-two size.

Re:Languages continue to evolve into ... Lisp

[smallpaul]

All programmers should study assembler. With an understanding of what kind of action is going on behind the scenes, programming makes a lot more sense.

Perhaps they should also learn microcode because without that, you won't know what's going on behind the scenes in Assembler. And then to understand the microcode, maybe you need to understand electronics. And to understand the electronics, you should understand physics. So all programmers should understand Maxwell's equation lest they not know what's going on "behind the scenes."

Re:Languages continue to evolve into ... Lisp

[Garrett Fox]

You jest, but it is good to learn as many aspects of a problem as possible. The extreme opposite case would be a programmer who thinks he's a whiz at giving magic incantations to the glowing mystery box, and ends up sacrificing AOL CDs to it when it breaks.

In education in general, I'd like to see everyone know how to make things like one of those shaking-powered flashlights. A hands-on program like that would give people more of a sense of ownership over science and technology.

Re:Languages continue to evolve into ... Lisp

[Garrett Fox]

Can you point out a useful assembler tutorial? Best I can think of existing for free, online, is Core Wars.

Re:Languages continue to evolve into ... Lisp

[harlemjoe]

There are very many competent programming languages out there.

But if you learn any well-entrenched programming language - C, Java, C#, Python, Ruby and even Lisp, once you achieve a certain level of competence, implementing almost any algorithm, creating almost any application, in that language becomes a straightforward process.

However, it's easy, especially with languages with enormous library and industry support, to get locked into one particular language or family (eg C++ and Java, Python and Ruby) of languages, and then lose the ability to discern what other programming languages do to make implementing some subset of algorithms or applications _better_. And by _better_ I mean easier to program in a straightforward fashion.

This is why it is important to keep one toe dipped in a distinct family of languages different from the one you are most accustomed to programming in. Most of my programming work is done in C++ or Java, but I like to extensively tool around with Python and Lisp, just to keep my mind free of being trapped into thinking exclusively in the C++ paradigm. I hope to dabble in Haskell, and maybe go back to a little OCaml programming too, just to keep things more interesting.

IMHO all languages don't eventually tend towards Lisp, but an understanding of functional programming truly improves programming (and oftentimes, frustration and resentment) with C++.

Re:Languages continue to evolve into ... Lisp

[SonOfLilit]

Good programmers aren't "good" because of their knowledge -

They are "good" because of their will to learn.
Because of their appreciation of code beauty.
Because they like to code.

Bad programmers don't care about coding, they see it as some sort of accounting-like job where you have to crunch symbols and get paid for it.

I didn't meet many bad programmers. I am only 18 and am only in my first programming job and programmers here are selected very carefully.

I only met bad programmers at school. They were the people who tried to copy what the teacher said just to get their grade, and didn't think about coding again until the next lesson.

While the good coders were busy trying to understand why what the teacher said works, what else can be done with that knowledge...

While bad programmers looked at the teacher, the book, or the neighbor good programmer (if they were lucky to have one) for answers, good programmers hacked and hacked until they found the solution /themselves/, enjoying the process.

    --------

I bought yesterday a poetry book by Charles Bukowski. It cost me a lot of money, more than I could afford, and I could have bought two great SF books by Orson Scott Card for the same price. Why did I buy that book? I read the first poem.

It started:

*so you want to be a writer?*

if it doesn't come bursting out of you

in spite of everything,

don't do it.

unless it comes unasked out of your

heart and your mind and your mouth

and your gut,

don't do it.

if you have to sit for hours

staring at your computer screen

or hunched over your

typewriter

searching for words,

don't do it.

rest here: http://www.poets.org/viewmedia.php/prmMID/16549

Re:Languages continue to evolve into ... Lisp

[drinkypoo]

I don't think going to the microcode level is necessary. First of all, assembler instructions are [usually, depending on platform] single opcodes, so you're almost there anyway; second, while in the real world people frequently write asm code, there are seldom reasons to enter bytecode directly. There's a place you need to learn that stuff, and it's in compiler design class.

Don't twist what I'm saying out of shape just because you find it amusing. I know a guy who writes dos asm programs in debug but he does it because he's eccentric, not because it's a good idea.

Re:Languages continue to evolve into ... Lisp

[smallpaul]

You're confusing machine code with microcode (check wikipedia). But overall you miss my point which is that you haven't identifed any technique for people to decide how many layers deep of knowledge they should go. Python (topic of this thread) is not written in assembly code, so why should a Python programmer skip C and learn assembler? Or if you say that they should learn both, then why not go all of the way down to microcode or chip design? How are you drawing your arbritary line?

My opinion: programmers should learn one layer lower than whatever they program in day to day. (which is C for Ruby/Python/Java programmers) You need to know the layer below so you can decide when it is appropriate to dip down for more power or performance. Programmers should learn a few more layers below if and only if they are very interested in performance. But if you care a lot about performance, assembly is the wrong place to stop. You should really know some chip design to know about cache misses, predictive branching, cross-core locking etc.

Re:Languages continue to evolve into ... Lisp

[drinkypoo]

But if you care a lot about performance, assembly is the wrong place to stop. You should really know some chip design to know about cache misses, predictive branching, cross-core locking etc.

I just think that every programmer should make it to assembly, because it's the first level at which you're really talking about individual instructions. I don't think most people have to go beyond that level.

The vast majority of code is written in a high level language, after all.

Re:Languages continue to evolve into ... Lisp

[tjwhaynes]

Then they should probably move straight on to OO :)

Most of my programming experience revolves around procedural and functional languages so when I had to pick up Java, I had to finally find out what this OO thingy was. The aspect of OO programming that struck me most strongly was the concept of information hiding - i.e. don't expose anything that you don't want outside influences to have an affect on. And then I realised that I'd pretty much been programming using this concept anyway - hide all the internals and black-box large sections of the code to keep the complexity under control.

OO languages aren't a panacea to programming. They do however encourage certain concepts that programmers should observe more widely.

Cheers,
Toby Haynes

Re:Languages continue to evolve into ... Lisp

[drinkypoo]

The primary benefit of OO as far as I can see is that it promotes code reuse. If I add new methods and/or properties to an object, as long as they are not something I MUST use, then the object continues to work with the old code just fine. That's great! And if everything were object-oriented then we'd be a lot closer to the dream of programming by arranging virtual tinkertoys. Someday this is going to have to be a useful method even for experienced programmers. If the adage is correct about 95% of your optimization being in 5% of the code, then you might as well start out at the highest conceptual level possible, work your way down from there, and then optimize after profiling. Such an approach would really open up programming to more people and provide a gentler learning curve.

One thing I find really amusing is that a lot of people seem to have a hard time explaining what an object is. They tend to start from the wrong end, the technical end, without just talking about the simple definition of "object". Why do people always want to do things backwards?

Re:Languages continue to evolve into ... Lisp

[pelletron]

A know the answers for some of your questions:

1. What is Lisp, and where to find the community web sites

Cliki is a good start:

http://www.cliki.net/index

2. How to locate, download, and install all the major Lisps on Linux, Mac, and Windows

On Debian: apt-get install sbcl

For windows try Lispbox:

http://www.gigamonkeys.com/lispbox/

3. Basic language grammar, including CLOS

The best text is "Practical Common Lisp":

http://www.gigamonkeys.com/book/

4. How to use ASDF (including complex examples)
5. How to fully interface with the operating system, including implementation-specific functions for file i/o, network i/o, command-line arguments, the environment, threads, and more
6. How to package a standalone Lisp application to deliver to customers
7. How to use UFFI

CFFI seens to be a better option:

http://common-lisp.net/project/cffi/

With a good manual:

http://common-lisp.net/project/cffi/manual/index.h tml

8. How to set up a Lisp web application server (modlisp or Araneida or ...)
9. How to use the most common libraries: CLSQL, OpenGL, SDL

Common lisp community is growing, and the OS integration, libraries and documention is improving.

Re:The ministry will be happy

[jimstapleton]

finally, a joke on the right lines...

Python Challenge

[Franio]

I know this is offtopic but does anyone know what happened to the python challenge?

There have been no new levels for a long time.

For those who haven't seen it, the python challenge is a great way to learn python.

Re:Python Challenge

[masklinn]

The python challenge is a great way to learn any language period.

Solve it once, then try to solve it again in any language you try to learn, since it's a very practical "hands on" excercise, it makes discovering and learning a language much more interresting and rewarding.

Re:Python Challenge

[masklinn]

Yep but I think only 2 or 3 of the 33 challenges require the use of python, so it's mostly a non-issue.

Too many pirates riding the snake...

[__aaclcg7560]

Any recommended resources for starting out on Python?

I'm surprised that was never taught at the local community college since the computer department dean started the Unix Administration class this semester with a story about killing a rattle snake at his home in the country. With the end of the shotgun less than two inches away from the snake's head, there wasn't too much left to worry about bees getting into the venom.

Re:Too many pirates riding the snake...

[rakanishu]

Python Tutorial

Dive Into Python is a great online book if you have some programming experience. Buy the dead tree if you like it.

Re:Too many pirates riding the snake...

[oscartheduck]

The O'Reilly "learning python" book is good if you've already got a little (only a tiny amount needed) background in a language. Even shell scripting is good enough. It's pretty dense, so you have to accept that as part and parcel of it, but it's solid.

Otherwise, http://www.ibiblio.org/obp/thinkCSpy/ is as good as many and better than most.

Re:Too many pirates riding the snake...

[Anonymous Coward]

Dive Into Python really helped me to get started. You can buy it as a book, but it's also available for free on the web. Guido's own tutorial is also a good way to get started, as python's creator wrote it himself, and is a pretty good teacher too. Both of these are no big secret, but both are well written and clear, so i'd check them out first before looking for more detailed tutorials. Python's official documentation/website are really so good that looking elsewhere is for the most part unnecessary.

Re:Too many pirates riding the snake...

[All_Star25]

I have been tutoring a 7th or 8th-grader in Python for several months now using the book How to Think Like a Computer Scientist: Learning with Python. It's released for free under the GFDL, and I printed up two copies of it via PrintFu, and it seems to be a pretty good text. However, it's primarily geared towards those with no prior programming experience. Regardless, I learned the language along with him as I tutored, and learned some general programming things from the book. I have no idea to what extent you are familiar with programming, but I was able to look at various things and think things like, "Oh, those are the equivalent of Perl hashes". I found that Python and Perl have a good deal in common when compared to a language like C (caveat: I am most familiar with C and Perl). But, it is indeed free, so it could serve as a simple introduction to Python before you spend money on something like the O'Reilly text.

Re:Too many pirates riding the snake...

[Capsaicin]

If you 'invest' in a book, make sure that it covers at least python 2.2 ... You don't want a 1.6x book which will leave you in the dark about new style classes, scoping rules etc. (ie. if you get the O'Reilly Learning Python book, make sure it is 2nd Ed.)

Having said that I'm going to totally contradict myself by pointing you in the direction of Instant Python. (Actually I'm warning you that this is out of date, it's just such a quick hand up that it's still worth a look at.) More generally a list of on-line python tutorials can be found here.

Re:Too many pirates riding the snake...

[nickdot]

If you want an IDE, use SPE. It is licensed under the GPL, so free and completely cross-platform. It has a lot of features, such as call-tips, auto-completion, uml diagrams (with pdf exports),...

http://pythonide.stani.be/

It greatly helped me when learning python.

Sqlite included!

[imag0]

From TFA:

In keeping with the theme of adding tried and true packages to the standard library, in 2.5 we've added ctypes, ElementTree, hashlib, sqlite3 and wsgiref to the standard library that ships with Python.

That made me sit up and take notice. A pretty nice programming language with built-in functionality to read and write Sqlite databases natively?

Looks like they release a Mac installer, too. Think I'll have to check it out when I get home

Cheers

Re:Sqlite included!

[masklinn]

They put the whole pysqlite library in the stdlib.

(so no, not just some functions of it, the module is now included in Python's stdlib and maintained as such)

Re:Sqlite included!

[imag0]

I understand where you come from. I fought with the Perl DB* stuff years ago. However, in previous cases Guido and crew have followed the "batteries included" philosophy of Python by making sure that modules added in were complete in form as well as function.

That is why I was happy to hear about Sqlite getting added in- it will be a complete interface for creating, dropping, renaming, you name it.

Reserving my cheers until I see the docs, however. Nothing updated at their main Modules site at this time.

Cheers

Re:Sqlite included!

[drinkypoo]

I didn't mean that they only used some functions, but simply that they didn't write those functions or anything, they're just linking a library and exposing the API to Python. This is really no different from having a perl module with a loadable module, except how it's distributed.

I'm sure you can compile it out, but putting the sqlite library into the base distribution is, IMO, stupid. It only makes base larger and more complex. Now granted, I will probably never write anything in Python because I feel that the alternatives suit my needs and control structures based on whitespace are stupid, but I am also unlikely to ever use sqlite no matter what OS I go to. It makes little sense, because it does not save you immense resources to begin with (in most situations) and it does not provide scalability.

Now I know that's just me (well, not just me) but doesn't it make sense to keep the distribution light?

Re:Sqlite included!

[masklinn]

I didn't mean that they only used some functions, but simply that they didn't write those functions or anything, they're just linking a library and exposing the API to Python.

Not exactly, they wrapped the library in a DBAPI2 compliant interface (DBAPI2 would be similar to Perl's DBI, it's an official standard DB interface published in PEP 249: the Python Database API Specification v2.0)

Re:Sqlite included!

[ubernostrum]

I didn't mean that they only used some functions, but simply that they didn't write those functions or anything, they're just linking a library and exposing the API to Python. This is really no different from having a perl module with a loadable module, except how it's distributed.

Nope. It's a module. The entire module is right there for you to use. Not some headers, not a few functions, the whole thing.

I'm sure you can compile it out, but putting the sqlite library into the base distribution is, IMO, stupid. It only makes base larger and more complex.

Except it doesn't. Python the language has not gained native support for SQLite. Nothing having anything to do with SQLite has been "compiled in" to the core language. A module which provides a Python wrapper around the SQLite API is now included among the libraries in the standard Python distribution. If you don't need it, don't ever import it in a program. Simple as that. If you do need it, importing from the pysqlite2 module is always guaranteed to work on Python 2.5, because you no longer have to go download that module from somewhere.

Re:Sqlite included!

[masklinn]

Damn, missed that one.

Now I know that's just me (well, not just me) but doesn't it make sense to keep the distribution light?

No. It makes sense to keep the core language light, but it definitely does not make sense to keep the standard library "light". And it would go against Python's philosophy of being offered "batteries included".

It makes sense to keep standard libraries high-quality, and fast, but stdlibs are great assets of computing languages. Many think that more than a language failed because there was no quality, extensive standard library (Common Lisp comes to mind).

Now extensive third-party repositories such as CPAN or easy-to-install third-party libs such as Ruby's gems do make sense, and are also great assets to a language not to be underestimated, but stdlib functions just give much more (potentially misguided though) confidence about quality, and they create common idioms across the language.

Re:Sqlite included!

[masklinn]

The documentation for Python 2.5 is still in docs.python.org/dev

It's also up to date in the Windows bundle, and the SQLite3 documentation seems fairly good

Re:Sqlite included!

[Just Some Guy]

but I am also unlikely to ever use sqlite no matter what OS I go to. It makes little sense, because it does not save you immense resources to begin with (in most situations) and it does not provide scalability.

I have to disagree with you there. I can think of 1,001 reasons why it'd be nice to have a lightweight, fast (!) SQL database available on the local machine. It seems like almost every nontrivial application implements its own ad-hoc database: email programs store status flags, MP3 players store metadata, browsers store cookies, text editors store history, etc. It makes sense to refactor that code into one reusable, highly optimized storage backend. Berkeley DB meets those requirements, but I'd have to say that SQLite is infinitely easier (for me) to code against.

Again, SQLite isn't meant to replace your enterprise terrabyte cluster. It's meant as a quick, easy-to-use way to store machine-local information.

Re:Sqlite included!

[Schraegstrichpunkt]

I will probably never write anything in Python because I feel that the alternatives suit my needs and control structures based on whitespace are stupid,

Wow, there are people who are still hung up on that? Care to explain (or provide an URL reference that explains) why Python's use of whitespace for syntax is so "stupid" that it's not worth using the language?

Re:Sqlite included!

[bulliver]

control structures based on whitespace are stupid,

Do you have any _real_ arguments to back that up other than the fact that you don't like it? I think it's brilliant. It forces you to write readable code, and besides, I (and anyone else if they're smart) would indent exactly the same way anyway, no matter the language. Being able to give up lame curly braces and moronic 'end' keywords is smart, not stupid.

If you actually took the time to write something beyond absolute triviality in Python you would know this...

Re:Sqlite included!

[drinkypoo]

Wow, there are people who are still hung up on that? Care to explain (or provide an URL reference that explains) why Python's use of whitespace for syntax is so "stupid" that it's not worth using the language?

It's very simple: I've had a ton of situations in which my whitespace was demolished by some well-meaning editor or such; it's an entirely commonplace occurrence. As such, designing a language around whitespace is a clueless manouver. We have symbols for grouping in mathematics and even verbal structures for grouping in language because they are useful.

Re:Sqlite included!

[Schraegstrichpunkt]

Like what editor? Even if your editor converts tabs to spaces or something, Python's parser can handle that just fine. All it does it look at the indentation of the current line relative to the indentation of previous lines.

If you're using an editor that mangles whitespace to such an extent that Python's parser can't handle it, and then submitting the results to some source code repository, you're creating a maintenance headache anyway.

Unless you're going to provide specific examples, it sounds more like a problem of your using a chisel as a screwdriver than a legitimate problem with the language.

Re:Sqlite included!

[drinkypoo]

My point is that if it doesn't work without formatting then if your formatting is mangled, it stops working. As long as I turn off the features for crap like smart quotes and dashes, it doesn't matter if I edit a perl script (just as an example) in Microsoft Word, or in edlin; it will still work. It doesn't matter if I somehow lose all my carriage returns, although the readability will be nil - it will still work.

Re:Sqlite included!

[Schraegstrichpunkt]

So you're saying that programming languages should be designed around Microsoft Word? And for the record, I see no reason why you couldn't edit Python code using MS Word. Even if you couldn't, you could just install gvim for Win32 or just dump it into a folder and run it from there (if you don't have admin access to the machine), or use Notepad, or whatever.

You're grasping at straws. So far, you've given me all sorts of reasons why whitespace significance could hypothetically be a problem, but no examples of how it actually is a meaningful problem in real life. I cringed at the thought of Python's whitespace significance when I first used it. I got over it in about a week, because it just isn't a problem.

I have found exactly one scenario where the whitespace handling is a problem: in mod_python Python Server Pages (basically inline-able Python code, like you can do with PHP). Even there, it worked, but I just didn't trust it to be maintainable. On the other hand, most people consider inlining code that way to be bad practice anyway. Furthermore, if you use the more elaborate Spyce intead of mod_python's built-in methanism, you can use braces around blocks anyway.

The bottom line is that I've been using Python, often in a professional capacity, for about 5 years, and the "whitespace issue" has just never been a serious problem, and has been quite helpful for when I've had to debug other people's code. You, so far, haven't convinced me that it can be a real problem, because you haven't given me any real examples of where Python was the wrong choice of language due to the way it handles whitespace.

Re:Sqlite included!

[drinkypoo]

I have found exactly one scenario where the whitespace handling is a problem: in mod_python Python Server Pages (basically inline-able Python code, like you can do with PHP). Even there, it worked, but I just didn't trust it to be maintainable.

so what you're saying is that YOU yourself found a situation where it's a problem (you didn't trust it to be maintainable, which is precisely my complaint) and you're giving me shit for saying it could be a problem without giving an example?

in English, we refer to this as "hypocrisy". HTH, HAND.

Re:Sqlite included!

[Schraegstrichpunkt]

...

I found one case where the whitespace was a hindrance, and it was only because I was trying to use Python directly as a templating language, which is dumb anyway. Even then, it still worked.

This was the problem: I effectively had code that did this:

if ([condition]) {
[bunch of lines of HTML]
} else {
[bunch of more lines of HTML]
}

I was worried about the trailing brace, which in Python, was supposed to be either a line of code, or a comment character, indented at the appropriate location. Even in another language, it was a stupid design. It's hard to match a single closing brace in the middle of nowhere with its corresponding opening brace, unless you have a good editor, which you have already said won't be the case. In Python it was slightly worse, because you'd end up with comment characters that had a particular significance, but it's not like I should have been doing that anyway.

Let's recap: the "whitespace issue" has just never been a serious problem, and has been quite helpful for when I've had to debug other people's code. You, so far, haven't convinced me that it can be a real problem, because you haven't given me any real examples of where Python was the wrong choice of language due to the way it handles whitespace. I repeat: The whitespace issue itself has never been a serious enough problem to render Python less suitable than some other language for any job I've worked on, and it has sometimes been beneficial..

So far, the only thing you have established (well, I was the one to establish it) is that control structures based on whitespace are, in at least one case, suboptimal. That's a far cry from your generalization:

control structures based on whitespace are stupid

On the plus side, you haven't called me homosexual or a Nazi or something like that yet, which is quite a surprise, given that this is Slashdot. :)

Re:Sqlite included!

[drinkypoo]

On the plus side, you haven't called me homosexual or a Nazi or something like that yet, which is quite a surprise, given that this is Slashdot. :)

I calls 'em as I sees 'em, and you haven't given any signs of homosexuality or being a member of the third reich yet :P

And for the record, only the latter is worthy of notice IMO. You can be as gay as you want and it won't affect my life. :P

Re:Sqlite included!

[Schraegstrichpunkt]

And for the record, only the latter is worthy of notice IMO. You can be as gay as you want and it won't affect my life. :P

Agreed. But then again, we're not 12-year-olds.

In line conditionals, FINALLY

[gd2shoe]

Although not as elegant as:

cout << ( a==b ? "first option" : "second option" )

It is good to finally see inline conditions such as:

print ( "first option" if a==b else "second option" )

This just makes me happy! ;-)

Re:In line conditionals, FINALLY

[xquark]

I believe this new inline conditional is just plain ugly!

When developing computer language syntax, natural language
imitation should not be the priority - also being different
for the sake of being different is so very early 90s.

Re:In line conditionals, FINALLY

[valwig]

It's not as elegant as Ruby's puts a == b ? 'first option' : 'second option' either.

Re:In line conditionals, FINALLY

[ShecoDu]

You could've been happy with the previous versions of python too, I think of this new feature as syntax candy.

For those who didn't know, you can do this in python, short circuit logic:

print a==b and "first option" or "second option"

Re:In line conditionals, FINALLY

[grayrest]

Note that this works ONLY if "first option" is known to evaluate to True.

Re:In line conditionals, FINALLY

[tuffy]

I like the syntax. I believe the idea was to put the common case first and the exceptional case past the conditional. Something like:

>>> "%d widgets" % (i) if i != 1 else "1 widget"

Re:In line conditionals, FINALLY

[Anonymous Coward]

Unless "first option" evaluated to False. So the general-purpose version of this is the hideous:

print (a==b and ["first option"] or ["second option"])[0]

if they're constant strings, you of course don't need this, but if they're expressions that might evaluate to False, you do need to do this.

For example, if you have a function:
def foo(a, b, x, y):
      print a==b and x or y

and you don't know that x will never be False (or 0), then you have to write it as:
def foo(a, b, x, y):
      print (a==b and [x] or [y])[0]

The list [x] can never be False, so this always works. Given this subtle error, I much prefer the new syntax.

Re:In line conditionals, FINALLY

[Pope Raymond Lama]

Indeed, I got puzzled about the choice for this syntax.

They explain why, whether one agrees or not with it, in this part of the release notes.

In short, there was some discussion on the mailing lists about whether the syntax should be, and no clear winner could be appointed. Then, the BDFL figured out that whenever conditional expressions are used, one of the values is usually the norm and the other the exception, thus, putting the normal value at the beggning of the expression made it for code readability.

From the URL above:
"""\
This syntax may seem strange and backwards; why does the condition go in the middle of the expression, and not in the front as in C's c ? x : y? The decision was checked by applying the new syntax to the modules in the standard library and seeing how the resulting code read. In many cases where a conditional expression is used, one value seems to be the 'common case' and one value is an 'exceptional case', used only on rarer occasions when the condition isn't met. The conditional syntax makes this pattern a bit more obvious:
contents = ((doc + '\n') if doc else '')
"""

Re:In line conditionals, FINALLY

[the_wesman]

"When developing computer language syntax, natural language imitation should not be the priority"

I could care less about inline if statements - I assume that those are only for people who either are the dangerous kind of lazy, like to write hard-to-read code or don't use emacs

in response to your 'natural language' comment, I'm hoping that isn't the reason that this was done because the if/else syntax we already have imitates natural language.

If she is hot, hit on her. else, if she is not hot and I'm drunk hit on her. else go home.

looks like natural language to me.

Re:In line conditionals, FINALLY

[ramunasg]

If you want real elegancy then use expression orientated language (this is general note, I don't know Ruby).

Re:In line conditionals, FINALLY

[xTantrum]

I have to agree, i don't see why GVR couldn't have just fashioned it the same as the ternery operator in C. I love python not only for its RAD ability but the syntax: clear, terse and indented. Since they added decorators i've been getting more and more irritated with it. keep it clean, keep it concise. WHY BE DIFFERENT FOR THE SAKE OF BEING DIFFERENT!

Re:In line conditionals, FINALLY

[Haeleth]

If she is hot, hit on her. else, if she is not hot and I'm drunk hit on her. else go home.

looks like natural language to me.

Looks rather unnatural to me. The usual way to say it would be more like "Hit on her if she's hot or you're drunk, else go home."

Which, I realised as I typed it, is exactly how Python's new inline conditional syntax works. Neat.

Re:In line conditionals, FINALLY

[Waffle Iron]

print a==b and "first option" or "second option"

IMHO, the need to use that idiom was the single worst failing of Python up until now. I've been bitten by real-world bugs where the middle term was accidentally "false" more times than I care to remember. In contrast, I can't remember a single time that I've had a bug caused by the possibility that every Python critic obsesses over: inconsistent whitespace.

Re:In line conditionals, FINALLY

[Anonymous Brave Guy]

I could care less about inline if statements - I assume that those are only for people who either are the dangerous kind of lazy, like to write hard-to-read code or don't use emacs

Or who just understand the difference between expressions and statements/command/whatever your language calls them.

Re:In line conditionals, FINALLY

[Anonymous Brave Guy]

Ironically, your example is exactly why I don't like this syntax much. I read that as

"%d widgets" % ( (i) if i != 1 else "1 widget" )

Re:In line conditionals, FINALLY

[Reverend528]

With inline conditions, my one-liner Y-Combinator is now useful!

Y=lambda x:(lambda p:x(lambda a:p(p)(a)))(lambda p:x(lambda a:p(p)(a)))
F=lambda x:(lambda y:1 if y<2 else y*x(y-1))
Y(F)(5) # correctly returns 120!

Re:In line conditionals, FINALLY

[fforw]

Decorators are good feature to have and the @ syntax

@decorator(arg1,arg2)
def func():
...
...
...

is by far more readable than the python2.3 equivalent.

def func():
...
...
...
func=decorator(func, arg1, arg2)

python always preferred language constructs close to natural language (and thankfully only in so far as that really works well). So

foo if condition else bar

fits in much better than

condition ? foo : bar

Re:In line conditionals, FINALLY

[srwalter]

I more or less disagree with the existence of the ternary operator. Sure, there are some cases where it's handy (the one you list seems innocuous enough), but when you start chaining them, things get evil very quickly. The primary reason GVR chose the syntax he did is because in reviewing the cases were a ternary were useful, there was a very common case, and a less common case. By putting the common case first, it is more clearly stated in the code.

Additionally, the syntax is similar (but not identical) to perl's expression if (condition); however I do not believe perl lets you express an else clause in that case.

Woot -- conditional expressions!

[SilentTristero]

Finally! Of course they have the most bass-ackward possible syntax, but at least they're there.

Re:Woot -- conditional expressions!

[artlogic]

I actually find the python syntax easier to read - but maybe not perfect... I think C/C++ syntax is confusing because the actual operator (?) appears AFTER the comparison (e.g. a==b ? "first option" : "second option").

Python makes it a little easier to read by not only keeping the testing operator the same (i.e. no ? and if, just if), but also by placing the operator BEFORE the comparison, which is a little closer to english, as well as being more consistent with the rest of the language (e.g. "first option" if a==b else "second option").

My only complaint is the movement of the first option to the start of the statement, though I can see how this reads even cleaner, it's not consistent... I would have preferred: if a==b "first option" else "second option"

I suppose that would have been too easy, though.

Re:Woot -- conditional expressions!

[masklinn]

I suppose that would have been too easy, though.

It's not about "too easy", it was rejected after lenghy discussions on python-dev. You can read explanations, modivations, and get links to quite a lot of discussions on the PEP 308 - Conditional Expressions page.

Whatever your thought on the result is, don't think for a second that the decision of this was easy, or a side-note on a receipt.

Re:Woot -- conditional expressions!

[Gospodin]

I don't feel particularly strongly about it, but it seems to me that the Python syntax gets unwieldy more rapidly when you have nested conditionals, like so:

"first option" if a==b else ("second option" if a==c else "third option")

...versus...

a==b ? "first option" : (a==c ? "second option" : "third option")

My other concern is that it's immediately obvious that a C conditional is just that, but the Python syntax makes it a little obscure:

s = "first option" if a==b else "second option";

...versus...

s = (a==b) ? "first option" : "second option";

Isn't it a little tempting to read the Python version as s = "first option"? Might be just me, though. My knowledge of Python is somewhere between jack and s**t, so maybe it just makes sense there.

Re:Woot -- conditional expressions!

[artlogic]

"Whatever your thought on the result is, don't think for a second that the decision of this was easy, or a side-note on a receipt."

I meant no disrespect - I use python on a daily basis, and I owe a debt of gratitude to all the developers, and especially Guido. I certainly had no idea the ammount of discussion that had gone into deciding the syntax. It's interesting to see that a form similar to the one I mentioned was high in the running.

I'm just glad it didn't end up being C syntax.

Re:Woot -- conditional expressions!

[Dragonslicer]

Isn't it a little tempting to read the Python version as s = "first option"? Might be just me, though.

It's not just you. It's the same reason I don't like Perl's $foo = "bar" if $blah syntax. It reads as Set $foo to "bar"... Oh wait, never mind, don't do what I just told you to do. I would personally prefer the condition-true-false order, since it matches the full if-else structure. I don't really mind the ?: symbols, but I wouldn't lose any sleep if a language picked different symbols.

Re:Woot -- conditional expressions!

[afd8856]

http://docs.python.org/dev/whatsnew/pep-308.html recommends inclosing the expression in parentheses. Also, deeply nested expressions are not encouraged in the python world.

Re:Woot -- conditional expressions!

[Gospodin]

http://docs.python.org/dev/whatsnew/pep-308.html recommends inclosing the expression in parentheses.

$var = $expr1 if $case else $expr2;

The first point in that URL is that the uncommon case should be de-emphasized and the code should be read as "$var = $expr1" (unless $case, and then "$var = $expr2"). The second point is that this can be confusing, so here's how to re-emphasize the conditional. I guess I agree, but I'm not sure how this strengthens the case for the syntax.

I guess I just don't see the point of coming up with a new syntax here. Is the ternary ?: problematic for some reason?

Re:Woot -- conditional expressions!

[afd8856]

In my C programming days I could never remember what the syntax for the ternary operator does. I guess that's why I'm programming python for a living and not C.

Re:OMG

[Ekarderif]

En taro Adun.

Finally!

[artlogic]

This release is worth the upgrade just for the new try, except, else, finally syntax. Never could figure out why Guido was confused by it...

Re:Finally!

[masklinn]

The WITH statement is much more interresting, in my eyes. the try/except/finally is merely the long-awaited correction of an annoying quirk

Re:Finally!

[pthisis]

The WITH statement is much more interresting

IMO, "with" is a gross hack that forces the programmer to repeat scope information. The proper solution to the problems it tries to solve is to mandate (the current CPython actual behavior) ref-counting semantics from the GC, or at least force local variable collection at function return time. Function definitions already provide scope; with provides a duplicate (but more fragile) way for the programmer to indicate variable lifespans.

Re:Finally!

[masklinn]

The point of `with` is not to repeat scope information (and I fail to see how it does too, it just creates a scope within a context generated by a contextmanager that you may or may not have written). It's to provide automated management by the contextmanager, akin to what Ruby does throughout the language and the stdlib: ensure that you don't forget to release a resource, ensure that you don't forget to close a file, ensure that you don't forget to release a lock, ...

You rarely want to create a full frame, and much less create a named function, for that kind of job.

And you can make you contextmanager arbitrarily complex, so that they do heavy lifting and just give you the easy-to-work-with part (think DB transaction, create a DB contextmanager, manipulate your data, at the end of the with block you transaction will be cleanly committed or rollbacked, no hassle and no chance for an error in manually handling the transaction yourself)

Re:Finally!

[pthisis]

It's to provide automated management by the contextmanager, akin to what Ruby does throughout the language and the stdlib: ensure that you don't forget to release a resource, ensure that you don't forget to close a file, ensure that you don't forget to release a lock

Actually upon further reflection the "with" statement is nice in the case of database transactions where finalization is different in the face of exceptions from without.

But a lot of the PEP deals with things that are non-issues in current CPython:

def foo():
  lock = threading.Lock(...)
  # do stuff here that needs the lock

can easily unlock automatically as soon as you return from foo, and more complex things like:

for fname in [ "foo", "bar", "baz" ]:
  for line in open(fname, "r"):
...

will close each file at the end of its pass through the loop without needing an intermediate name bound to the open call in a with statement a la

for fname in [ "foo", "bar", "baz" ]:
    with open(fname, "r") as this_file:
        for line in this_file:
...

In these cases, "with" just buys implementation flexibility so that things like Jython can be half-assed about GC and run it at random times, instead of giving the programmer deterministic guarantees on when objects are collected.

Indeed, much of the advocacy on Python lists about "with" has been that it allows resource finalization on looser GC implementations, without anyone willing to admit that it requires additional programmer care and makes things more brittle than simply requiring the GC to act in a predictable manner.

So I withdraw my blanket objection to "with", but maintain that keeping deterministic GC is a big boon to the programmer and should be made an explicit language guarantee and not an implementation detail (newer Python implementations like pypy are already using less programmer-friendly GCs by default since they aren't required to have more useful GC semantics).

Re:Finally!

[grammar fascist]

In these cases, "with" just buys implementation flexibility so that things like Jython can be half-assed about GC and run it at random times, instead of giving the programmer deterministic guarantees on when objects are collected.

With all due respect, you're totally missing the point of GC.

In a language with GC, objects are assumed to exist after you create them indefinitely. This is a whole lot like math - if you define something, you can't undefine it. GC simply makes that theoretical construct work in languages that happen to run on finite state machines (our computers) by sweeping up objects that aren't referred to any longer.

If you choose to define a function that's run when a resource-representing object is collected, good for you, it might catch a resource allocation bug, it might not. Resource deallocation by deterministic destruction is fundamentally and theoretically incompatible with indefinite object lifetimes. "With," on the other hand, is compatible in every way.

Re:Finally!

[pthisis]

With all due respect, you're totally missing the point of GC.

No, you are. Not all the garbage collection world is mark/sweep.

The point of GC is to free the programmer from concerns about explicit resource deallocation. There are many possible approaches to that, all with different semantics.

In a language with GC, objects are assumed to exist after you create them indefinitely

In _some_ languages with GC, objects are assumed to exist indefinitely. In some, there are time-bounds on collection. In some, there are ways to force immediate collection--objects may not deallocate at any specific time when the GC runs, but there's some sort of call that forces it to collect garbage "right now". In some languages, the rules for when objects get collected are more deterministic.

Claiming that all GCs lack rules about when objects are deallocated is simply wrong.

(also, GC is not necessarily about objects--all kinds of resources can be GC'd)

Resource deallocation by deterministic destruction is fundamentally and theoretically incompatible with indefinite object lifetimes.

Yes. But not all methods of GC limit their model to indefinite object lifetimes. Those that do _not_ have such a limitation are far more useful to the programmer than those that do--almost all aspects of programming are made easier if the system behaves deterministically rather than arbitrarily.

The tension is a speed tradeoff that is particularly visible in certain shared-object systems (low-level multithreaded languages can see a big speed penalty from deterministic object deallocation). None of those arguments apply particularly well to Python, which semantically _does_ guarantee enough synchronization in other areas that the speed cost of deterministic GC is nearly zero.

Resource deallocation by deterministic destruction is fundamentally and theoretically incompatible with indefinite object lifetimes. "With," on the other hand, is compatible in every way.

Yes, that's exactly the (bogus) argument. There are 2 alternatives:
1. Allow nondeterministic GC, and force the programmer to use something like "with" to compensate--in other words, force explicit resource management on top of your garbage collection scheme; or
2. Mandate deterministic GC rules in the language definition.

The standard Python implementation already does deterministic GC, and mandating such behavior for alternative Python implementations would make the language much more programmer-friendly than requiring explicit resource management on the programmer's part.

It makes far more sense to me to make alternative implementations somewhat more difficult than to make them easier at the cost of making them behave differently, and making code less portable between them--especially when the different behaviour is also far less useful to the programmer.

Learning python

[gd2shoe]

Their server seems to be taking a beating, so I can't get the exact URL. They have a decent tutorial. Just go to python.org-> documentation-> tutorial. If you are programming savy, you can just skim it, slowing down for unusual stuff.

The sys module has some interesting things in it that you might want access to early on. for example:
sys.argv
sys.stdin
sys.stdout
sys.stderr

Re:OMG

[stoolpigeon]

My life for Aiur!

A Gem

[pythiane]

Python, the brightest programming gem. ;-)

Hey!

[gd2shoe]

Hey!

This is a time and place for us python nut-cases. Ruby wackos can go release thier own new versions...

(Just messing with you, but your comment was a cheep shot)

Assembly - C - Python

[gd2shoe]

It's also nice when dealing with a language like python to know some of what c/c++ is doing behind the scenes. I'm certainly no expert in the python c api, but what little I know helps me keep things in perspective.

Re:The writer, I believe, is not religious

[ltbarcly]

Why did you post this? Why point out there religion?

try/except/else/finally

[ttfkam]

Would someone be so kind as to explain this construct for me?

try:
    block-1 ...
except Exception1:
    handler-1 ...
except Exception2:
    handler-2 ...
else:
    else-block
finally:
    final-block

Coming from Java and C++ land, I'm familiar with the idea of

try {} catch (...) {} finally {}

What is the point of else? What does it get you that you didn't have just as easily without it? If no exception is thrown, run it? Isn't that what the content in the try section is for? Will someone provide a use case for this for me please?

Re:try/except/else/finally

[artlogic]

You would include logic in the else to be executed in the case that no exceptions occur, that is:

else:
    print "no exceptions occured!"

Everything else is the same as Java/C++.

Re:try/except/else/finally

[grayrest]

try:
    f = open('number.txt','r').read()
    x = int(f.read()) #convert the contents of a file to an int
except IOError:
    print "number.txt wasn't found"
except ValueError:
    print "contents weren't a number"
else:
    print "Unknown Error"
finally:
    f.close()

In previous releases this didn't entirely work as expected. I believe the wart was that the finally clause didn't make it if there was an exception in the except clauses. It's a bugfix.

Re:try/except/else/finally

[masklinn]

The code that you run after the part you may want to protect could thrown an exception that you wouldn't want to catch in your except handlers.

The else clause gives you a way to run it without the risk of shadowing/accidentaly catching these exceptions.

Re:try/except/else/finally

[masklinn]

I believe the wart was that the finally clause didn't make it if there was an exception in the except clauses. It's a bugfix.

Wrong. In the previous versions there were two versions of the try clause: try/except/else and try/finally. You couldn't use both except and finally in a single try clause (the idiom was usually to wrap your try/except in a try/finally). This was a wart indeed in the eyes of many people (including me), but it is not a bugfix.

Re:try/except/else/finally

[tuffy]

The "else" block is run when the try/except block returns normally and without a continue, break or return statement. Everything in the else block isn't covered by the try/except, which helps one avoid accidentally catching exceptions you're not looking for.

Re:try/except/else/finally

[Ishi]

The point is to limit the scope of the try block and to only catch exceptions on code that you expect to throw things in. Here's an example:

try:
        foo = someDict[key]
except KeyError:
        return None
else:
        return myCrazyFunction(foo)

If myCrazyFunction throws a KeyError you probably want it propagated upwards, not caught.

Re:try/except/else/finally

[artlogic]

Actually:

except IOError: ...
except:
        print "unknown error"
else:
        print "an error didn't occur"

is a little more correct - you can blanket catch exceptions with except on it's own - where else is really meant to take care of actions you want to do if no exceptions were caught.

Re:try/except/else/finally

[truedfx]

So basically,

try:
a
except:
b
else:
c

is the same as

try:
rethrow = False
a
rethrow = True
c
except:
if rethrow:
raise
b

except without an extra variable? (I'm not sure how to make /. respect the spacing, sorry for that.)

Re:try/except/else/finally

[Anonymous Coward]

How is this any different than:


try:
    foo = someDict[key]
except KeyError:
    return None
return myCrazyFunction(foo)

Re:try/except/else/finally

[cosminn]

That's just silly tho. This would have the same effect:

try:
    do stuff that can throw exception
    print 'no exception'
except:
    print 'oops'

Re:try/except/else/finally

[artlogic]

More like this:

try:
    error = false
    a
except:
    error = true
    b

if not error:
    c

Re:try/except/else/finally

[cosminn]

        try:
                f = open('number.txt','r').read()
                x = int(f.read()) #convert the contents of a file to an int
        except IOError:
                print "number.txt wasn't found"
        except ValueError:
                print "contents weren't a number"
        except:
                print "Unknown Error"
        finally:
                f.close()

This works exactly as the "new" way.

Re:try/except/else/finally

[cosminn]

try:
                foo = someDict[key]
except KeyError:
                return None
return myCrazyFunction(foo)

Wouldn't this do the same thing tho?

Re:try/except/else/finally

[artlogic]

The difference... which I keep not mentioning, doh... is in the case that "print 'no exception'" throws an exception. In that particular case, your code would proceed into the exception block, where my code would bubble up to the next error handler.

Re:try/except/else/finally

[truedfx]

So c gets executed after any "finally" clause?

Re:try/except/else/finally

[artlogic]

It would in this contrived example - but if you had a finally block it would not. That is, the finally block would be executed before return myCrazyFunction(foo) in your example, rather than after it, if you used an else.

Re:try/except/else/finally

[artlogic]

Sorry - not the best example on my part - c (else) is executed before the finally clause, but after the try clause.

Re:try/except/else/finally

[truedfx]

I think that's what my example did, but I'm very confused, so I'm probably wrong on that. Thanks, I think I got it now.

Re:try/except/else/finally

[i_finally_got_an_acc]

Maybe I'm redundant at this point, but the else-block is what is run if something in the try block throws an exception that is not of type Exception1 or Exception2. It's just the generic fallback error handling. I guess it would be like catching Exception in java, after attempting to catch some more specialized exception types.

Then the final-block is run no matter what.

Re:try/except/else/finally

[tdelaney]

Nope - the else block is executed if no exception is thrown in the try block. If an exception is thrown from the try block that is not handled by an except block, it propagates up the stack (executing any finally blocks) until it is caught.

The advantage of the else block (as others have pointed out) is that what is included in it is not covered by the except blocks, but is covered by the finally block. So if an exception is thrown from the else block the finally block is executed and then the exception propagates up the stack.

The else block existed on the try/except/else and try/else/finally constructs previously. Obviously it only really serves a purpose with a finally block.

Note: up the stack does not just mean stack frames - the python stack includes try/except/else/finally constructs, so propagating up the stack will execute finally blocks on nested try/finally constructs.

BTW - the "catch-all" behaviour is obtained by using a bare except:, and is highly recommended against. It will catch things that should normally be passed through, such as KeyboardException and SystemExit.

Re:try/except/else/finally

[i_finally_got_an_acc]

Boy, do I look dumb! Guess I misread the explanation earlier.

Also, I think that this syntax makes no sense now that I know how it actually works.

Sorry about the misinformation everyone. Oh well, it's Slashdot. When in Rome, right? har har har.

Re:try/except/else/finally

[firewrought]

Coming from Java and C++ land, I'm familiar with the idea of try {} catch (...) {} finally {}. What is the point of else?

Other responses have explained it better than I can, but here's a similar construct in Java:

bool handleException = true; try { // block-1 stuff handleException = false; // else-block stuff } catch (Exception1 ex) { if (handleException) { // handler-1 stuff } else { throw ex; } } catch (Exception2 ex) { if (handleException) { // handler-2 stuff } else { throw ex; } } finally { // final-block }

Re:try/except/else/finally

[swillden]

It woulnd't do the same thing in a couple of cases:

1. If the except block didn't return or throw; or
2. If there was a finally block in addition to the except and else blocks.

Re:try/except/else/finally

[Lobais]

You could put that in the last line of the tryblock too.

Re:try/except/else/finally

[meowsqueak]

I'm interested to know what would happen if you 'return' from the ELSE block, but have code in the FINALLY block.

foo = 42
try:
    print "a"
except:
    print "b"
else:
    print "c"
    return foo
finally:
    foo = 13
    print "d"

What would this actually do? Would it save the value of 'foo' as 42, run the FINALLY block, and then return the saved value? Or would it actually modify the value to return, hence return 13? Or would it just crash?

Re:try/except/else/finally

[archeopterix]

I'm interested to know what would happen if you 'return' from the ELSE block, but have code in the FINALLY block.

See The return statement First, the exception passed to 'return' is evaluated (in your example to 42), then the 'finally' block is executed. So, this function prints "a","c","d" and returns 42.

Dive Into Python

[grayrest]

http://www.diveintopython.org/

For those that know how to program. Accept no substitutes.

Re:Dive Into Python

[Millennium]

Dive Into Python is great, but it has the problem of being old. So old, in fact, that so far I haven't found anything from it that doesn't work perfectly in Jython. That might not seem like much, until you realize that Jython is still not quite at the Python 2.2 stage yet: more than three years behind.

Not that I dislike Jython. Quite the contrary: I use it more than I use cPython, for a variety of reasons. But its development is going slowly enough that it's making me want to brush up on my Java so I could help out.

Re:Dive Into Python

[chris_mahan]

Don't expect too much out of jython since the main dev was hire by ms to work on ironpython.

Re:Dive Into Python

[mixmasta]

not that old ... it talked me into start using list comprehensions finally.

Python is not anything like Lisp

[Anonymous Coward]

Ugh, where did this meme come from?

I think Paul Graham looked at Python 1.0, saw that it had a "lambda" in there somewhere, and had a little orgasm in his pants. Then he wrote an article about it and the Python fanatics didn't realize what he meant was, "compared to C++, COBOL, and FORTRAN, Python is a lot like Lisp". So every now and then, somebody comes along and compares Python to Lisp (favorably or unfavorably).

Python rarely uses "lambda" these days, I think Guido has "deprecated" that kind of usage pattern, and Python doesn't have MACROS, which are kinda what makes Lisp. And of course, no s-expressions (and the whole whitespace thing makes Python even HARDER to parse than other langauges).

Now Ruby has the anonymous function thing ("blocks") which lets you do some of the same things you can do in Lisp with Macros, and Ruby generally "feels" more like Lisp to me (but it's no replacement for Lisp either). And Perl, even though the syntax is awful, is even *more* like Lisp, if you can believe it (you can do "blocks" in Perl as well for instance, though I hardly ever see it, and you can "roll your own" objects as in Lisp).

So please, let's stop pretending that Python is "Lisp" in any way shape size or form.

Re:Python is not anything like Lisp

[masklinn]

Now Ruby has the anonymous function thing ("blocks") which lets you do some of the same things you can do in Lisp with Macros

Duh, looks like you never used macros, blocks don't let you do anything macros let you do, they let you do what lambdas (anonymous functions) let you do in lisp.

These is no relation at all between blocks and macros, macros are tools to generate (transform) code. The only think that could be linked to macros in Ruby are class_eval and instance_eval-type methods.

Now please shut up, you don't even being to grasp what macros are or what they're used for, so don't talk about them.

Re:Python is not anything like Lisp

[masklinn]

So what? There is no mention of macros in here, and no mention of the relation between macros and lambdas (rightfully so, because there is none).

Just be glad they're here.

[gd2shoe]

Or: if a==b then "first option" else "second option"

Although that would mean adding a new keyword.
Still, I'll take what I can get.

Easy transition from Python to Ruby?

[Anonymous Coward]

Does anyone knows a good tutorial for application migration from Python to Ruby?

Re:Easy transition from Python to Ruby?

[masklinn]

Migrating from Python to Ruby is trivial, they're 95% identical. Some idioms are different such as Ruby's use of anonymous functions (called blocks) and different ways of metaprogramming (plus the fact that Ruby uses metaprogrammatic abilities much more often than Python), but the difference between them is far smaller than some people make it to be.

Re:Easy transition from Python to Ruby?

[masklinn]

Oh yeah, the biggest hurdle when transitioning from Python to Ruby is the awfully shitty documentation by the way, and the fact that Ruby's stdlib is fairly anemic compared to Python's (third party packages and the ease of installing them via gem somewhat eases the pain though)

Re:Easy transition from Python to Ruby?

[ubernostrum]

Migrating from Python to Ruby is trivial, they're 95% identical. Some idioms are different such as Ruby's use of anonymous functions (called blocks) and different ways of metaprogramming (plus the fact that Ruby uses metaprogrammatic abilities much more often than Python), but the difference between them is far smaller than some people make it to be.

If I moderated, I'd mod this up :)

Seriously, the idioms and conventions of programming in Python and Ruby are the largest differences, not the actual languages themselves:

• Ruby programmers, on average, seem more likely to crack a class open and add new things to it, where Python programmers generally prefer to subclass and do what they need in there.
• Ruby programmers, on average, seem more likely to build domain-specific languages to solve problems, where Python programmers generally prefer other routes (though which route they take will vary depending on the problem).

Et cetera, et cetera. Ruby folks are also big on the arbitrary anonymous blocks, which Python doesn't have, but I've yet to run into a problem I can't solve with a named function, and a lot of the time I end up with cleaner and more understandable code because of it. Which, really, I think is the biggest cultural difference: given a situation where all other things are equal, Ruby focuses on expressiveness (an inherited "there's more than one way to do it" from the Perl in its genes), and Python focuses on clarity and readability.

WxPython

[nih]

anyone using wxpython will need to upgrade to wxpython for python 2.5

http://www.wxpython.org/download.php

as soon as i'd installed python 2.5 all my app died, took me a few mins
to realise that py2.5 breaks wxpython for py2.4, and some tk demo's ran:)

Re:WxPython

[nih]

just noticed that pywin32 (Python for Windows extensions) is now broke as well get pywin32-209.1.win32-py2.5.exe from: http://sourceforge.net/project/showfiles.php?group _id=78018

Re:WxPython

[Phoe6]

Anyone using pyWin32 sould upgrade to 2.5 version as well. Otherwise you will have problems.

Re:What?

[cortana]

Ouch ;)

Learning Python... add pyrepl to the interpreter.

[zapadoo]

Tip #1: I highly recommend adding pyrepl to your Python environment. It enhances functionality of the interactive interpreter such that you can easily edit multi-line code snippets. Forward and back (control-n, control-p) through history. Control-r (then start typing) to find something back in history. Very useful. http://codespeak.net/pyrepl/

Tip #2: Avail yourself of the help() function in the interpreter. help(SomeObjectOrFunction) i.e. help(open) will return the docstrings associated; help(SomeModule) i.e. import sha; help(sha) will return the module docs.

Re:Learning Python... add pyrepl to the interprete

[zapadoo]

PS: For those that don't read docs or code, following installation of pyrepl, to launch a pyrepl-enhanced interpreter, at the command prompt: pythoni

Re:The writer, I believe, is not religious

[swimmar132]

Huh? The creator of Ruby, Matz, over in Japan, is Mormon?

Backwards compatibility?

[Thorsten Timberlake]

What I'd like to know is: Are there any breaking changes? Will 2.4 modules and code still work?

Re:Backwards compatibility?

[zapadoo]

AMK puts out a "What's New in Python X.X" doc for each release, and within the doc is a "Porting to..." section that highlights any issues. From what I've seen, the broadest "gotya" likely to hit folks are those with non-ascii characters in their names who have attribution in python code files. ASCII is now the default encoding for modules (easily overridden) and unlike before, non-ASCII within a file raises an exception unless you've changed the encoding. Sounds worse than it is. You umlaut folks be warned, however.

Re:Backwards compatibility?

[tdelaney]

Pure-python modules are almost certain to work, unless they hit one of the few documented areas that are not backwards-compatible.

C extensions will probably require a recompile, as some fundamental data structures have changed. This is the norm for any major or minor Python release (i.e. when x or y changes in x.y.z).

C extensions used on 64-bit operating systems will need some important but fairly simple modifications. Quite a few extensions have already been fixed to work with Python 2.5 during the beta and release candidate periods.

Re:Backwards compatibility?

[Chapter80]

I think you are asking about forward compatibility. 2.4 modules and code working under 2.5 is forward compatibility, and for the most part, I imagine every attempt has been made to facilitate this compatibility.

Backwards compatibility, running 2.5 code on 2.4 will really depend on whether you take advantage of the new features.

However... I bet one can easily conjure up examples of 2.4 code that performs differently on 2.5. Since, in python, you can programatic evaluations of syntax, you could easily create (meaningless) code that evaluates some 2.5 python code, within a try/except block that will jump to the except block in 2.4, and not execute the except block in 2.5. Something like this:

try:
....eval("some 2.5 -specific code")
....print "2.5"
except:
....print "2.4"

Therefore it IS possible to create weird examples that are not forward-compatible.

Re:Use the appropriate language

[Intron]

I don't know. Back in the day, I wrote a simplified Lisp interpreter to run on a 6802 microprocessor in 64K. It seemed like the easiest way to run a realtime dispatching algorithm - kind of a rule-based expert system. You can get Lisp going with about a dozen hard-coded ops and write everything else in Lisp. I haven't seen a better way to do it since then, although I like stack-based languages for embedded systems also. Postscript is my favorite. One of the few embedded projects I've worked on that completely failed was written in C.

Re:Use the appropriate language

[masklinn]

It has features from many languages. That's why it's so easy to learn. Whatever your programming style, you can probably do it in Python.

Well python is a multiparadigm language and fairly flexible, but it doesn't go far beyond OO, imperative and lightweight functional styles.

It's not fit at all for logic programming, DBC and AOP are not that cool (even though decorators make them at least possible without being too damn ugly), and hardline functional programmin is impossible due to lack of support for recursions (Python doesn't optimize tail-recursion), absence of pattern-matching and mutable states.

Oh, and it has no support whatsoever for distributed or heavy concurrent programming.

Re:The writer, I believe, is not religious

[Psycosys]

As it turns out yes, check out this mailing list post http://comox.textdrive.com/pipermail/talk/2005-Dec ember/000435.html

Re:The writer, I believe, is not religious

[Psycosys]

It would seem that Guido is not religious. There is a quote at http://lambda-the-ultimate.org/classic/message3555 .html stating as much.

ElementTree

[makomk]

Glad to see ElementTree's gone into the main Python distribution - it's a very nice way of working with XML, and the one I generally use if I have the choice (IMO it has a nice, clean, Pythonic API which generally fits with what I want to do, though it does require you to load the entire XML tree into memory before you do anything with it).

Re:ElementTree

[stuartrobinson]

Yes, the inclusion of ElementTree is definitely a good thing. IMHO, it is the most intuitive and user-friendly way of handling XML in Python (or any other language, for that matter) that I have seen so far.

Does this versio still support Pails?

[Ingolfke]

I've been using Python in Pails for about 3 months now and absolutely love it. It's the only Web 2.0 compliant framework I use for dynamic database driven website creation. It's flexible too, unlike some other tools that ascribe to the one size fits all mentality (PHP we're looking at you). Pails let's you choose a thimble (small framework) for your small customer websites or a full blown pail for your enterprise sites. I'm looking forward to getting wrapped up in this new version of Python, but I can't get out of pails at this point. So if anyone knows... I'd be much obliged.

Re:The writer, I believe, is not religious

[poliopteragriseoapte]

Ah, that must be why Python does no miracles for me.

learning

[mackyrae]

I'm using a book called Python Programming for the Absolute Beginner. It explains all the data types and stuff which does get a little annoying if you already know another programming language, but it cost $15 less than Dive Into Python. I think one of the guys in my dorm is going to borrow it because he needs those explanations (first language).

Re:Aircraft Control

[epee1221]

Somehow, I get the feeling that avionics software is too time-sensitive for interpreted languages, but I've never done it before, so I don't really know.

Re:Let's get it out of the way...

[Yunzil]

Yes, but not on mother fucking planes.

HTH.

Why not learn Scheme

[lakeland]

You're obviously not using lisp for interoperabilit with others, so why not learn a language that's fixed the most glaring faults in lisp while staying very true to its principles? Besides, bad programmers can still write lisp macros: Put a backtick at the start, and a comma before every argument. Not that hard really.

Now, if you want a challenge, learn a pure functional language instead of one that only goes half way... :)

But...

[Estanislao Mart�nez]

[...] Ruby focuses on expressiveness (an inherited "there's more than one way to do it" from the Perl in its genes), and Python focuses on clarity and readability.

But... the point of expressiveness is to make code more readable, by reducing the semantic gap between your language and the problem domain (a concept which is at the heart of the idea of domain-specific languages, which you mentioned as being part of the Ruby approach).

The fact that a language has fewer constructs than another only makes code in that language "clearer" if you assume that clarity consists in it being easier to figure out the low-level details of the code in question ("ok, here it's setting up a loop counter variable, then it's testing whether it exceeds x, then it's..."). If the standard, on the other hand, is to convey what a program is trying to do at a high level, the limitations that get you that "clarity" will hurt you.

Re:But...

[masklinn]

the point of expressiveness is to make code more readable

I disagree, you can have extremely expressive languages that are completely unreadable.

For example, Perl is a very expressive language, and yet it's completely unreadable. Haskell could be another example, it's one of the most expressive and concise languages I know, but it's code structure makes it hard to read when you're not familiar with the language.

Python is slightly less expressive than Ruby, but it has a very readable, very clear and "obvious" syntax, and this feeling of obviousness is part of the language's base and philosophy:

~$ python -m this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Re:But...

[ubernostrum]

Wow. And here I thought all the old Adequacy people had just faded away with time.

unwind-protect

[Nicolay77]

So this is like Common Lisp unwind-protect special form.
Nice feature :)

Ohh sorry, I just forgot that Python is trying not to be more Lisp-like!! :P

Re:unwind-protect

[masklinn]

That's it, except that it's not up to the user to write the unwinding code, but up to the service provider (the one who wrote the code in the first place). The user only writes the protected code.

Which is pretty much trivial to implement with unwind-protect.

Re:Aircraft Control

[Guignol]

I'm not sure about that,
But there are certainly planes on a snake

Backwards compatibility? Yes, backwards!

[mangobrain]

Err... I think you have your definitions mixed up. Forward compatibility is the ability to accept (even if "accept" simply means ignore without error) input that is designed for future use - for example, Python 2.4 would be forwards compatible with 2.5 if you could use it to run code containing "with" statements, accepting the caveat that the code blocks they contained wouldn't be executed (but would "magically" begin to work if you switched to 2.5 - AFAIK, 2.4 is NOT forward compatible in this manner, this is simply an example). A more useful example is in HTML, where forwards compatibility is achieved by browsers simply ignoring tags they do not understand, and treating their content as plaintext - this is how the "noscript" tag works: old browsers ignore the tag and print the content, new browsers know to pretend both tag and content aren't there when JavaScript is available.

Backward compatibility would be the ability of Python 2.5 to completely replace Python 2.4 in current usage scenarios with code changes on the level of little to none. It is the ability of a new version of a system to accept input designed for an older version, and still produce sane, expected output.

The ability to communicate ideas is quite a fundamental point in if you are, or are going to become, a programming professional. The term "backwards compatible" should be in every serious programmer's vocabulary, and I have yet to use it in a face-to-face conversation a programmer who so much as hinted that they didn't think it meant exactly the same thing I do. Forward compatibility is less common; in fact, I actually had to look up a definition to check I had the right idea!

Re:Backwards compatibility? Yes, backwards!

[Chapter80]

Thanks for the correction. It is confusing to me to read other's perspective - but I've been using the terms as specified to me by a major computer manufacturer 20 years ago. So maybe I have been wrong for 20 years. But it is the way I was taught by someone who should know. And this definition is consistent with everyone I have communicated with over years of interfacing with many customers.

We may be saying the same thing, though:

I was really looking at the compatibility of the software, not of Python (since the GP post asked "Will 2.4 modules and code still work?" and this is forward compatibility of the modules and code. Moving 2.4 modules and code onto 2.5 is moving them forward, not backwards.

So maybe I was wrong, but that was my logic. I think it's relative to the software that you are speaking about (are you moving the code forward, or are you moving Python backwards?). But thanks for pointing it out; it caused me to read other's perspective (on Wikipedia, etc).

Wikipedia: ...a product is said to be backward compatible... when it is able to take the place of an older product, by interoperating with other products that were designed for the older product.

Can the code or module, designed to interoperate with 2.5, interoperate with 2.4? That's what I see as backward compatibility of the code.

On a more serious note...

[mangobrain]

It is there: Python 2.5

And they are already fixing packaging problems: 2.5-r1

Bear in mind Gentoo may take longer than most to fully switch over to 2.5, since Portage itself is written in Python. They have much more to lose from getting this wrong than Debian. I have used Debian in the past, but have been a Gentoo user for a few years now; I have noticied a backing off - intentional or otherwise - from the old "bleeding edge" tendencies over the past few months, but I for one am not particularly bothered, provided it isn't indicative of infrastructure problems and doesn't become a growing trend of getting further and further behind. (I have no evidence that it is either of these things, just a bad gut feeling based on some of the not-so-good times I've had with the distro.)

He's not the main dev anymore...

[Millennium]

If you're talking about Jim Hugunin, he handed the project off to others before he left it. But development just plain hasn't been the same since he left.

Re:He's not the main dev anymore...

[chris_mahan]

Thanks, I had forgotten his name.

We too are hoping for a jython that implements python 2.5, but we're not holding our breath.

Python just Jealous of Ruby, I guess

[Slashdot Parent]

Ruby also allows an else block in the case that no exceptions are caught. I have not yet thought of a good use for it, but it is there.

Re:Debunked????

[lekikui]

Typical /. + Python == zealotry....

Shouldn't that be:

(= (+ Slashdot Python) zealotry)

If we're talking about Lisp?

And then comes Python and f!#@$ your argument...

[Nicolay77]

By implementing the Common Lisp operator unwind-protect :P
In case you miss it, the one Python calls WITH.

Don't worry, you can update your paper, and then in Python 3.0 they will copy something else :D

Twisted not included?

[cpghost]

Hmmm... it looks like Twisted framework didn't make it into the standard library (yet?).