Slashdot Mirror
Python 2.4 Final Released
Eventh writes "The final release of Python 2.4 was just released. Python 2.4 is the result of almost 18 month's worth of work on top of Python 2.3. New features are, but not limited to, function decorators, generator expressions, a number of new module and more. Check out Andrew Kuchling's What's New In Python for a detailed view of some of the new features of Python 2.4. "
It took them a while, but it's worth it. Here's some of the new features:
/usr/lib/python2.4/pdb.py
* multi-line imports - when using imports in the form from foo import bar, baz, bing, bang, you can surround the imported names with brackets, and they can be split across lines. This is part of PEP 328.
* Farewell to OverflowWarning - as documented in PEP 237, Python no longer generates OverflowWarnings.
* function/method decorators - function and method decorators, first described in PEP 318, have been added to the language, using 'pie-decorator' syntax. Decorators are on the line before the 'def', and prefixed with an '@' sign. (PEP 318)
* Assigning to None - the compiler now treats assigning to None as a SyntaxError.
* Failed import cleanup - when a module import failed, versions of Python prior to 2.4a2 would leave a broken module in sys.modules - subsequent attempts to import the failing module would silently succeed, but use the broken module object. The import machinery now removes the failing module from sys.modules if the import fails.
* The -m command line option - python -m modulename will find a module in the standard library, and invoke it. For example, python -m pdb is equivalent to python -m
Finally I can make my functions so much prettier.
I don't need a signature.
If you can keep your "significant whitespace sucks" comments as children of this one, I'm sure everyone will get along just fine...
import overlords
print "I for one welcome our new %s overloads.!" % overloads.get_random()
The python final release of python 2.4 is finally released for python users out there who wish to use the final release of python release final.
cue grumbling about how Christmas is overcommericalized+etc
The World Wide Web is dying. Soon, we shall have only the Internet.
You forgot the most important improvement, the "generator expressions".
From the AMK's excellent (as always) overview:
print sum(obj.count for obj in list_all_objects())
The important part is that no intermediate list is generated, because we are dealing with generators.
Generators in general kick so much ass it's not even funny.
Save your wrists today - switch to Dvorak
2,500KVA @ 0.8 PF? (note: some electrical background required to appreciate the above)
Karma: Negative (Mostly affected by dorm trolling)
The importance of decimal arithmetic is not that it is more accurate than binary, but rather that it conforms more closely to what people expect from using decimal in daily life. These expectations are codified into various social rules such as accounting practices.
There's been some heated discussion of Python 2.4's Decimal, in this very regard, on the Lambda the Ultimate languages blog.
Instead of having a special keyword for immutable sets (frozenset) wouldn't it be better to have an "immutable", "final" or "const" keyword?!
and of course I managed to forget (again) that comments, being HTML formatted, ignore whitespace.
Karma: Negative (Mostly affected by dorm trolling)
Python is a pretty good language for general use and for teaching. If fact, what got me interested in Python was a story (on Slashdot) about programmers at Sun saying that Python was a better language than Java in their environment.
Having said the above, there always seem to be 'issues'. Floating point numbers are one such issue. This release fixes that with 'Decimal'. The trouble is, you have to know about 'Decimal' before you can use it. This raises the difficulty of using Python.
I find that I write code quickly and then spend an hour researching some module or other. It sure slows down the process.
What were Linus' comments?
I do not see "Extensions API" anywhere on the list of improvements. Last I tried, creating one's own object type or even a simple command was a rather tedious task, unlike in TCL...
In Soviet Washington the swamp drains you.
Someone elaborate a little? Maybe even give us a link?
I had absolutely no interest in Python until I read Slashdots review of Dive Into Python. Its right on target and got me excited to run home and see what I could do. Of course that only lasted for about a month, but I'll be sure to head home and take a peak at it again.
Let me paraphrase you : "I *want* to be enthused, but ... someone told me not to be."
Way to have a backbone, kiddo.
after Linus's comments I am inclined to get more profficient with Bash and C and almost ignore Python completely. It's so dissapointing though - I really wanted to learn Python; it's such a neat language.
Linus explicitly mentioned that he doesn't do anything "in the middle" - it's either kernel hacking or something trivial enough to do with bash. Just go ahead and learn Python - you will find that it's *easier* than bash, especially if your programs might have errors (which they do).
BTW, why would you want to get more proficient in C? Programmers are abandoning C in droves. It's just not programmer-time efficient to do things in C anymore. It's one thing if you are maintaining a project that was written in C originally, but for new projects, C is a non-starter.
Go read ESR's "The Art of Unix Programming", available online for free.
Save your wrists today - switch to Dvorak
Why not learn it, if it is such an neat language (ive dabbled a bit in python after i had to write a semester paper on it, you're right, it is a neat language)
"Something's wrong with you...and I hope we never do meet again." - Deftones When Girls Telephone Boys
Addmittedly yes...
Python is not optimal for system administration, but that's because its focus has moved away from system administration (if it ever was there in the first place). Let Perl have it, or bash. I use it now not as much for system administration as for actual development of my projects, and for that I find it faster to develop than C(++) or Java.
And I don't want to start any flames, this is my opinion.
Please stop misusing Catch-22 to describe chicken-egg problems or other paradoxes that are not Catch-22.
Any chance jython may be updated, soon? It seems it is two versions behind?
Can one tell me why I should learn python and not any other programming language anyway?
From the little I have seen, python seems to be a command line language. Is it anywhere similar to Visual Basic, which I have come to see and experience through a GUI?
Or has python strayed from it's original philosophy of 'one best way to do it'?
I used python in the 1.5 days. The syntax was incredibly clean. Nowadays the language has tremendous idiomatic power, any programming language researcher should be familiar with it.
But that power has brough alot of complexity. At the end of the day, languages are tools and the learning curve to understand (particularly others) python code seems to be increasing.
If you are looking to do something that Bash can do but probably shouldn't (most things people use Bash for fall into that category) use perl, not python. Perl is very bash-like and porting things to perl is easy.
Of course, this is why so many perl programs look like a complete mess, people do quick ports and don't learn how to properly use the language. Do the next guy a favor and do "man perlstyle" early on.
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
I think one of the problems is too many people are still spreading the myth that it's essential to learn C before moving on to C++, which is totally false, C++ is a language in itself, and can be treated as such. Learning C (unless you intend to use it) is a waste of time, and I would go so far to say learning C first will make you less producive in C++, because it teaches concepts which are not applicable, or are actually bad habits when used in C++. At least that's my view on the subject.
That said, C still has its uses, but for many projects (like parent said) it's a "non-starter"
Here's a novel idea: Use the right tool for the job. There's a very large class of problems for which neither c nor bash are particularly appropriate programming languages. I suspect that Linus was attempting to comment on the partcular classes of problems on which he typically works, not on the merits of any specific programming language. If everything you're doing now can be done with bash, then use bash. However, don't rule out Python just because Linus doesn't use it. One day, you'll need to do something that's impractical with bash, and you'll find Python quite useful.
I use Python extensively in my day-to-day work. It's the most versatile tool in my toolbox, and I'm continually amazed that so few people, at least around here, use it.
Grrr, the @ sign is the Ruby way to declare an instance member. This is a declaration of war I say!!! (next thing he'll do is to drop the indentation and add end at the end of all the blocks ;)
At first I was excited to learn that set was a built in type. But for the life of me I cant figure out what good it is when it only operates on characters. Except for perhaps argument checking, it seems rather useless if you cant operate on sets of words and objects rather than letters.
There are GUI toolkits which typically are added on as an extension to something like Python. I am learning Ruby and can choose from Qt, Tk, Wx, Fox, etc. As long as someone has created the extensions you are good to go.
Now we just need to wait for 2.4 versions of py2exe, cx_Freeze3, wxPython 2.5.3.1, SPE, IDLE, PyQt, SWIG etc. before we can start using this!
I expect some software will even die now - like McMillan Installer, as development stopped on 2.3, unless 2.4-devel has some excellent backwards compatibility with 2.3 libraries.
I'm sticking to 2.3.4 for a good while yet, don't have a use for decorators.....
#include <sig.h>
I've always liked Python, but I don't think this update is enough to make me learn it.
In one respect, it is exactly what I've been hoping for. No more sweeping changes or vast syntactic variances, but they have eliminated some usability problems and silly errors. It's a very mature language now, and seems to be behaving as such, this makes me happy
Still, though, they seem to be competing for a niche that Perl has a deathgrip on for me. I use Bash whenever I can, Perl when I can't or it would be ugly, and C when I feel like I haven't had my eyeballs gouged out with hot pokers enough lately -- er, I mean when performance is at a premium.
Python's capabilities seem to rapidly be approaching what I can do with C, and God knows I want to never malloc() again, but as long as compiled binaries can be made only "Not easily," I don't think it's going to unseat Perl for my heavy-duty scripting language slot.
adam b.
Does it use that new Parot thingie that Python and Perl were supposed to share?
Ita erat quando hic adveni.
That entire "debate" consists of one idiot flipping a shit because of a poorly worded snippet from a pre-release version of the "What's New?" overview. He didn't even bother to reference the appropriate PEPs and documentation before grossly misrepresenting the point of the new Decimal type.
No, the Decimal type isn't IEEE 754 standard. No, it doesn't solve, or intend to solve, all the world's numerical analysis problems. Yes, it is a good thing in a language intended to minimize the dissonance between user expectation and actual result.
What the fuck is this supposed to mean?
processFunc = collapse and (lambda s: " ".join(s.split())) or (lambda s: s)
Way to go, and pick a complicated line to use as your example. I think by saying the language reads like pseudocode, they mean:
print 'hello, world'
answer = read_string('what is the answer')
a = str(a)
stuff like that. And don't think that all languages don't have this kind of unreadable code.
The Decimal type! Finaly Python is catching up to COBOL. Yeah.
Actually, its useful. Every language should have it.
Very insightful comment. Many people around here will consider what you said heresy, of course.
There are still performance consierations that keep people on C. While desktop apps can be written in just about anything, ie Visual Basic (though poorly), there are still a good number of applications that require natively compiled code. Servers, embedded systems, military applications, kernels all jump to mind and while most people aren't programming for any of those, it's still a useful language to know for people who want to expand their marketablility.
Not everyone has to a Java/.Net/VB/"programmer-efficient-language" writing code monkey.
I'm not sure what it means, but Python is looking an awful lot like CommonLisp, down to the somewhat controversial syntax.
There are two big differences. One is that CommonLisp made it a lot easier to treat programs as data and vice versa, and it had a built-in high-performance native compiler. On the other hand, Python integrates a lot better with Linux and UNIX, there are tons more libraries for it, and is easier for new users to learn.
Is good to have a light-weight language handy for all those general tasks you encounter, being either perl or Python.
You can learn just enough Python for the specific task at hand and keep on building on top of that knowledge later. Just choose it as your preferred tool and when a task comes, learn how to do it in Python, the libraries available are extensive enough to encompass most of the needs you can think of.
Python includes some neat new ideas on programming, borrowed from more advanced languages that are still in research stage. generators is the prime example and it helps to learn about it if anything just to keep up with the technology.
You might save time in the future by using Python now, as IMHO is easier to mantain than bash or perl.
Finally, If you combine Python with C, specially in a *nix environment, you get a lot of raw power (C) with a powerful and easy interface (Python) and can do lots of fun things.
Carlos J. Hernandez
(Warning: Flamebait lookalike ahead).
:)
IMHO - there are still uses for C, there are absolutely no uses for C++ nowadays. Moreover - there is no C++. I mean - I've been tracking (and sometimes using) C++ developments since the early days till recent and I can tell you - the amount of pileup that they produced in modern C++ compared even to early C++'s (not to say about more sane languages) is totally ridiculous. No - inventing a new language construct for bloody every particular problem does not make a good language. Well - if you want a complex system - use dynamic languages (Python, Lisp, Smalltalk - whatever suits you. Heck - PHP even if you know how to manage your globals). If you want something small and embedded - you should not overcomplicate - use C (refer to Linux sources, for example, to see how people code in C). If you want low-level performance and reliability in complex systems - I hate to say it, but use Java (large portions of IL2 - flight simulator - are written in Java, totally amazing stuff). Of course, if you like brainfucking - C++ may be for you, but it's really a bird that does not fly. On amount of time and energy that you'll waste on learning C++ you can pick half a dozen of better languages.
If still not convinced - check out how many CPU instructions are wasted for such a simple thing as returning a C++ string object from a function. When I show it to C++ "gurus" many are enlightened.
Don't worry about it. It's still a good book and very little (if anything) has changed that affects the book's accuracy. It won't tell you about new features of course, but those are all either dead easy to learn or not likely to matter to the average new pythonista.
Efficient use of programmer time is only one reason to select one language over another. I still code a lot in C on my own projects simply because I enjoy it. Yes, you heard right. I enjoy hunting down stupid off-by-one errors, iteration bugs, memory corruption, silently conflicting declarations, prototype errors, implicit casting errors, rounding and truncation problems, etc. :-)
If all the C programmers vanish, what are we going to write the next generation of high-level languages in? Python? Do you really want a future where not a single person actually knows what is happening inside that CPU, just because "it's hard?"
Yes, programming C is very difficult. And I love it for that, just like I love climbing mountains. That's pretty damn hard, too. At least while programming C I can't accidentally kill myself.
Currently in Python, the C floating point libraries used will produce this:
>>> 1.1
1.1000000000000001
Thus, the Decimal data type was born.
From PEP 327: "The inaccuracy isn't always visible when you print the number because the FP-to-decimal-string conversion is provided by the C library, and most C libraries try to produce sensible output. Even if it's not displayed, however, the inaccuracy is still there and subsequent operations can magnify the error."
Function Decorator Proposal/Specification
Its nice to see a language evolve in favor of use without sacrificing readability and overall utility.
Before:After:Readable is of course in the eye of the beholder... and I am a C and Java programmer with a sizable fetish for D. So while I don't find the syntax all that pleasing to me in terms of my own work, it certainly changes things for reading python code.
I was also stunned to learn how flexible decorators were in the previous version of python. It's refreshing to be see functions treated as objects... unless I'm mistaken about the concept.
However its a huge shame that the new decorator syntax isn't supported for classes in 2.4. Seems like that's going to become a wart on a rather consistent language syntax, IMO.
Maybe you shouldn't do it then: take a pointer to a string object as an argument, and modify it directly, then you don't have to return anything.
So now that Python is using the '@' character for function decorators the Pythonistas can no longer crticize other languages like Ruby (which uses sigils responsibly) for their use of '@' (I'm not including Perl in the list of languages that use sigils responsibly, btw :)
:)
Welcome to the sigil club! Pandoras box is now open! '$' can't be too far behind
string a, b, c;
c = a + b;
That's how all the people do it and how C++ says you can. Do you do it any different way? (That's what I was referring to).
Linux is good at what he does, but what he does represents only a small slice of programming. So, his choice of language and tools really shouldn't have any bearing on your choice unless you happen to be in the business of writing big, monolithic kernels for PC hardware.
Actually, a lot of language and systems designers have blinders on when it comes to the needs of large chunks of their potential user communities. In particular, numerical and scientific users get short-changed in this because most people who develop programming languages think about their needs as an afterthought. As a result, languages like Java end up being awful for scientific programming, while languages like Matlab and Fortran, which have a lot of the features scientific programmers need, end up being awful languages.
Python is an excellent language for lots of applications; give it a try. There is a good chance you will like it and find it very useful.
[[F*ck. Messed up a previous message. Bart Simpson: "I will always preview what I post to slashdot"]]
;)
:-)
If you want to be a good programmer all-around you _have_ to know C. I suppose this statement will be true for another 20 years maybe.
Actually - C is kinda unique language in that it does what it was intended to almost perfectly. And then it does much more. Me, I have only these several micro-complains about it:
1) "->" operator is redundant. "." after pointers would've suffice and would be more elegant and easier on my eyes and fingers.
2) "for()" loop is a bit misguided. More specialized version I would've like more. Also - when "for (i=0; i < n; i++)" idiom is broken it takes some concentration on my side to understand what's happened
3) Prefixes for "struct" fields in standard library are redundant. tm->tm_hour IMO wins nothing over tm->hour.
Other than these - it's a very cool, easy to learn, and elegant language. One of inventors - I don't remember who - Ritchie? - said that if he had to invent it anew, the only change would've been "creat()" becoming "create()"
If all the C programmers vanish, what are we going to write the next generation of high-level languages in?
That's a very good question. However, just because programming in C is difficult doesn't mean that it's the best language to write high-level languages in. C has many design flaws that people have gotten so used to, they assume there's no other way of doing things.
If you like programming in C because it's a challenge, then by all means do so. However, I would classify that hobby with people who program in Intercal and similar. Those languages are challenging too.
I see a real need for a language that is as easy to program in as Python, yet as potentially fast as C. As far as I know such a language doesn't exist yet, but I see no fundamental obstacles preventing us from creating one. It's just a matter of time.
Do you really want a future where not a single person actually knows what is happening inside that CPU, just because "it's hard?"
Yes, an essential part of a programmer's training is learning exactly what is happening inside the machine. However, a human being cannot keep track of everything at once. That's why we use abstraction. A high-level language (not C) abstracts away the details the computer is smart enough to handle, and leaves the material which the computer is not smart enough to handle.
Programming is fundamentally hard. Making the job harder than it needs to be can be fun, but for day-to-day work, it just doesn't make sense.
TTFN
BTW, why would you want to get more proficient in C? Programmers are abandoning C in droves. It's just not programmer-time efficient to do things in C anymore. It's one thing if you are maintaining a project that was written in C originally, but for new projects, C is a non-starter.
nice try.
C is the defacto for embedded systems. it's smaller and faster and there are libs available that make your app 1/10th the size of a regular C app.
ther are no embedded libs for C++ that are solidly tested and compatable with the regular libs.
Embedded programming is getting huge, and C is a part of that.
Do not look at laser with remaining good eye.
BTW, why would you want to get more proficient in C? Programmers are abandoning C in droves.
:)
For analyzing exploit code. That's all done in C and Assembler.
dmiessler.com -- grep understanding knowledge
Let me paraphrase you : "I *want* to be enthused, but ... someone told me not to be."
While being quite witty, you're missing the point. It's easier to follow the crowd and say Python is the best tool for Bash-oriented tasks. It's harder to admit that while being cooler, it may not be as efficient as Bash.
This is the reality that I knew before reading Linus's comments but only became willing to accept after he did so - hence my post.
In other words, the practice of learning Python will be much like learning French. It's quite nice to know, and learning another language is always a bonus, but perhaps I should spend my time on something more useful given the fact that there is an existing tool (that I am more familiar with) that works as well or better.
dmiessler.com -- grep understanding knowledge
IIRC the grand parent is refering to an interview with linux in the Revolution OS documentary. I can't find any links that provide quotes though.
Like ultrabot already mentioned, Linus doesn't use languages like python very often because his interests lie in kernal hacking or in small projects that can be done in bash. That doesn't mean that Linus doesn't like python.
C++ is slowly being replaced with C# and Java in today's academic and corporate environments just like C++ began to take over C 15 years ago when Windows came out.
But C++ is still taught in many universities and still is used in many old corporate apps just like C is still around here and there. People use it because they are familiar with it.
C++ can be nasty but it can also be used for procedural programing and as long as you don't go crazy with pointers and some of the less documented STL its not too bad. I use to use C++ and it can be tollerable if you watch yourself.
I prefer Java or C# much much more for real object oriented work with great libraries and api''s with a fraction of the amount of code and errors.
http://saveie6.com/
I thought you meant this:
string hello_world()
{
return "hello world";
}
hello_world();
Which fits your description perfectly
C++ STl's generate a ton of code which is probably the reason.
Java micro edition is making some headway as well as some scripting languages. Still I see assembler being used as well.
Embedded systems remind me of pc's 15 years ago in power and memory available.
http://saveie6.com/
I don't quite understand. CLU, which was designed in the 70's, had generators with a very similar syntax to Python's ("yield" keyword, similar for-loop). Python has a somewhat more complex iteration repertoire than CLU with list comprehensions, general iterator protocol and the new generator expressions.
If you want to be a good programmer all-around you _have_ to know C.
[...]
Other than these - it's a very cool, easy to learn, and elegant language. One of inventors - I don't remember who - Ritchie? - said that if he had to invent it anew, the only change would've been "creat()" becoming "create()"
That was a comment about UNIX, dumbass. It's amusing that you made a comment about needing to know C, but you apparently don't know C well enough to recognize that "creat()" is not a part of the C language.
a = [7,8]
b,c = "5" * len(a), ("5 " * len(a))[:-1]
c = c[:-1]
print b, c
I'm positive, don't belive me look at my karma
Divide-and-conquer. Any program is a sum of many smaller bits. The easier the smaller bits...
Of course it's going to take a lot of instructions, because you're dynamically allocating a new variable-length string object. That's far safer than the typical C approach. If you allocate a new safe string object in C using something like glib, you'll get a comparable number of instructions.
Maybe C++ should have used immutable strings to make it somewhat more efficient to create new string copies. OTOH, if you pass mutable strings by reference to a function and have it modify the string as output, you get performance that other languages like Java can't touch because you can avoid doing any heap allocations. C++ strings are just a library anyway; you can probably find an immutable string library somewhere.
Doing it the C way with manually allocated fixed sized buffers is simply not an option. It is unacceptably dangerous and has been the root of many if not most security holes.
google for py2exe.
import glob; for f in glob.glob("/tmp/*").sorted(): print f
You're still allowed to use ; to break lines.
I agree with the sentiment, but not the conclusion.
There are still times when we need the low-level, fine granularity of something like C. On those occasions, we also frequently need some high-level features as well, which is where C++ came from.
Unfortunately, the design of C++ has meandered around the design state space so much that many of us consider it to have become quite a mess. Whole *series* of books have been written on the vast number of pitfalls of working in C++.
Dropping back to plain C to get some simplicity and clarity isn't very attractive, for ordinary application work, though. It lacks too many useful things.
Instead, we are told to "use a subset of C++" in some special way that changes over time. That's supposed to bring back the simplicity without sacrificing power. So now every developer uses a different subset a different way, meaning all "good C++ developers" need to have an encyclopedic knowledge of arcane trivia to work with other developers. Where did the simplicity go?
I think the best approach is a language that is as low level and simple as C, but has most of the most popular high-level features of C++ and even many Python-like conveniences, and that's the "D" programming language.
It's still in beta, but it has progressed far enough and is out in the open enough that it looks as though it will become a reality, unlike Paul Graham's Arc.
Sticking as close to C as they have means that it should be relatively easy to slip it into the massive existing infrastructure of libraries and OS calls that exist for C and C++.
It's like C with many of the conveniences of Python built-in but overridable.
It's not as easy to work in as Python, but when you need to use either C or C++, you might be able to get away with using D. Despite the many Pythonesque features, it's still so close to C that a D compiler can statically link compiled D with compiled C into a standalone executable.
I hope to be able to switch from my current "subset of C++" to using D in the not too distant future.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
3) Prefixes for "struct" fields in standard library are redundant
They are now, but they weren't when Unix was written. For that matter, "." and "->" weren't redundant back then; there's at least one place in the Lions Book where there's an int on the left-hand side of a ".", and a few others with ints on the LHS of "->", and the meanings are different.
Linus is not some kind of deity. He (by his own account) does nothing between kernelspace and small scripts.
I'm very proficient with C, Python and Bash, and I can tell you for a fact: Bash and Python barely compete against each other.
Bash has nothing in the way of nice datatypes. Bash is very slow while Python can be nearly as fast as C (I've gotten it up to 80% when relying heavily on C libraries like regex). Bash can't do more than the most trivial things without helper programs, which while useful, takes forever because it has to keep spawning processes.
For a high level language, Bash has pathetic memory management. Pretty much the only way to get some things done is tempfiles, which is worse than malloc because they're not removed if you don't clean them up.
If you can't hold more than two languages in your head, go home and learn Java and C#. You're only going to get made fun of on slashdot.
I rarely criticize things I don't care about.
...I am inclined to get more profficient with Bash and C...
But Bash does not do anything. To accomplish something you have to use all the command line tools, like grep, sed, and awk. Put those tools in the language and you have Ruby or Perl.
Shell scripts are only really quick to develop because they mirror what we would type via the CLI. Thus the name, "script".
All interpreted languages are abstractions over Lisp
I'm so not happy with the way python development is going. I'm seriously thinking of moving to another scripting language. One that doesn't claim to be anything, that way when it changes directions or adds superflous functions and syntax - I won't be dissapointed. What a dissapointement: I'm also starting to think its becoming a bit bloated.
"BTW, why would you want to get more proficient in C? Programmers are abandoning C in droves. It's just not programmer-time efficient to do things in C anymore. It's one thing if you are maintaining a project that was written in C originally, but for new projects, C is a non-starter."
C is necessary for enough things that it won't be replaced in our lifetimes. Its use has diminished now that it's not being forced into service for things it was never great at, but it will never be driven out of some areas.
Also, I think it's critical that programmers learn C if only to understand what's going on underneath the newer languages.
I rarely criticize things I don't care about.
All those funny symbols, casting back and forth in perl just getting in the way yet don't really say anything useful ... here is an example:
whether or not this is good code is not the point, I have to make it work, look at all that pointless markup, in python this same thing would look like this:
(leading . stands for a space )which version would you rather read?
or that uselessly verbose java where you have to write X number of lines before any action starts ...
Python is a simple, clean and powerful language where the real value comes tomorrow or next month, when you have to understand and modify what you wrote today. There are no objective measures of this quality you have to try it to believe it.
Wow where did you get that Stat? *rolleyes.
You're quite right - functions in Python are first-class objects.
So are classes, bound and unbound methods, and everything else.
It's possible to do some serious magic with metaclasses, making use of the fact that classes are just objects. Stuff like that can hurt to look at, though, where 'a' is an instance of 'A', and 'b' is an instance of 'a'. *winces and rubs brain*.
The issue with 'float' is actually a hardware limitation. It's present in all languages that use the floating point hardware. Python, however, doesn't hide it from you when you print the floats - AFAIK that's pretty much the only difference.
What it boils down to is that floats are a PITA. That said, in practice I've had few issues, I just remember the usual rules like never comparing floats for equality, only by a range, and always truncating them when printing. I do exactly the same thing in C++.
I'm doing it now, and I must agree - it's pretty slow going.
... *sigh*. Still, most of the low-level API is pretty good once you know it - it could just use a big improvement in the documentation.
It's fairly fast and simple to implement a module and a bunch of functions, I'd find it hard to complain about that.
Unfortunately, the same cannot be said of building objects, which I find a considerably more irritating processes.
There are a bunch of tools that others have mentioned to help out, of course, but they don't fit every situation. I'm just having to code the lot by hand
What _is_ endlessly frustrating is the lack of a standard C++/Python interface shipping with Python. It really sucks to have to implement Python objects as plain C functions in C++.
I've looked at enough of GCC's assembly output to know what kinds of things it does for certain kinds of code...
And I don't see how assembly language is any more or less "on the machine" than C code, given the fact that computers do not execute assembly language -- they execute machine language.
So what. Linus also says you shouldn't be running cards that need binary drivers, so do you completely ignore the benifits of the nvidia driver if you have an nvidia card?
he gave an opinion and said what he uses to do things, but its not gospel. If you like the language, its probably usefull to you.
"I use a Mac because I'm just better than you are."
I'm with you on the functional style issue.
I always hated functional programming, having been forced to learn to use utterly crippled pure-functional teaching languages. Uggh. Consequently, I thought functional programming was pointless academic wank.
I didn't forget how to do it, though.
With the Python 'map', 'filter', 'zip' and 'reduce' functions, I found myself breaking into segments of functional style again, where it was faster / simpler / safer / cleaner.
List comprehensions increased this further, largely by eliminating the horror that is the nested map and filter jungle.
Some programs, especially data processing ones, I now write almost purely functionally. I'll usually write a series of functional blocks that perform each major transformation, put them in separate one-line functions, then perform each block in series in the main() function.
I generally find this results in much less buggy, faster, and better designed code.
The most important thing is that I can use imperative code where it's more appropraite, and functional code where it fits best. That's just fantastic.
BTW, why would you want to get more proficient in C? Programmers are abandoning C in droves. It's just not programmer-time efficient to do things in C anymore. It's one thing if you are maintaining a project that was written in C originally, but for new projects, C is a non-starter.
For one, C has historical significance. How many languages can you name that don't borrow from C. (Java, JavaScript, Powerbuilder, etc all borrow syntax from it.)
For programmers, it's almost like a universal langugage for exchanging information--want to know how to do something--you can probably find a code snippet in C showing you how. Even if you don't program in it, it's good to know a little of it so you can read all the samples you'll find.
And it was designed for writing operating systems so several OSes are writting in it.
I don't know if C is dying or not. But I don't think it's outlived it's usefulness.
Coder's Stone: The programming language quick ref for iPad
What issue do you find? Java also have the same design with a float data type and a BigDecimal class for arbitrary-precision decimal numbers. If you are complaining that C doesn't have a Decimal type that's more understandable.
But I don't think you need to conform to the One True Perl style to write legible Perl; heck, a One True Perl style is antithetical to the whole Perl philosophy of Many Ways To Do It.
The perl style guide is not exactly strict. The reason to have it is that perl code needs to be interpreted by two distinctly different parsers, the perl parser and the human code reader. Rules like "No space before the semicolon" are for us humans who have a hard time parsing code written the other way.
There is a benefit to letting people code in the style they like. There is also a benefit to making them code in the style the person who comes along next, likes. The key is balancing those two benefits. Most people underestimate the amount of re-use their code will get. If you use 4 character tabs in all your code and the rest of the world uses 8 character tabs, your code will look horrible to them (I really loved my 4 character tabs. sniffle.) but, if you want to be able to work well with others, you need to be able to pick up other people's code and have other people pick up your code.
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
Well, my main point was that what Linus uses probably shouldn't matter to most people because what Linus does is pretty atypical.
It's not that they have blinders on, it's that you can only do so much well.
The problem is that we have far too many languages of the form that language designers like to design. We don't a dozen variants of ML, we need some more languages like SISAL.
So, in your example, tools like Matlab can go back and forth between letting Matlab routines be called from C,
Ah, Matlab calling C--the unspeakable calling the inedible. Seriously, both Matlab and C were steps backward from systems that preceded them.
You example is a very powerful one liner!
You need to learn a few Python idioms. Anyone who work with Python for a while should have no problem understanding this.
1. x and y or z is Python's version of ternary operator. If is similar to x ? y : z in C.
2. " ".join(list) is similar to string.join(" ", list). I won't go into detail here but your expresion collapse a string with multiple whitespaces into single space.
3. The lambda construct is a function factory. Thing of callback in C but Python allow for much more elegant functional style programming.
The entire expression create a function which can collapse or not collapse a string base on you choice. The best thing is to see it in action with two more lines:
for line in file('xyz.txt'):
print processFunc(line)
This will output a files with whitespace collapsed or unmodified depends on the collapse flag.
Every language has its syntax and idiom to learn. Is the syntax below readable? Yes if you actual know the language.
for (i=0; in; i++) {
If you expect 0 learning and that each line of Python maps to something you are familiar with such as C, that's not what Python really is.
Normallly yes, but using them between an "import" and a "for" triggers a syntax error. Try it yourself and see:
Ita erat quando hic adveni.
Then I stand corrected. :)
But I like Lua better for embedding into apps. And as a lnaguage as well. Pygame is horrible and slow IMHO.
click me
"see a real need for a language that is as easy to program in as Python, yet as potentially fast as C. As far as I know such a language doesn't exist yet, but I see no fundamental obstacles preventing us from creating one. It's just a matter of time." It's called Lua.
click me
Because there's a one to one relationship between assembler instructions and the machine intstructions. Assembler is just human mnemonics for opcodes. Effectively, assembler is the machine code.
For example, take a simple function call for a function returning void and taking an integer (with standard calling convention) in C:
ack (3);
the assembly for this would look something like:
mov eax, 3
push eax
call ack
In this very simple case there's a three to one increase in statements. That's why assembler is more "on the machine" than high level languages (which technically C is one of).
Disclaimers:
1) Yeah, I know the one to one thing doesn't hold true for certain directives and etc in macro assemblers...but that's not what I'm referring to.
2) Yeah, I know most chips that support the 80x86 instruction set produced in recent years don't actually execute the 80x86 instructions "natively" but rather have risc-like cores and execute microcode etc...but for the purposes of the above it doesn't matter.
Matlab, famously, has an array type (the basic data type is a 2-D array or matrix -- hence "Matlab"). While Matlab is interpreted and slow, functions that operate wholesale on array types are fast. Java has an array type, and they seem to have done a good job of it with efficient bounds checking. At one level, a Java array definition is a class like any other class, but an array is special case (you cannot "extends" an array type) that gives the required efficiency.
While the early Lisps didn't have arrays, I am told Common Lisp and the other dialects stemming from the Lisp machine days where the emphasis was on having an industrial-strength language, they all had arrays, and they even had neat ways of taking array "slices" -- passing a subrange of an array and having bounds checking apply to that subrange.
Python is working on arrays -- Numeric and Numarray -- but adoption seems slow in stuff like plot and graphics packages.
I would like to use Python as a replacement for Matlab -- I am bothered that we are so stuck on Matlab in our engineering curriculum -- a university shouldn't be shilling for a properietary language from a single vendor. Besides, Matlab is so ad hoc and cobbled together -- I think we could use something with a better theoretical foundation in language design.
I am looking for a good plot/graphics package for Python that supports on of the Python array types to make this transition.
way to make a point, unfortunately i believe you made the other guy's point.
What's so unreadable about that? Once you get used to the idiom of "shift in a sub gives you the next argument" you'll be set for life.
all of it, you just admitted you needed to know something about the code/language to understand what it was that you wrote. anybody should be able to understand what the block of Python code did without having ever seen Python before (but obviously _some_ programming experience is necessary) because it reads as psuedo-code.
Please don't read my sig.
I didn't see this in the discussion yet. The number one reason for me to upgrade to 2.4 is that it's the first (official?) release to be built with MSVC 7 (for Windows, of course). As of 2.3, the distutils package would barf if you tried to build extensions with MSVC 7 instead of 6. Apparently MS changes enough stuff between major compiler releases that lots of little bugs would pop up for extensions built with a different version.
...), I
tried rebuilding Python 2.3.4 and various
libraries (numeric, etc) with MSVC 7. This
was a huge pain particularly when I found a
new library. I wanted to use the 2.4 betas but the boss wouldn't go for it. I was forced to live with MSVC 6. Feel my pain, people.
As MSVC 6 is so truly horrible for writing anything advanced (or using Boost
18 months and they hit the release target almost bang on. Way to go!
for new projects, C is a non-starter.
Not into embedded development, are you?
No it doesn't. Consider the machine instruction 0x90 on x86 architecture ("NOP"). Should the disassembler turn this into a "nop" or might it use "xor eax, 0"? I've seen disassemblers which do both.
Conversely, consider the instruction:
mov eax, [ebx + 0]
Should this produce "8B 03" or "8B 43 00" ?
Clearly the mapping is not one to one, in EITHER direction.
Try it. If nothing else the experience will make you a better perl programmer. I found the same when I tried perl. Personally, I prefer python for a simple reason: code intelligibility. You can go back to python programs months later and understand them immediately. The absence of braces is helpful too, means you don't have to move off the home keys when coding, and it's one less thing to type, but unlike many perl abbreviations you actually improve readability by removing them - the eye follows the indentation, not the braces, so it's better when the interpreter does too.
I am trolling
IME python scripts are far easier to fix when you find a problem in them six months later than perl ones. And I learnt python faster than I learnt perl, despite knowing bash. YMMV of course.
I am trolling
If you're going to nitpick about how man CPU instructions it takes to return a std::string, you better not use any high-level language.
Take a look at the job market, good knowledge of C++ is still an invaluable skill.
Moreover take a look at libraries like boost or systems built on C++ like KDE. Well written C++ can be just as elegant as any language (it's always in the programmers hands, they can turn anything in to spaghetti). There's a reason why it's been so popular and many of its concepts are used in other languages (not to say that it was original in its ideas, but in its use of them).
It's called Lua.
Lua is an interpreted language. A Lua program can never be as fast as a properly-written C program. If you can prove differently, there's a big future for you in Computer Science.
Let me clarify my point. We need a language that is easy on the programmer, but can also be used to write fast code and operating systems.
Compiling to native code is essential for a truly general-purpose language because there are some things which an interpreter cannot do. Full hardware speed and bare metal execution are two of them.
TTFN
I'm so not happy with the way python development is going. I'm seriously thinking of moving to another scripting language.
Yes decorators are a major wart, but who says you have to use them? You don't even need to update to 2.4.
Better to be despised for too anxious apprehensions, than ruined by too confident a security. --Edmund Burke
Yeah, I'd love to use a language whose maintainer doesn't seem to understand the importance of Unicode. 'Cause ASCII and EUC-JP is all we need, right? :rolleyes:
Ah... the follies of youth. And what do anonymous cowards use in Korea? :p
Um, sort of. At some point in the future you are likely to want, or need, to muck with someone else's code, and that someone may have thought decorators were the cat's meow.
I've gotten the impression that Python was designed to ensure that developers didn't do anything too out-of-hand by simply denying the option, from the enforced code formatting to the There's Only One Way To Do It philosophy. So, I tend to think that decorators were added because there is a compelling need for them.
Java is the blue pill
Choose the red pill
At some point in the future you are likely to want, or need, to muck with someone else's code, and that someone may have thought decorators were the cat's meow.
That's the rub of course. How likely it is, depends on how widely decorators will be adopted. It's also a bit of an old saw. It was practically the sole argument for rejecting PEP308 (ternary logical operator). My inconvenience in possibly having to read someone else's code which uses decorators is probably outweighed by the extra expressiveness those who imagine they need this 'feature.'
OK, the truth is I'm still pained by the inclusion of these @$#@*!! ugly decorators and I'm trying to be generous in an attempt to come to terms with my grief ;)
I tend to think that decorators were added because there is a compelling need for them.
I've yet to be shown any reason that comes anywhere near 'compelling.'
Better to be despised for too anxious apprehensions, than ruined by too confident a security. --Edmund Burke
Not into embedded development, are you?
That's exactly what I do, in C++.
Save your wrists today - switch to Dvorak
The main change is that we're replacing Java code with Python. Java was used for things like GUIs and report generation but it's much quicker to code these kind of things in Python. Most of the grunt work is done by the C++ back end so Python's lack of run time speed isn't an issue.
I was just being a smartass.
click me
for f in (glob.glob("/tmp/*")).sorted() : print f
AttributeError: 'list' object has no attribute 'sorted'
The OP must have typed that wrong. It should be:
for f in sorted(glob.glob("/tmp/*")): print f
print "$_\n" foreach (sort glob "/tmp/*")
I dare python lovers to write something like that in python in one line.
Why is one line better?
But anyway (assuming you've imported glob already--you'd need to do that for your Perl, too):
for f in glob("/tmp/*").sorted(): print f
(print already newline-terminates, but you could easily "print f+'\n'" or whatever)
rage, rage against the dying of the light
First, if you've already done the right import then its:
for file in sorted(glob("/tmp/*")): print file
which comes to:
for file in sorted glob print file
which is much easier for an English speaker to understand than the perl, IMO:
print for each sorted glob
second, I'm not really sure how else you'd want to express this. But if you're building a list for more complicated manipulations, Python provides many styles to do it.
rage, rage against the dying of the light