Python 2.5 Released 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."
Re:Languages continue to evolve into ... Lisp (Score:3, Insightful)
Re:In line conditionals, FINALLY (Score:2, Insightful)
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:Languages continue to evolve into ... Lisp (Score:5, Insightful)
Hey! (Score:2, Insightful)
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)
Easy transition from Python to Ruby? (Score:1, Insightful)
Re:Languages continue to evolve into ... Lisp (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. 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:try/except/else/finally (Score:1, Insightful)
try:
foo = someDict[key]
except KeyError:
return None
return myCrazyFunction(foo)
Re:Sqlite included! (Score:3, Insightful)
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.
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! (Score:5, Insightful)
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.
Re:In line conditionals, FINALLY (Score:2, Insightful)
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:Use the appropriate language (Score:3, Insightful)
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:Languages continue to evolve into ... Lisp (Score:5, Insightful)
Re:In line conditionals, FINALLY (Score:3, Insightful)
Re:Languages continue to evolve into ... Lisp (Score:3, Insightful)
Re:Languages continue to evolve into ... Lisp (Score:5, Insightful)
Re:In line conditionals, FINALLY (Score:2, Insightful)
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:Languages continue to evolve into ... Lisp (Score:5, Insightful)
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.
Re:Languages continue to evolve into ... Lisp (Score:1, Insightful)
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 (Score:5, 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."
Re:Languages continue to evolve into ... Lisp (Score:2, Insightful)
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.
unwind-protect (Score:3, Insightful)
Nice feature
Ohh sorry, I just forgot that Python is trying not to be more Lisp-like!!