Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Python 2.5 Released

Zonk posted more than 7 years ago | from the snakes-on-a-frame dept.

228

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

cancel ×

228 comments

Sorry! There are no comments related to the filter you selected.

Other Big Python Names (0, Troll)

Anonymous Coward | more than 7 years ago | (#16139000)

Did you know the makers of Spam -- Hormel -- also use Python for internal use?

Re:Other Big Python Names (0)

Anonymous Coward | more than 7 years ago | (#16139110)

That still doesn't explain the texture, yuk!

Re:Other Big Python Names (0)

Anonymous Coward | more than 7 years ago | (#16139169)

Arrrr, methinks we send the texture to davy jones locker.

Let's get it out of the way... (-1)

Anonymous Coward | more than 7 years ago | (#16139005)

Will Python be allowed on god damn planes?

Sequal (0)

Anonymous Coward | more than 7 years ago | (#16139027)

Snakes on a Plane 2.5

Too Bad Python Sucks (-1, Troll)

Anonymous Coward | more than 7 years ago | (#16139043)

Tcl 4 life, esse.

Arrrr! (0)

Anonymous Coward | more than 7 years ago | (#16139044)

Where be the pirate posts, mateys?

How appropriate... (1, Funny)

markana (152984) | more than 7 years ago | (#16139047)

for Talk Like A Python Day....

oh wait, .... never mind.

Re:How appropriate... (0)

Anonymous Coward | more than 7 years ago | (#16139102)

hisssss hiss hiis me heartiesssss, hisss hiisssssyyyysshissyshisshiss hiss o' eight.

Your idea sucksss.

Re:How appropriate... (1)

MightyYar (622222) | more than 7 years ago | (#16139109)

You are thinking of Talk Like Cobra Commander Day.

Re:How appropriate... (5, Funny)

Tackhead (54550) | more than 7 years ago | (#16139143)

> for Talk Like A Python Day....

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

Aircraft Control (0)

Anonymous Coward | more than 7 years ago | (#16139083)

Is Python used in any aviation software?

We really can have Snakes on a Plane...

.
.
.

Dear god... I feel so horribly lame... Dirty... Ah man, where is that "Post Anonymously" button...

I'm going to take a shower now...

Languages continue to evolve into ... Lisp (1, Interesting)

Intron (870560) | more than 7 years ago | (#16139086)

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

Re:Languages continue to evolve into ... Lisp (0)

Anonymous Coward | more than 7 years ago | (#16139155)

If lisp is so good, why is it so seldom used?

Re:Languages continue to evolve into ... Lisp (2, Insightful)

Scarblac (122480) | more than 7 years ago | (#16139180)

Because 90% of programmers only know the simplest languages.

Re:Languages continue to evolve into ... Lisp (2, Informative)

ltbarcly (398259) | more than 7 years ago | (#16139270)

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 (4, Informative)

Scarblac (122480) | more than 7 years ago | (#16139433)

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 (4, Insightful)

drinkypoo (153816) | more than 7 years ago | (#16139536)

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

Assembly - C - Python (1)

gd2shoe (747932) | more than 7 years ago | (#16139569)

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:Languages continue to evolve into ... Lisp (0)

Intron (870560) | more than 7 years ago | (#16139686)

Lisp's downfall is that it became popular before there was any concept of language standards so it split into dialects early on and has no standard libraries. Everything is pretty much built from scratch. It has one other major bug, which is it's mistaken belief that indices start at 0 instead of 1. Most other languages have copied this delusion.

(Note: No garbage collection today due to holiday.)

Re:Languages continue to evolve into ... Lisp (0)

Anonymous Coward | more than 7 years ago | (#16139774)

The 0/1 offset goes back to electronics and address decoding, which in turn is represented in machine code and its buddy, assember. Starting at 1 seems plain dumb to me as that's not what's going on under hood, and if you're a real developer, if you cannot cope with starting at zero, it's probably time to try something else.

Re:Languages continue to evolve into ... Lisp (4, Insightful)

a.d.trick (894813) | more than 7 years ago | (#16139723)

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 (1)

the_wesman (106427) | more than 7 years ago | (#16139849)

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

Re:Languages continue to evolve into ... Lisp (1)

John Courtland (585609) | more than 7 years ago | (#16139857)

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

Python is not anything like Lisp (1, Informative)

Anonymous Coward | more than 7 years ago | (#16139632)

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 (0)

Anonymous Coward | more than 7 years ago | (#16139805)

You are mostly agreeing with Graham, you know. The point of his article is that Python has almost what it needs to replace Lisp.

You clearly don't know what macros are. Hint: first class object [wikipedia.org]

Re:Python is not anything like Lisp (0)

Anonymous Coward | more than 7 years ago | (#16139834)

No, macros aren't first-class objects by a far shot. They have nothing to do with each other.

Macros are syntactic abstractions. For instance you could have a macro that translates a yacc-like notation into a parser - at compile-time (or rather macro-expansion time).

First-class objects are totally possible without macros (like in SML or Haskell).

Use the appropriate language (0)

Anonymous Coward | more than 7 years ago | (#16139731)

My school expects us to be expert C programmers because C is the universal language in the embedded world. On the other hand, for a quick and dirty UI, Visual Basic might be appropriate.

In some ways, Python is a multipurpose language. It is very easy to learn yet it has the horsepower and the extensibility to be useful for some very large projects. If you had to pick just one language to use for the rest of time, Python would be a good choice. Of course each language has its own strengths and it's handy to be able to choose the right one. Sometimes you have to use more than one. For instance, Python isn't very good for talking to hardware. The most efficient thing to do is create C code to talk to the hardware and use Python for the rest. It's way faster than using C for the whole thing.

Anyway, wrt evolving into Lisp; Python may be acquiring Lisp like features which you could use if you wanted, but you can easily avoid them. 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.

Python??? (0, Offtopic)

rackhamh (217889) | more than 7 years ago | (#16139094)

I'm TIRED of these MOTHER******* SNAKES... oh, I see. Well, nevermind then.

Translation (0, Offtopic)

whimmel (189969) | more than 7 years ago | (#16139101)

'Tis been nearly 20 months since th' last major release o' th' Python programming language, t' be sure, and version 2, aye, by Davy Jones's locker, ye scurvey dog. It is probably th' most significant new release o' Python since 2.2, aye, I'll warrant ye. Th' latest release includes a variety o' additions t' th' standard library, arrrr, t' be sure, language extensions, and performance optimizations, with a chest full a' booty. This is a final release, to be sure, I'll warrant ye, and should be suitable fer production use. And swab th' deck! Walk the plank! Read th' release announcement, to be sure, aye, by Blackbeard's sword, th' highlights, what's new, and download it, aye.

Good stuff... (1)

Svippy (876087) | more than 7 years ago | (#16139113)

I should be getting my hands on python as soon as possible. According what I've read thus far in the updates, it looks promising, and the fact that they manage to continue with such features in a whitespace/tab/line feed based language. :)

The ministry will be happy (0)

Anonymous Coward | more than 7 years ago | (#16139177)

The Ministry of Silly Walks wants to know where all of the funding went for 2.3 and 2.4. The whole point of Python is to reduce to costs of developing new silly walks. With this new release, The Ministry of Silly Walks should be able to make great advances in the art of Silly Walking.

Re:The ministry will be happy (1)

jimstapleton (999106) | more than 7 years ago | (#16139213)

finally, a joke on the right lines...

What? (0)

Anonymous Coward | more than 7 years ago | (#16139198)

it's not in portage yet!

Re:What? (3, Funny)

cortana (588495) | more than 7 years ago | (#16139711)

Ouch [debian.org] ;)

Python Challenge (5, Informative)

Franio (964631) | more than 7 years ago | (#16139230)

I know this is offtopic but does anyone know what happened to the python challenge [pythonchallenge.com] ?

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 (1)

masklinn (823351) | more than 7 years ago | (#16139429)

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 (0)

Anonymous Coward | more than 7 years ago | (#16139669)

For some challenges you had to use Python but it didnt stop me from learning Ruby using Python Challenge.

Too many pirates riding the snake... (1)

creimer (824291) | more than 7 years ago | (#16139236)

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.

Learning python (1)

gd2shoe (747932) | more than 7 years ago | (#16139408)

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:Too many pirates riding the snake... (1)

rakanishu (670638) | more than 7 years ago | (#16139430)

Python Tutorial [python.org]

Dive Into Python [diveintopython.org] 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... (1)

oscartheduck (866357) | more than 7 years ago | (#16139436)

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/ [ibiblio.org] is as good as many and better than most.

Re:Too many pirates riding the snake... (3, Informative)

Anonymous Coward | more than 7 years ago | (#16139523)

Dive Into Python [diveintopython.org] 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 [python.org] 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.

Dive Into Python (1)

grayrest (468197) | more than 7 years ago | (#16139603)

http://www.diveintopython.org/ [diveintopython.org]

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

Learning Python... add pyrepl to the interpreter. (2, Informative)

zapadoo (807744) | more than 7 years ago | (#16139779)

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/ [codespeak.net]

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 (1)

zapadoo (807744) | more than 7 years ago | (#16139800)

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:Too many pirates riding the snake... (2, Informative)

All_Star25 (736597) | more than 7 years ago | (#16139794)

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 [ibiblio.org] . 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 [oreilly.com] .

Sqlite included! (3, Informative)

imag0 (605684) | more than 7 years ago | (#16139255)

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! (0)

Anonymous Coward | more than 7 years ago | (#16139476)

PHP started bundling its SQLite library in by default as of 5.0, a couple years ago. Whether or not PHP is a "pretty nice" programming language is left as an exercise to the reader.

Re:Sqlite included! (0, Flamebait)

drinkypoo (153816) | more than 7 years ago | (#16139575)

Natively? Yeah, just about as native as perl; there's a library (I'm assuming) and they use some functions from it.

Re:Sqlite included! (1)

masklinn (823351) | more than 7 years ago | (#16139613)

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! (1)

drinkypoo (153816) | more than 7 years ago | (#16139738)

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! (1)

masklinn (823351) | more than 7 years ago | (#16139809)

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

Re:Sqlite included! (2, Insightful)

ubernostrum (219442) | more than 7 years ago | (#16139842)

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! (4, Insightful)

masklinn (823351) | more than 7 years ago | (#16139856)

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! (1)

imag0 (605684) | more than 7 years ago | (#16139680)

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

Cheers

In line conditionals, FINALLY (4, Informative)

gd2shoe (747932) | more than 7 years ago | (#16139279)

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 (1, Insightful)

xquark (649804) | more than 7 years ago | (#16139457)

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 (1, Redundant)

Pope Raymond Lama (57277) | more than 7 years ago | (#16139753)

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

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 (1)

valwig (819169) | more than 7 years ago | (#16139469)

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

Hey! (2, Insightful)

gd2shoe (747932) | more than 7 years ago | (#16139552)

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)

Re:In line conditionals, FINALLY (1)

ShecoDu (447850) | more than 7 years ago | (#16139553)

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 (1)

grayrest (468197) | more than 7 years ago | (#16139622)

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

Re:In line conditionals, FINALLY (2, Informative)

Anonymous Coward | more than 7 years ago | (#16139666)

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 (1)

tuffy (10202) | more than 7 years ago | (#16139628)

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"

OMG (0)

Anonymous Coward | more than 7 years ago | (#16139307)

Bring out the zealots :(

Re:OMG (1, Funny)

Ekarderif (941116) | more than 7 years ago | (#16139376)

En taro Adun.

Re:OMG (1)

stoolpigeon (454276) | more than 7 years ago | (#16139420)

My life for Aiur!

Woot -- conditional expressions! (1)

SilentTristero (99253) | more than 7 years ago | (#16139316)

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

Re:Woot -- conditional expressions! (1)

artlogic (819675) | more than 7 years ago | (#16139482)

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.

Just be glad they're here. (1)

gd2shoe (747932) | more than 7 years ago | (#16139633)

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.

Re:Woot -- conditional expressions! (4, Informative)

masklinn (823351) | more than 7 years ago | (#16139656)

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

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! (1)

artlogic (819675) | more than 7 years ago | (#16139831)

"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! (2, Informative)

Gospodin (547743) | more than 7 years ago | (#16139802)

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.

Finally! (1)

artlogic (819675) | more than 7 years ago | (#16139398)

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! (1)

masklinn (823351) | more than 7 years ago | (#16139455)

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

A Gem (1)

pythiane (1003082) | more than 7 years ago | (#16139453)

Python, the brightest programming gem. ;-)

The writer, I believe, is not religious (-1, Troll)

Cybert4 (994278) | more than 7 years ago | (#16139506)

For comparison, Perl (evangelical) and Ruby (Mormon) are both written by Christians. I'll refrain from putting any opinion here. Just giving the facts as I know them.

Re:The writer, I believe, is not religious (1)

ltbarcly (398259) | more than 7 years ago | (#16139585)

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

Re:The writer, I believe, is not religious (1)

swimmar132 (302744) | more than 7 years ago | (#16139851)

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

SNAKES ON A... (1)

phekno (719662) | more than 7 years ago | (#16139556)

nevermind...

try/except/else/finally (3, Interesting)

ttfkam (37064) | more than 7 years ago | (#16139587)

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 (5, Informative)

artlogic (819675) | more than 7 years ago | (#16139658)

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 (1)

truedfx (802492) | more than 7 years ago | (#16139782)

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 (1)

artlogic (819675) | more than 7 years ago | (#16139882)

More like this:

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

if not error:
    c

Re:try/except/else/finally (1)

cosminn (889926) | more than 7 years ago | (#16139869)

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 (1)

grayrest (468197) | more than 7 years ago | (#16139695)

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 (1)

masklinn (823351) | more than 7 years ago | (#16139718)

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 (1)

artlogic (819675) | more than 7 years ago | (#16139758)

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 (1)

cosminn (889926) | more than 7 years ago | (#16139886)


        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 (3, Informative)

masklinn (823351) | more than 7 years ago | (#16139696)

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 (1)

tuffy (10202) | more than 7 years ago | (#16139733)

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 (1)

Ishi (211995) | more than 7 years ago | (#16139736)

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 (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16139818)

How is this any different than:


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

Easy transition from Python to Ruby? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16139648)

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

Re:Easy transition from Python to Ruby? (3, Informative)

masklinn (823351) | more than 7 years ago | (#16139743)

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? (2, Informative)

masklinn (823351) | more than 7 years ago | (#16139769)

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? (0, Troll)

zapadoo (807744) | more than 7 years ago | (#16139866)

Migrate? And give up significant whitespace?

NEVER.

Aside from the accurate observation from another here that Python's documentation is superior and its stdlib much more complete, the readability of Python is far superior, For some this isn't a big issue, but for others, it will be *the* issue.

WxPython (5, Informative)

nih (411096) | more than 7 years ago | (#16139681)

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

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

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:)
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>