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."
Python Challenge (Score:5, Informative)
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: (Score:2)
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: (Score:2)
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... (Score:2)
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: (Score:2)
Otherwise, http://www.ibiblio.org/obp/thinkCSpy/ [ibiblio.org] is as good as many and better than most.
Re: (Score:3, Informative)
Learning Python... add pyrepl to the interpreter. (Score:2, Informative)
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.
Re: (Score:2, Informative)
learning (Score:2, Informative)
Re: (Score:2)
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 [oreilly.com] 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 [hetland.org]. (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-
Re:Dive Into Python (Score:4, Informative)
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: (Score:2)
He's not the main dev anymore... (Score:2)
Sqlite included! (Score:4, Informative)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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: (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.
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: (Score:2)
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 m
Re: (Score:2)
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: (Score:2)
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 stru
Re: (Score:2)
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 l
Re: (Score:2)
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: (Score:2)
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.
Cheer
Re: (Score:2)
The documentation for Python 2.5 is still in docs.python.org/dev [python.org]
It's also up to date in the Windows bundle, and the SQLite3 documentation seems fairly good [python.org]
In line conditionals, FINALLY (Score:4, Informative)
It is good to finally see inline conditions such as:
This just makes me happy!
Re: (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: (Score:2, Redundant)
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.
F
Re: (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 h
Re: (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.
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)
Re: (Score:3, Insightful)
Re: (Score:2, Informative)
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):
Woot -- conditional expressions! (Score:2)
Re:Woot -- conditional expressions! (Score:5, Informative)
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: (Score:2, Informative)
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
Re: (Score:2)
Re: (Score:2)
try/except/else/finally (Score:4, Interesting)
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 (Score:5, Informative)
else:
print "no exceptions occured!"
Everything else is the same as Java/C++.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Informative)
Re:try/except/else/finally (Score:4, 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.
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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 pr
Re: (Score:2)
It woulnd't do the same thing in a couple of cases:
WxPython (Score:5, Informative)
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:)
Re: (Score:2)
ElementTree (Score:2)
Does this versio still support Pails? (Score:2)
Re: (Score:2)
Re:How appropriate... (Score:5, Funny)
AVAST! Ah've had it with these landlubbin' memes on this landlubbin' website!
Re:Languages continue to evolve into ... Lisp (Score:5, Insightful)
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
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 cla
Re:Languages continue to evolve into ... Lisp (Score:5, 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 :-)
Re:Languages continue to evolve into ... Lisp (Score:5, Insightful)
Re: (Score:2, Interesting)
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: (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.
Re: (Score:2)
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
Re: (Score:2)
My opinion: programmer
Re: (Score:2)
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: (Score:2)
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 l
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:Languages continue to evolve into ... Lisp (Score:5, Insightful)
Re: (Score:2, Interesting)
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 peo
Re: (Score:2)
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.
Why not learn Scheme (Score:2)
Now, if you want a challenge, learn a pure functional language instead of one that only goes half way...
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:3, Informative)
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,
Re: (Score:2)
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).
Re: (Score:3, Informative)
Re: (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 r
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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 CPyth
Re: (Score:2)
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 la
unwind-protect (Score:3, Insightful)
Nice feature
Ohh sorry, I just forgot that Python is trying not to be more Lisp-like!!
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:What? (Score:4, Funny)
Re:Easy transition from Python to Ruby? (Score:4, Informative)
Re: (Score:3, Informative)
Re:Easy transition from Python to Ruby? (Score:5, Interesting)
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.
Re: (Score:2)
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 "obv
Re: (Score:2)
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 an
Re: (Score:2)
HTH.