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."
AVAST! Ah've had it with these landlubbin' memes on this landlubbin' website!
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.
It is good to finally see inline conditions such as:
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.
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.
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.'"
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
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
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
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.
Damn, missed that one.
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
If you're going to be elitist, it would help to be elite.
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:
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.
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...
.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).
... 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.
.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).
...)
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
Pathnames
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
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.
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."