Python 2.5 Released

Re:How appropriate... by Tackhead · 2006-09-19 05:49 · Score: 5, Funny

> for Talk Like A Python Day....

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

Python Challenge by Franio · 2006-09-19 05:59 · Score: 5, Informative

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.

Sqlite included! by imag0 · 2006-09-19 06:03 · Score: 3, Informative

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! by masklinn · 2006-09-19 07:13 · Score: 4, Insightful

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.

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler

In line conditionals, FINALLY by gd2shoe · 2006-09-19 06:06 · Score: 4, Informative

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

--
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.

Re:In line conditionals, FINALLY by xTantrum · 2006-09-19 07:45 · Score: 3, Insightful

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!

--
$action = empty(PHP) ? backToC() : unset(PHP) ; "when the concrete cases are understood, the abstractions are readily

Re:Languages continue to evolve into ... Lisp by Scarblac · 2006-09-19 06:23 · Score: 4, Informative

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

--
I believe posters are recognized by their sig. So I made one.

Re:Too many pirates riding the snake... by Anonymous Coward · 2006-09-19 06:33 · Score: 3, Informative

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:Languages continue to evolve into ... Lisp by drinkypoo · 2006-09-19 06:36 · Score: 4, Insightful

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

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"

try/except/else/finally by ttfkam · 2006-09-19 06:42 · Score: 3, Interesting

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?

--

- I don't need to go outside, my CRT tan'll do me just fine.

Re:try/except/else/finally by artlogic · 2006-09-19 06:51 · Score: 5, Informative

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

--
"A Mathematician is a machine for turning coffee into theorems." ~ Paul Erdos
Re:try/except/else/finally by masklinn · 2006-09-19 06:56 · Score: 3, Informative

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.

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler

Re:Woot -- conditional expressions! by masklinn · 2006-09-19 06:51 · Score: 4, Informative

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.

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler

WxPython by nih · 2006-09-19 06:55 · Score: 5, Informative

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

--
I'm a rabbit startled by the headlights of life :(

Re:What? by cortana · 2006-09-19 06:58 · Score: 3, Funny

Ouch ;)

Re:Languages continue to evolve into ... Lisp by a.d.trick · 2006-09-19 06:59 · Score: 4, Insightful

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:Easy transition from Python to Ruby? by masklinn · 2006-09-19 07:01 · Score: 3, Informative

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.

--
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler

Re:Languages continue to evolve into ... Lisp by smallpaul · 2006-09-19 07:32 · Score: 4, Insightful

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 by fuzz6y · 2006-09-19 07:55 · Score: 5, Insightful

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.

--
If you're going to be elitist, it would help to be elite.

Re:Easy transition from Python to Ruby? by ubernostrum · 2006-09-19 08:12 · Score: 4, Interesting

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.

Re:Dive Into Python by Millennium · 2006-09-19 08:19 · Score: 3, Informative

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:Languages continue to evolve into ... Lisp by ciggieposeur · 2006-09-19 08:54 · Score: 4, Insightful

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 by smallpaul · 2006-09-19 16:09 · Score: 4, Insightful

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

23 of 228 comments (clear)