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

Comments

FP!

[imbaczek]

Let the decorator bashing begin!

Re:FP!

[Pxtl]

@this
@is
@an
@ugly
@character
def is(it, not):
pass

Re:FP!

[nkh]

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

Re:FP!

[CPrimerPlus]

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.

Re:FP!

[Capsaicin]

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.

Re:FP!

[JamesOfTheDesert]

Yes decorators are a major wart, but who says you have to use them?

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.

Re:FP!

[Capsaicin]

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

Re:FP!

[Anonymous Coward]

"This is a declaration of war I say!!!"

Uh, don't you mean "decoration of war"?

Re:FP!

[Anonymous Coward]

its becoming a bit bloated

"it's".

18 Months

[nijk]

It took them a while, but it's worth it. Here's some of the new features:

* 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 /usr/lib/python2.4/pdb.py

Re:18 Months

[davesplace1]

Looks like a lot of good improvements, still takes me a couple of weeks to get used to new features. All in all Python 2.4 looks great IMHO.

Re:18 Months

[MikeBabcock]

Its not that they're hard to parse, its that they're unnecessary and ugly.

if (x == y)
{
if (!do(something))
{
printf(failuremsg);
return -1;
}
return 0;
}

vs.

if x == y:
if not do(something):
print failuremsg
return -1
return 0

Linus' comments in the kernel's CodingStyle document are relevant too -- try to keep your functions so that you can read most of them on one screen. Python allows you to do this more often (I find) without resorting to strange brace positions.

Re:18 Months

[Anonymous Coward]

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.

Hmm, a work around for Python's syntax choices. Wouldn't be better just to NOT need the brackets? Or to AWAYS need brackets? This leads to cruft. Well it *is* cruft already.

Farewell to OverflowWarning - as documented in PEP 237, Python no longer generates OverflowWarnings.

Haven't read the PEP ... does this mean Python finally does the sensible thing that Ruby does and uses arbitrary-precision integers when needed?

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)

More syntax cruft.. gotta love it. Or not. Remember when they said python "reads like pseudo-code"?

By the way, is it possible yet in python to import arbitrary pathnames yet? Like "import /some/path/somewhere.py". I remember fondly my struggles with the "imp" module a few months ago. I did reduce my solution to 3 dense lines, I'm proud!

Re:18 Months

[ReelOddeeo]

Linus' comments in the kernel's CodingStyle document are relevant too -- try to keep your functions so that you can read most of them on one screen. Python allows you to do this more often (I find) without resorting to strange brace positions.

My functions do each fit on one screen.

For any sufficiently large definition of screen.

Re:18 Months

[Stephan Schulz]

Linus' comments in the kernel's CodingStyle document are relevant too -- try to keep your functions so that you can read most of them on one screen. Python allows you to do this more often (I find) without resorting to strange brace positions.

Good advice from Linus (and shared by a lot of other people). But the one-page limit is a rule of thumb about how much complexity to put into a single function, not how many lines. Having 80x25 full of white-noise Perl is not good (let alone the 96x62 I manage with my emacs).

Of course having a more compact syntax (and more powerful language constructs) helps keeping the nominal line count down. But unless you manage to keep the semantic complexity down, you only get a very small part of the benefit - seeing the whole function at once. The bigger part - breaking the design down to a managable level - comes from limiting complexity, not line count.

Re:18 Months

[Boronx]

try to keep your functions so that you can read most of them on one screen.

Or just print it out when you want to examine it.

Re:18 Months

[Spaceman40]

In truth, Python's whitespace setup is more difficult to parse - it is much easier to parse brackets and ignore all whitespace. Try it sometime :)

Re:18 Months

[davegaramond]

I'm sorry to sound trollish, but if that's the best the Python folks can do in 18 months, I'm disappointed. Those things you mentioned (except maybe decorators) are mostly minor, hardly "worth the wait of 1,5 years"! Syntax enhancement for import, big deal. A new command line option, yawn. No OverflowWarning, well that's the consequence of transparent int-bigint conversion. Etc.

I'm sure there are many improvements and new features in the included libraries ("batteries"), but as far as the language goes, little interesting new stuff I say (again, except for decorators which is quite controversial).

Where's Python 3000 anyway? When will we see it, if ever?

Re:18 Months

[asdfghjklqwertyuiop]

In truth, Python's whitespace setup is more difficult to parse - it is much easier to parse brackets and ignore all whitespace. Try it sometime :)

I did. And I disagree. I find that indentation makes the biggest difference in readability. Not only that, but the opening brace is moved more out of the way if you put it on the same line as whatever statement opens it (ie, not K&R style).

Re:18 Months

[MikeBabcock]

He didn't say readability -- he said parse, as in for the machine.

The original poster assumed that whitespace was used instead of squigglies because of parsing on the part of the interpreter, but its used for readability whereas squigglies are actually designed to make the compiler / interpreter's life easier.

Re:18 Months

[MikeBabcock]

Someone moderate that as funny ... ... please.

I worked with someone who printed reams of paper every time he wanted to look at his source code. It would just kill me to watch.

I read my source on-screen, with tracing tools to find where a variable was last used, what else referneces a function, etc.

Again, I hope that was intended as funny.

Re:18 Months

[MikeBabcock]

Agreed, and very much so.

That's another reason I love reading other peoples' Python code. Even if they have no idea what they're doing, the syntax almost forces them to keep the complexity of any given section to a dull roar.

I've seen some insanely complicated Python code, and perhaps an obfuscated Python contest would show us more, but I believe its more difficult to achieve than in languages like C and PERL. At the very lease, the language dissuades such behaviour.

For example, this site mentions the following example:

cmath.sqrt((reduce(operator.add, [i**2 for i in l], 0)-(reduce(operator.add, l, 0)*reduce(operator.add, l, 0)/len(l)))/(len(l)-1))

That isn't half as bad as some of the "normal" PERL I've seen.

See also these suggestions.

function decorators

[koi88]

Finally I can make my functions so much prettier.

Re:function decorators

[nijk]

Actually, I find decorators to be quite ugly. :-(

Re:function decorators

[MikeBabcock]

I concur ... but I just won't use them in all likelihood.

If I run into code that uses them, that's another story.

Re:function decorators

[sjames]

Actually, I find decorators to be quite ugly. :-(

Definatly avoid the decorators that want everything in gold, green, brown, and orange. That's SO '70s

OK Trolls...

[Anonymous Coward]

If you can keep your "significant whitespace sucks" comments as children of this one, I'm sure everyone will get along just fine...

Re:OK Trolls...

[TychoCelchuuu]

Significant whitespace sucks? Blasphemy. I add significant whitespace even when it's not neccesary!

Re:OK Trolls...

[rhaig]

whitespace, when used correctly, makes code readable. However, having the inability to be flexible with the use of that whitespace bugs me.

coding standards make good code, not a language. I can write bad python just as easially as I can write good perl.

Re:OK Trolls...

[nkh]

I read two Python books and (I still don't like this language but) whitespace is not one of its problems. You have to admit it's very confusing for n00bs (especially if you look into some real OSS programs) but it's definitely no more an issue after one chapter of a good book.

Re:OK Trolls...

[NardofDoom]

Example: Say you're debugging a script on an 80 character wide TTY display. Do you really want to go through each line, scrolling all the way to the end because your language has significant whitespace?

Just like a Wookie on Endor, it doesn't make sense.

Re:OK Trolls...

[grumbel]

One of the biggest drawback of the whitespace issue is that you don't get a real lambda in Python for basically just that reason. The lambda that is in Python is limited to a single expression (ie. single line) and thus beside trivial stuff completly useless. Naming functions kind of really sucks if all you wanna do is something very little.

The whitespace issue makes of course other things like copy&paste a whole lot harder too.

Overall I just wish they would introduce some kind of construct to get away from thet whitespace issue be it {}-blocks or whatever, but its probally to late for that now. Lack of Whitespace is one of the reasons I prefer Ruby, while it has some uglynesses by itself, it doesn't feel like I am always punished by the language.

Re:OK Trolls...

[pclminion]

Do you really want to go through each line, scrolling all the way to the end because your language has significant whitespace?

There is absolutely nothing that says you can't break things across lines. In most cases you don't even need a backslash to escape the linebreak. TRY the damn thing before criticizing it.

Re:OK Trolls...

[Anonymous Coward]

Don't forget that the main purpose of a lambda construct is to create anonymous function objects. If you had to name every function that you dynamically create, you'd be screwed, because there's no guarantee you wouldn't eventually get a name collision, especially when you combine your code with somebody else's.

Re:OK Trolls...

[garaged]

I can see you code on windows :-) Use Vim for the sake of god !

Re:OK Trolls...

[Anonymovs Coward]

Just what does that restriction to a single expression have to do with whitespace? Or are you unaware that a line can be split with a backslash? Lambda as a concept comes from functional languages. In purely functional programming, there is no statement separator because there is only one statement because functions don't have side-effects. In other words, if only the last function evaluation counts, results of previous function evaluations are thrown away, and every function evaluation takes input and returns output without changing the state of the world in any way, there is no situation where you need to execute multiple "statements" with separators. That, of course, is a very different approach to programming, but it's fun and I found it surprisingly intuitive and productive after the initial what-the-heck feeling: try it. (Sometimes you do need functions with side-effects like print statements, but you don't need them in a lambda definition.)

Re:OK Trolls...

[asdfghjklqwertyuiop]

Example: Say you're debugging a script on an 80 character wide TTY display. Do you really want to go through each line, scrolling all the way to the end because your language has significant whitespace?

Uh, no, I don't... which is why I'm glad this is perfectly valid python syntax:

a = [1,2,3,
4,5,6,
7,8,9]

def somefunc(s1,s2,s3):
print "1 "+s1+"\n"+ \
"2 "+s2+"\n"+ \
"3 "+s3+"\n"

somefunc("as","df",
"gh")

Re:OK Trolls...

[NardofDoom]

Say it's someone else's script. You'd have to write another script to process the original script to add the escape characters where they're needed and regular linebreaks where they're not.

And I still think that if there's not a visible character there, it shouldn't mean anything. It goes against logic: Nothing isn't something.

Re:OK Trolls...

[rhaig]

which is exactly why I say that "the inability to be flexible with the use of that whitespace bugs me."

and as for 80char wide tty displays, all but one of my xterms is 80char wide. (out of 14 open at the moment) And while I'll admit that an xterm is morefunctional a display than a VT52, or whatever ASCII head you have on your serial port, there's not much I'd do on the xterm that I couldn't do on the console besides cut & paste .

Re:OK Trolls...

[asdfghjklqwertyuiop]

Say it's someone else's script. You'd have to write another script to process the original script to add the escape characters where they're needed and regular linebreaks where they're not.

Someone else's script? Written in what, python? Well then I don't need to process anything. It is either valid python or not. If you're just talking about including some pre-formatted text into a python script, then just enclose it in a multi-line string (which in python are inclosed by """ (three double quotes in a row)).

And I still think that if there's not a visible character there, it shouldn't mean anything. It goes against logic: Nothing isn't something.

I used to believe python's whitepsace-sensitive C syntax would really get on my nerves if I ever tried python, since I'm used to C and perl. Like many people, I wouldn't even give python a shot because of that whitespace issue. But one day I did because I needed to help a friend, and I actually found the language quite pleasant.

The whitepsace sensitivity didn't get in my way like I thought it would (which is to say it never got in my way, I didn't even notice it). Python's rules for whitespace are quite logical and intuitive and follow the way you're already used to indenting for readability in C or perl. When I started using python, I didn't even have to learn how the whitespace worked like I would have to learn any other syntax. The whitespace rules already worked the way I always programmed, so once I started python I had no trouble at all.

Re:OK Trolls...

[magefile]

I can write bad python just as easially as I can write good perl.

You're right - both are impossible. :-)

Re:OK Trolls...

[rhaig]

at least you're posting in the troll thread. Because if I could moderate here, it would be either troll, or funny. (probably funny since you appropriately smiley faced it)

but on a more serious note, it's worth mentioning that the quality, readability and re-usability of the code has very little to do with what language it was written in, and much more to do with the bad or good habits of the auther of that code.

Re:OK Trolls...

[rhaig]

and certainly has nothing to do with the ability of the author to spell :P

Re:OK Trolls...

[grumbel]

### Just what does that restriction to a single expression have to do with whitespace?

A lot, since you can't simply include a code block whereever you want. If you search the list archives a bit you will find plenty of discussions that basically boil down to whitespace being one of the major issues why Python does not have anonymouse functions.

Functional programming is a whole different issue and doesn't have anything todo with this.

Re:OK Trolls...

[Capsaicin]

Significant whitespace sucks? Blasphemy.

It sure is if you are a Whitespace programmer!

Re:OK Trolls...

[magefile]

Which is why I put the smiley ... it's like saying "vi is better than emacs". Although I personally found python easier to learn than Perl, although that may be because I hate reaching up to the top row for @,#,$, etc (I have very short fingers).

Re:OK Trolls...

[rhaig]

but isn't vi better than emacs??
<duck>

Re:OK Trolls...

[magefile]

I wholeheartedly agree. And it's more Unix-ish (smaller programs that do one thing well). But my point was ... no one takes that argument seriously anymore. And you forgot the "/" in your closing tag.

heh

[boschmorden]

import overlords

print "I for one welcome our new %s overloads.!" % overloads.get_random()

Re:heh

[TeknoHog]

$_=~s/loads/lords/g;

Re:heh

[wormbin]

<analGeek>

1) overlords != overloads

2) unless overloads.get_random() returns a list containing a single string element you're in for a runtime error.

Of course if you wrote this in a compiled language you'd know this buy now. *ducks*

</analGeek>

Re:heh

[gotgenes]

1) buy != by
2) Of course, if he was using the Python interactive interpreter, he would have known this without even having to wait for it to compile! :-D

Re:heh

[pclminion]

2) unless overloads.get_random() returns a list containing a single string element you're in for a runtime error.

No, the string substitution operator can take a non-sequence if there is only a single substitution. Come on, a 5 second experiment would have proven this:

>>> print '%d' % 66
66

I didn't have to stick '66' in a list.

Re:heh

[say]

Of course if you wrote this in a compiled language you'd know this buy now. *ducks*

buy != by.

Re:heh

[TildaBang]

...Until your children are assimilated into the collective.

Re:heh

[Anonymous Coward]

2) unless overloads.get_random() returns a list containing a single string element you're in for a runtime error.

Bzzzzt! If it returned a list, it would print the string reprentation of that list (eg. "['somestring']"), not of the member. You probably meant a tuple. But you don't need an explicit tuple with a single value. Try this:

print 'hello %s' % 'world.'

On the other hand you could argue that the design of the module overlords is more complicated than warranted, why for instance is it defining a separate 'get_random' function, when we could use a simple list of overlords along with the standard random module. eg

import overlords, random
print 'I for one welcome our new %s overlords' % random.choice(overlords)

department of redundancy dept.

[Anonymous Coward]

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.

Just in time for Xmas!

[FooAtWFU]

No! It's the Christmas season, so decorations are in right now! We should all get the new version of Python and decorate our source code to celebrate the spirit of holiday cheer!

cue grumbling about how Christmas is overcommericalized+etc

genexps

[ultrabot]

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.

Re:genexps

[percivall]

Yeah, generators do kick ass.

But it's important to remember that generator expressions are slower than list comprehensions. This is mainly because functions calls are expensive in Python, and when dealing with generators each iteration means one more function call.

Re:genexps

[Anonymous Coward]

Generators in general kick so much ass it's not even funny.

Heh, what's funny is when old stuff gets re-invented and people think it's something new and exciting.

Ever used continuations? Generators are just *one* thing you can do with first-class continuations.

Re:genexps

[Anonymous Coward]

But it's important to remember that generator expressions are slower than list comprehensions. This is mainly because functions calls are expensive in Python, and when dealing with generators each iteration means one more function call.

Python doesn't have a list splice operator like Lisp or MOO -- well it does, unary *, but it's really quite crippled (perl splices implicitly, no idea about ruby). A list comprehension would return a list and not splice it into the args, so you'd have to use "apply", which is more indirection.

The above example is really kind of silly. A more real world example would be more like:

# strip out lines starting with a !
for line in (l for l in sock.read_line() if line[0] != "!"):
print("> " + line)

Also, iterator and generator resumption is faster than a function call.

Re:genexps

[Pxtl]

Wow, generators, decorators.... how much more linguistic cruft is it gonna take before they just give up and implement Ruby style blocks? It seems like 90% of these are created because lamdba sucks and def isn't anonymous.

Re:genexps

[ultrabot]

It seems like 90% of these are created because lamdba sucks and def isn't anonymous.

Uh, you do realize that generators have nothing to do with anonymous functions, and that it's rather a simplified, understandable approach for providing coroutines? Generators are significantly more powerful than Ruby code blocks.

Re:genexps

[CoughDropAddict]

At a language level, it's true that generators don't have anything to do with lambda or code blocks. But when you consider what these features are used for, there is some overlap.

Consider the example you gave:

print sum(obj.count for obj in list_all_objects())

In Ruby, you can accomplish the same thing by writing:

print (objGenerator.map { |obj| obj.count } ).sum

where "objGenerator" is an object that mixes in the "Enumerable" module. An even better way (that really avoids building an intermediate list, even of integers) is:

a = 0
objGenerator.each { |obj| a += obj.count }
print a

There is one thing that generators give you that blocks can't, that is very, very cool. With a generator, you can create programs with a pipeline architecture, where different steps of the pipeline all can be written as if they have the main loop.

Imagine you are writing a compiler. You could write (be easy on my syntax, I haven't written Python in a while)

def lexer(input):
state = STATE_BEGIN
ch = input.read(1)
if state == STATE_BEGIN:
if ch == '(':
yield TOKEN_LEFT_PAREN
(...)

def parser(lexer)
token = lexer.get()
if token == TOKEN_LEFT_PAREN:
yield parse_expr(lexer)
# gobble TOKEN_LEFT_PAREN
lexer.get()
(...)

The beauty is that both your lexer and your parser can be written as if they have the main loop, and all they have to do is yield a token/expression when they find one. In reality, it's pipelined and you get the efficiency of not having to build up the entire list of tokens before you start parsing.

Re:genexps

[CoughDropAddict]

Oops, I realized that probably the best way to do this in ruby is to use inject:

print objGenerator.inject(0) { |sum, value| sum + value }

No intermediate list, and you don't have to rely on having a function like "sum" defined -- it could be any operation.

You could also add this to the "Enumerable" mixin:

module Enumerable
def sum
return inject(0) { |sum, value| sum + value }
end
end

Now you can call "sum" on any object that implements "Enumerable", and the example becomes:

print objGenerator.sum

Re:genexps

[poincaraux]

Also, iterator and generator resumption is faster than a function call.

Yup. Like the PEP says,

Early timings showed that generators had a significant performance advantage over list comprehensions. However, the latter were highly optimized for Py2.4 and now the performance is roughly comparable for small to mid-sized data sets. As the data volumes grow larger, generator expressions tend to perform better because they do not exhaust cache memory and they allow Python to re-use objects between iterations.

I think I know where the OP got the idea that genexps would be slow .. function calls are slow in Python .. in things like for loops, but not in places like genexps and maps. It's a good idea to test something out before you make claims about its speed.

Re:genexps

[Anonymous Coward]

> Wow, generators, decorators.... how much more linguistic cruft is it gonna take before they just give up and implement Ruby style blocks?

Maybe when ruby gets list comprehensions? yes, python's lambda sucks. Even Guido thinks so. Basically, python backed itself into a corner with its whitespace, which is what keeps it from effectively having blocks: the formatting would be brutally nasty, something like using Haskell's layout rule in the middle of a non-layout-rule section. Haskell doesn't have this problem because it *has* optional delimiters and brackets ... of course, having no statements also helps (semicolons in do blocks get turned into >>=\x-> sequences by the compiler)

Re:genexps

[matusa]

Ruby iterator blocks can be passed to functions which use yield in an identical fashion to pass control over to them with any desired parameters. Note that doing this from within a C module intended for use within ruby is similarly trivial (rb_yield()).

Re:genexps

[CoughDropAddict]

Ruby iterator blocks can be passed to functions which use yield in an identical fashion to pass control over to them with any desired parameters.

It's not an identical fashion.

Yes, you can yield to a block, passing it values. All you've really done is make a function call to an anonymous function.

What you can't do is pull the values the function yields, one by one.

Let's define a simple fibonacci generator:

def fib_generator():
a, b = 0, 1
while 1:
a, b = b, a+b
yield a

It's true that you could create a similar type of thing in ruby:

def fib_generator
a, b = 0, 1
while true
a, b = b, a+b
yield a
end
end

However, there's a big difference in how you can use them. Let's say we want to print the next fibonacci number to the screen every time the user presses the "n" key. In Python, we could do something like this in the main loop:

if ch == "n":
print generator.next()

However, with Ruby we can't do this. The best we can do is:

fib_generator { |n| puts n }

But this is unacceptable, because we only want to get the next fibonacci number in certain circumstances. Yielding to Ruby blocks is only appropriate when you know you want to fetch every value the function will yield in one fell swoop. All the code that is part of this iteration has to be in one anonymous function! Imagine my lexer example using Ruby blocks:

lexer(input_stream) { |token| the_whole_freaking_compiler(token) }

Do you really want to have to write a compiler function that gets called once for every token? That has to save all of its state between subsequent calls? That has to awkwardly communicate the results of the compilation by either returning it through the lexer function, or otherwise through side effect?

Generators/coroutines really are cool, and something that I really wish Ruby had (and this is coming from a huge Ruby fan).

Re:genexps

[Abcd1234]

Don't you mean Smalltalk-style blocks?

Re:genexps

[davegaramond]

Oh, and Ruby does have continuations, and that can be used to implement generators and coroutines if you want.

Re:genexps

[davegaramond]

First of all, Ruby doesn't need generators since it has proper closures.

Second of all, it's trivial to implement generators/coroutines using continuations in Ruby. Using the Fibonacci example:

require 'generator'
g = Generator.new { |g|
a, b = 0, 1
while true
a, b = b, a+b
g.yield a
end
}
p (1..10).collect { g.next }

will print:

[1, 1, 2, 3, 5, 8, 13, 21, 34, 55]

Don't bash Ruby if you know next to nothing about it.

Re:genexps

[julesh]

Consider the example you gave:

print sum(obj.count for obj in list_all_objects())

In Ruby, you can accomplish the same thing by writing:

print (objGenerator.map { |obj| obj.count } ).sum

Sorry, but I think the Python example is a lot more readable. I'll admit I've never programmed Ruby, but even if I hadn't programmed Python I'd be able to look at the Python code and figure out what it did. I can't say the same for the Ruby code. The "|var| var.something" syntax is rather non-intuitive, I think.

Re:genexps

[the quick brown fox]

Sorry, but I think the Python example is a lot more readable. I'll admit I've never programmed Ruby, but even if I hadn't programmed Python I'd be able to look at the Python code and figure out what it did. I can't say the same for the Ruby code. The "|var| var.something" syntax is rather non-intuitive, I think.

It may be rather non-intuitive for a programmer with a C/VB/Java background (which, admittedly, is almost all of us) but a functional programmer will feel right at home.

Anyway, once you get used to the block syntax (and it doesn't take long), the above is very readable. Blocks are worth taking the time to get used to; they're a great answer for a very large number of common problems, not just iteration and list comprehensions.

Re:genexps

[CoughDropAddict]

Interesting... that's close to what generators provide. That solution preserves the lexical environment between calls to the generator, but what it doesn't preserve between calls is the control flow.

Let's say I want to create a generator that reads a stream of numbers, character-by-character, and for each number will yield that many dashes. As a Python generator:

def dash_generator(int_producer):
try:
while 1:
i = int_producer.next()
for x in range(i):
yield "-"
except:
# no more ints from int_producer
return

Every time you yield a dash in that loop, the current state of the routine is frozen, including how far you are into the "for x in range(i)" iteration.

Re:genexps

[Anonymous Coward]

I agreed with your post up until the last line:

Don't bash Ruby if you know next to nothing about it.

Such a statement just makes you look like an asshole.

Re:genexps

[pthisis]

Stackless python supports full continuations.

generator expressions?

[deathazre]

2,500KVA @ 0.8 PF? (note: some electrical background required to appreciate the above)

Re:generator expressions?

[provolt]

It usually quite easy to see when people reach a true understanding of power factor. That moment comes when they start making plans on how to run their air conditionary completely on imaginary power.

Air conditioner modification plans and a funny professor were what made those classes bearable.

Re:generator expressions?

[BovineSpirit]

Occasionally heard on London's Oxford Street: "How did they get those generators up there? And how do they refuel them?"

On Decimal and floating point

[Frater 219]

The What's New document gives a somewhat inaccurate description of the importance of the Decimal type. Naturally, switching from binary to decimal changes which fractions can be exactly represented, but it does not change the fact that some cannot.

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.

Re:On Decimal and floating point

[mwlewis]

Actually, decimal arithmetic is more accurate than binary. Any binary fraction can also be represented in decimal, but not all decimal fractions can be represented in binary, since 2 divides 10 evenly, and 5 doesn't divide 2 evenly.

Re:On Decimal and floating point

[pkhuong]

So, obviously, we should be using base (apply '* *n-first-primes*). How about 30 or 210? At least it's not an arbitrary base.

Re:On Decimal and floating point

[SamBeckett]

This is why we still have 60 and 360 as common bases-- the ancient one's need to avoid confusing fractions.

Incidentally, 60 = 2*2*3*5 and 360 = 2*2*2*3*3*5

Re:On Decimal and floating point

[Frequency Domain]

So, obviously, we should be using base (apply '* *n-first-primes*). How about 30 or 210? At least it's not an arbitrary base.

It doesn't matter which base you use. All your base are belong to us.

Re:On Decimal and floating point

[geg81]

Agreed: decimal representations are pretty useless. You might as well use binary integers and appropriate scaling. And that is what any implementation of decimal arithmetic should be: binary numbers with implicit decimal scale factors.

Re:On Decimal and floating point

[Anonymous Coward]

Actually, I wrote a C program that uses base 3600. It uses fixed point arithmetic in a bit of code that allows registration of time-sequenced iterators over an in-core database. Each second is divided into 3600 parts, which allows the iterators to space themselves at convenient interals like 1/100, 1/2, 1/4, etc. Doing this in floating point is highly error prone and difficult to get right.

Re:On Decimal and floating point

[sjames]

since 2 divides 10 evenly, and 5 doesn't divide 2 evenly.

That's where the scaling comes in. Think of a scaled binary number as (in pseudo C):

struct scaled_number { long int value; int scale; }

The value .5 is represented by value=5, scale = -1. For 50.5, value=505, scale=-1. The only difference from a BCD system is that value =0x1f9 rather than 0x0505.

To print that, you have to convert value to ASCII and insert the decimal (or add 0s) according to the value of scale. It doesn't lose anything due to division by 2. However, it also doesn't provide arbitrary precision that some BCD implementations do.

FORTH has had scaled integers forever.

Re:On Decimal and floating point

[pkhuong]

Or, for arbitrary precision, rationals.

Re:On Decimal and floating point

[Anonymous Coward]

the ancient one's need to avoid confusing fractions.

Who is "the ancient one"? (Or did you mean "the ancient ones'"?)

frozenset

[hey]

Instead of having a special keyword for immutable sets (frozenset) wouldn't it be better to have an "immutable", "final" or "const" keyword?!

Re:frozenset

[ultrabot]

Instead of having a special keyword for immutable sets (frozenset) wouldn't it be better to have an "immutable", "final" or "const" keyword?!

Where would you put that keyword?

s = frozen Set()

where frozen would do some kind of lookup in a table that has a non-mutable equivalent of every class?

That wouldn't make much sense. Providing a freeze() function might be more sensible, where it would always call obj.__freeze__ if applicable, telling the object to lose all the mutability...

Re:frozenset

[Pxtl]

Because that would be consistent. What, haven't you ever used Python? Its no less a hack than Perl, its just a much more legible, better documented hack.

Re:frozenset

[Anonymous Coward]

in short, no.

python doesn't have modifiers for anything else, so it would require syntax changes. Whitespace after a python reserved word seperates it from its expression.

"frozen x = Set()" complexifies things because since day 1, an assignment returns 'None', and 'frozen None' is nonsense.

You could of course write it as a property:

x = Set()
x.become_frozen()

But it's better to consider 'frozenset' as a subclass of 'set' (or vice versa), since 'frozenset' very well fits the 'is a' paradigm, because a frozenset IS A type of set!

Re:frozenset

[xygorn]

You have to be careful with this one. If a frozenset is a set, then it must be able to do everything that a set can. This means that set can' t have any methods that modify it. Otherwise, if a frozenset object were used as a set object polymorphically, then the code might call a modifying function on the frozenset. I think the vice-versa might work better, since a set should be able to handle anything that a frozenset can. But then of could you lose the intuitive appeal of IS-A. Maybe there should be set, with mutable set and frozen set as subclasses.

Re:frozenset

[Abcd1234]

Actually, that's the way NeXTStep is set up. For example, you have NSString, which is a subclass of NSObject, and you have NSMutableString, which is a subclass of NSString. Definitely more logical, IMHO. And I think it actually conforms better to the IS-A relationship, but I suppose that's a matter of perspective. :)

Re:frozenset

[Anonymous Coward]

Instead of having a special keyword for immutable sets (frozenset) wouldn't it be better to have an "immutable", "final" or "const" keyword?!

NO!!!

Re:frozenset

[the quick brown fox]

In a language that uses duck typing, does this really matter?

(Not rhetorical... I'm really asking.)

I *want* to be enthused, but...

[danielrm26]

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

Alas, there just isn't that much of a reason for me to since most of what I want to do can be done with Bash. This is a reality I don't want to face.

Re:I *want* to be enthused, but...

[donniejones18]

What were Linus' comments?

Re:I *want* to be enthused, but...

[Anonymous Coward]

Someone elaborate a little? Maybe even give us a link?

Re:I *want* to be enthused, but...

[Anonymous Coward]

Let me paraphrase you : "I *want* to be enthused, but ... someone told me not to be."

Way to have a backbone, kiddo.

Re:I *want* to be enthused, but...

[ultrabot]

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.

Re:I *want* to be enthused, but...

[nb caffeine]

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)

Re:I *want* to be enthused, but...

[Anonymous Coward]

then you don't want to do much.

Re:I *want* to be enthused, but...

[Chris84000000]

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.

Re:I *want* to be enthused, but...

[egarland]

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.

Re:I *want* to be enthused, but...

[oexeo]

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.

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"

Re:I *want* to be enthused, but...

[Anonymous Coward]

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.

Re:I *want* to be enthused, but...

[abigor]

Very insightful comment. Many people around here will consider what you said heresy, of course.

Re:I *want* to be enthused, but...

[Ebon Praetor]

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.

Re:I *want* to be enthused, but...

[carlosh]

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.

Re:I *want* to be enthused, but...

[ceeam]

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

Re:I *want* to be enthused, but...

[pclminion]

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.

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.

Re:I *want* to be enthused, but...

[ceeam]

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

Re:I *want* to be enthused, but...

[oexeo]

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

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.

Re:I *want* to be enthused, but...

[ceeam]

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

Re:I *want* to be enthused, but...

[geg81]

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.

Re:I *want* to be enthused, but...

[ceeam]

[[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()" :-)

Re:I *want* to be enthused, but...

[Zaak]

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

Re:I *want* to be enthused, but...

[Lumpy]

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.

Re:I *want* to be enthused, but...

[danielrm26]

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

Re:I *want* to be enthused, but...

[danielrm26]

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.

Re:I *want* to be enthused, but...

[titusjan]

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.

Re:I *want* to be enthused, but...

[Anonymous Coward]

There are strong theoretical reasons why you can't replace a C-like language with a Python-like language, mostly doing with the fact that creating hardware to do that sort of thing is hard. C maps pretty much exactly to the sort of operations that modern processors can provide and provide fast, while higher-level languages need to do things like garbage collection, which aren't implemented at a primitive level. Which means you need to implement the garbage collection in something, and it's probably going to end up being a low-level language.

While C isn't even an ideal low-level language, the installed base of programmers and software infrastructure is so large that switching to a new "perfect" language just for the purpose of system programming would not be justifiable. System programming is hard and essentially a fringe activity, and you're not going to get a bunch of code monkeys doing it just because the language changes (well, unless they're getting paid to do it, but then it'll probably turn out like Windows). System programmers are basically coding in high-level assembly most of the time anyway, so many of C's warts (like being able to do pointer arithmetic and all the bugaboos that introduces) aren't annoying to them, they're essential.

Now, I completely agree with you when we're talking about applications, but please, C does and will continue to have its place. Just imagine how portable Python or Perl would be if they had to be written from scratch on each platform--instead, they can leverage the universal support of C to write portable code that compiles, with a little care, everywhere. Compare this to the situation with Java JITs and other languages that implement their own machine language compilers, and which need to be laboriously ported to each new architecture. By using C, somebody else (usually the platform architects) has already done this for you, and in return, the new platform gains access to a huge body of existing code (including Python scripts running on top of C-based Python interpreters).

Re:I *want* to be enthused, but...

[Billly Gates]

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.

Re:I *want* to be enthused, but...

[oexeo]

I thought you meant this:

string hello_world()
{
return "hello world";
}

hello_world();

Which fits your description perfectly

Re:I *want* to be enthused, but...

[Billly Gates]

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.

Re:I *want* to be enthused, but...

[Anonymous Coward]

I prefer perldoc perlstyle. :) I'm not a hard core Perl programmer, but after reading the style document way back when, it looked like the Perl guys tried to make it as easy as possible to preserve C style, with a few extra tweaks, so I just stick to writing my code with my usual C conventions, making a few substitutions for Perl-isms as needed. An Ada programmer might choose an entirely different set of conventions, and a shell script programmer a third, and part of Perl's charm is that it'll embrace that. Now, if your normal programming style is a completely ad hoc spaghetti ball of wax, then yes, because Perl is so free form, you'll be able to do a lot of damage. 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.

Re:I *want* to be enthused, but...

[k.ovaska]

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.

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.

Re:I *want* to be enthused, but...

[Anonymous Coward]

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.

Re:I *want* to be enthused, but...

[Waffle Iron]

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.

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.

Re:I *want* to be enthused, but...

[Anonymous Coward]

It's not that they have blinders on, it's that you can only do so much well. If you had to invent a perfect language that was good at everything, you'd end up with something like Common Lisp or Haskell in which you end up being the only person you know who programs in it. Languages are constantly evolving, and you'll never be able to just standardize on perfection (and standardizing is important). In the end, the most practical approach is probably to provide ways to easily link many different languages together, and use each one for what it does best. So, in your example, tools like Matlab can go back and forth between letting Matlab routines be called from C, and calling C routines. In fact, C is the least common denominator for almost everything, so if you have a C interface, you've pretty much got the world to choose from (although it may not be particularly easy, which is where third party tools to do the necessarily stubs come in).

Re:I *want* to be enthused, but...

[Anonymous Coward]

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

This is quite true, but only in theory. The reality is that nearly any substantial C++ program will end up needing to integrate with C libraries, at which point the programmer will need to understand (e.g.) how strings are handled in C in order to use the library.

Re:I *want* to be enthused, but...

[uid8472]

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.

Re:I *want* to be enthused, but...

[curne]

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

Re:I *want* to be enthused, but...

[ArbitraryConstant]

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

Re:I *want* to be enthused, but...

[CPrimerPlus]

Wow where did you get that Stat? *rolleyes.

Re:I *want* to be enthused, but...

[0racle]

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.

Re:I *want* to be enthused, but...

[slapout]

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.

Re:I *want* to be enthused, but...

[egarland]

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.

Re:I *want* to be enthused, but...

[geg81]

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.

Re:I *want* to be enthused, but...

[mandrake*rpgdx]

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

Re:I *want* to be enthused, but...

[lightspawn]

for new projects, C is a non-starter.

Not into embedded development, are you?

Re:I *want* to be enthused, but...

[m50d]

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.

Re:I *want* to be enthused, but...

[abdulla]

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

Re:I *want* to be enthused, but...

[Zaak]

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

Re:I *want* to be enthused, but...

[Anonymous Coward]

Linus doesn't like any technology developed after the 1970s. Perl, Python, microkernels, etc.

Re:I *want* to be enthused, but...

[ultrabot]

Not into embedded development, are you?

That's exactly what I do, in C++.

Re:I *want* to be enthused, but...

[vrai]

We still produce large amounts of C++ code at my place of work, as do many other banks and financial institutions. It's very fast, sufficently high level to be easy for experts to code in and cross platform. Plus it has an excellent standard library.

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.

Re:I *want* to be enthused, but...

[Anonymous Coward]

interview with linux

"with Linus".

Is it called final because...

[tod_miller]

People say 'Oh, 2.4, Fiiinally, took thier time!'

Like, hordes of old koreans...

This is more infectious that a mutated H5N1 virus! :-)

aargh.

[deathazre]

and of course I managed to forget (again) that comments, being HTML formatted, ignore whitespace.

Re:aargh.

[Anonymous Coward]

and of course I managed to forget (again) that comments, being HTML formatted, ignore whitespace

Can't say the same thing about Python. ;)

Re:aargh.

[Anonymous Coward]

You insensitive clod!

Python annoyances

[Anonymous Coward]

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.

Re:Python annoyances

[Anonymous Coward]

researching a module is part of learning any language, if you are using perl or ruby you have to learn about the modules. if you are using java, you have to learn about the packages, if you are using C, you have to learn about the libraries. learning is an investment. it takes once to learn modules.

learning python modules is easier than in other languages, a lot of times, i don't even have to grab the documentation.

all one has to do is

import somemodule
dir(somemodule) and you can see the classes, functions available. with dir() you could figure out so much so fast. ]

segmond

Re:Python annoyances

[Anonymous Coward]

Try Ruby.. it was designed properly to begin with.

Re:Python annoyances

[kfg]

I find that I write code quickly and then spend an hour researching some module or other. It sure slows down the process.

This is a problem inherent in OOP. It is often quicker to write your own classes (which you then understand innately), at least if you actually understand the mathematics of the problem you're working on, than it is to find and research an existing one.

This degrades the value of the public investment in reusable code.

If Java seems more "intuitive" to you that is a result of the capital investment you've already made in research. In Java too you have to know something is there before you can use it.

KFG

Re:Python annoyances

[hrm]

The decimal type offers a fix for a (very slight) inaccuracy that's inherent with floating point values on a machine level. It's not a programming language "issue" at all.

Having said that, I agree it takes some time to become efficient in Python. I wish/hope (ought to check again) that Python's potentially excellent built-in documentation string system becomes/is more accessible and useful. That'd help a lot with getting to know modules.

I've used 3 scripting languages over the times; I use bash for anything less then 10 lines, never using functions. Perl no longer, as I can learn the language, but my brain can't seem to remember the details longer than about a week --- don't know where the fault lies. That leaves me with Python for everything more than 10 lines.

Re:Python annoyances

[Stradenko]

The function:
help(object)
will display docstrings in a relatively fancy way -- good for when you're figuring stuff out interactively.

Re:Python annoyances

[Anonymous Coward]

Yeah, that's the whole problem with high level languages in general. When I write a piece of C code, sure, there can be obscure bugs, but at least I know the + operator hasn't been overloaded out from under me to do something completely unexpected. Even if it does the expected thing, that's more an assumption on my part unless I actually go through the documentation and read every last proviso of the API. High level languages can be quite dense semantically, which is their whole advantage, but more explicit languages are much easier to prove that they do the right thing. The farther you get from the hardware, the less predictable the whole system becomes. Not to say that therefore everything should be written in assembly, but I find that for serious programming, you should have just a few favorite high level languages and understand them thoroughly, rather than understand many languages poorly.

Re:Python annoyances

[kfg]

. . .rather than understand many languages poorly.

Or even worse, one language poorly, which seems to be the norm these days.

KFG

Re:Python annoyances

[Peter Harris]

Erm, no.. floating point numbers do exactly what floating point binary numbers are supposed to do.

If this is just about 0.1 being printed out as
0.10000000000000001 well, just format it for goodness' sake.

>>> print "%.6f" % 0.1
0.100000
>>> print str(0.1)
0.1

Re:Python annoyances

[lee7guy]

Neat!

I am just starting out with Python and things like this helps a lot.

Is there any similar way to find out what these classes and functions do from within the python shell?

Example:

>>> import time
>>> dir(time)
['__doc__', '__name__', 'accept2dyear', 'altzone', 'asctime', 'clock', 'ctime', 'daylight', 'gmtime', 'localtime', 'mktime', 'sleep', 'strftime', 'strptime', 'struct_time', 'time', 'timezone', 'tzname']

Ok, now I know the time module contains a "strftime" class or function. Is there any easy way to find out how that specific class/function works?

Re:Python annoyances

[Dan Hayes]

Try help(strftime). Or use the excellent library reference instead :)

Re:Python annoyances

[lee7guy]

Thanks, but as far as I can tell, most functions don't have any "help()" included. Or is it my Python installation that has the docs messed up somehow?

>>> import time
>>> help(strftime)

Traceback (most recent call last):
File "<pyshell#1>", line 1, in -toplevel-
help(strftime)
NameError: name 'strftime' is not defined

>>> help('strftime')
no Python documentation found for 'strftime'

Yes, the library reference is really nice, would be even nicer to have it all included in the shell though. :)

Re:Python annoyances

[lee7guy]

Never mind my previous reply, I figured it out. Python shell rocks!

>>> help(time.strftime)
Help on built-in function strftime:

strftime(...)
strftime(format[, tuple]) -> string

Convert a time tuple to a string according to a format specification.
See the library reference manual for formatting codes. When the time tuple
is not present, current time as returned by localtime() is used.

Writing extensions...

[mi]

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

Re:Writing extensions...

[ondelette]

Actually, using SWIG, it is almost trivial to wrap a C++ object in Python.

Re:Writing extensions...

[imroy]

The Boost project has Boost.Python. I haven't used it yet, but the docs make it sound very interesting. It looks quite simple to write base classes in C++ and then subclass them in Python.

Re:Writing extensions...

[William Stein]

One can write extensions in Pyrex, which is a language that is very similar to Python. Pyrex code is converted to C, which is ccompiled into an extension to Python. One can also access any C libraries from Pyrex.

Re:Writing extensions...

[loqi]

I've done a fair amount of work with Boost.Python, and I've been quite happy with it. It used to be a bit tedious to wrap classes with polymorphic behavior, but one of the Boost.Python contributors has written a program (Pyste) to automatically generate Boost.Python bindings. It's not always what you need, but it's flexible enough to be very usable.

Re:Writing extensions...

[pthisis]

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

Are you serious? The first time I created a C extension, it took about 45 minutes to have the base code up and running. It was an SQL driver; supporting all of the Python DBI took several more hours, but in 45 minutes I had basic connect-to-DB/query/get results stuff working.

And unlike my experiences with TCL, it ran fine in concert with other 3rd-party extensions without having to rebuild the interpreter.

Re:Writing extensions...

[yerM)M]

You are using the wrong tools. We use SWIG and the interface is as simple as

mycplusplus.i
%module mycplusplus
%feature("autodoc");
%include "mycplusplusheader.h"

and that is pretty much it. Most of the standard library is supported out of the box and you can easily include special case code. It even handles templates pretty well. Using their new fangled directors, we can even subclass C++ classes in python itself! It also supports java, guile, C#, ruby...

It is really an amazing piece of work.

Re:Writing extensions...

[jkujawa]

If it's easy to write extensions, but the rest of the language stinks, like TCL, is that really a win?

Re:Writing extensions...

[mi]

I did not say, it is hard, I said, it is tedious. Like filling out a form. With TCL's forms taking one page and Python's -- a few.

And I tried both of them (and Perl too). TCL remains my favorite. Simple things are simple, hard things are possible (Perl's motto, actually).

No, I'm not using SWIG or anything like that -- I was never quite satisfied with the automatically generated extensions. They rarely fit the style and philosophy of the language being extended and the generated code is hardly meant to be maintained.

Re:Writing extensions...

[dmiller]

In the last two months I have written my first two Python extensions (and a Perl one). It isn't too hard - it is a little confusing until you get your head around the refcounting and type API, but then it is very easy and quite elegant.

Of course, swig makes is trivial for some tasks, but the code that I was working with wasn't a brilliant fit.

IMO is it a little bit easier to write Python extensions than Perl ones.

Dive into Python

[cbelle13013]

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.

braces?

[rhaig]

has anyone written a module that will allow the use of braces rather than whitespace for code-block separation?

If anyone does that, then a lot of the reasons for bitching about python go away. (my reasons at least)

and I am NOT trying to start a python vs <insert language here> war. Just wondering if it's been done yet.

aside from the braces/whitespace issue, the fact that the debugger is an external module and can be problematic, I really like python. (well, it's been a few years since I used it, but it was nice then)

Pah

[potcrackpot]

Any language I can't do the following in, I'm not using.

$a[0] = 7; $a[1] = 8;
@b = (5 x @a); @c = ((5) x @a);
print "@b @c";

Re:Pah

[ezzzD55J]

Hm, what's so special about that?

Re:Pah

[Anonymous Coward]

python -c 'print "55 5 5";'

Re:Pah

[Anonymous Coward]

Those who do not understand lisp are doomed to re-implement it ... badly.

Re:Pah

[William Tanksley]

So you're an APL fan (of the K dialect, or possibly J)?

-Billy

Re:Pah

[Slick_Snake]

Don't know why you want to do this but ok here you go.

a = [7,8]
b,c = "5" * len(a), ("5 " * len(a))[:-1] c = c[:-1]
print b, c

Re:Pah

[kraut]

I refuse to use any language that would take that as code rather than noise.

Re:Pah

[Anonymous Coward]

That's not equivalent to the Perl code. Your Python version includes a newline at the end of its output.

Re:Pah

[Retype]

python -c "print '55 5 5',"

now you don't have the trailing end line, happy?

OK Trolls...Arthritis.

[Anonymous Coward]

"Significant whitespace sucks? Blasphemy. I add significant whitespace even when it's not neccesary!"

Typing sucks.

Re:In a certain east asian country...

[Anonymous Coward]

This is not about cute. Anyone smart enough, would have python or ruby in their toolbox. Prior to python, I was one of those few who swore by C, I would code anything in C or assembly. C was as high level as I wanted to go, high level langauges for the most part disgusted me. But since I got into python. 99% of my code are python, a few in C. Python is the turbocharger of programming languages.

segmond

Re:In a certain east asian country...

[Justin205]

In Korea, only old people use Python!

In Soviet Russia, Python uses you.

Let the bad "In..." joke wars start!

Don't call me white

[Anonymous Coward]

The connotation's wearing my nerves thin
Could it be semantics generating the mess we're in?
I understand that language breeds stereotype
But what's the explanation for the malice, for the spite?

jython?

[Anonymous Coward]

Any chance jython may be updated, soon? It seems it is two versions behind?

Re:jython?

[julesh]

I believe the author is working on a .NET implementation these days, so probably doesn't have time/the inclination to do it.

Supprised

[bogaboga]

I was supprised that even though a good number of Slashdotters are programmers themselves, http://www.python.org/ was not slashdotted.

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?

Re:Supprised

[Stradenko]

There are many gui widget libraries available for python, and several RAD tools to get into 'em quickly. Try Boa constructor http://boa-constructor.sourceforge.net/ or google for pyglade

Re:Supprised

[Anonymous Coward]

Erm, not sure if this is a joke or not, however, VB is a language and Visual Studio is the IDE. Not sure what you mean by "command line" language, unless you mean there's no good IDE for it. It's just a language. You can create GUI programs, you can create web pages with it, and you can even created compiled Windows programs using Visual Studio .NET.

Re:Supprised

[kirkjobsluder]

Can one tell me why I should learn python and not any other programming language anyway?

Well, some of the things I like about python:
1: tightly structured code.
2: less punctuation.
3: more readable syntax.
4: full OOP from the ground up (in contrast to perl where the OOP is bolted on with references).
5: short production cycle.

Many of these things can be found in other languages as well. So it largely comes down a matter of preference.

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?

Check out tkinter and wxPython.

Re:Supprised

[Anonymous Coward]

Python is no more a command line language than you want it to be. But it is not tied to a GUI either. Most modern toolkits and some not so modern provide bindings for python. For a great example of what you can do with pyton, and also a great altenative to VB. Take a look at eric3 the python IDE. http://www.die-offenbachs.de/detlev/eric3.html

Re:Supprised

[eli173]

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?

Check out tkinter and wxPython.

And if you like KDE, checkout PyQt.

Re:Supprised

[Anonymous Coward]

Not to be too harsh or anything, but if your only programming background is Visual Basic, then all "command line" languages are probably going to be a bit too advanced for you. However, now is a good time as any to learn one. I never really took to Python myself, it seemed too hard I needed to get done when I'm used to manipulating individual bytes (I mainly do system programming), but I've heard good things about Python as a beginner's language. If you plan on doing any serious programming in the future, you should really get familiar with the whole idea of writing source code into text files and running them on the command line. The GUI stuff is mostly just a distraction from the core task of writing working programs (unless, of course, your whole application is a GUI).

Re:Supprised

[Anonymous Coward]

Qt is extremely expensive to use in non-GPL projects on Windows, which reduces its utility greatly in comparison to wxWindows or Tk.

Re:Supprised

[pHDNgell]

Can one tell me why I should learn python and not any other programming language anyway? ...uh, because your brain is actually capable of learning more than one way to do things. Some people even know up to *three* programming languages!

Sarcasm aside, it's not uncommon for me to work in four vastly different programming languages in a single day (usually java, ocaml, python, and C). That's not counting the ``lesser'' languages like sh, javascript, etc...

If I hear people talking about how a language or development environment does wonders for their productivity, I'll give it a shot. I can usually pick up languages pretty fast. I admit it took me a week or maybe even longer before I really ``got'' ocaml, though. But I had a good time trying. :)

I learned python initially because it had the best xmlrpc implementation. My first actual project was one that read a format definition for the tiger database and then used it to parse all of the zip file exports to load them into postgres. I ran it on several machines for about a week with very few errors (my own errors, that is) after spending a couple of hours writing the loader. That impressed me quite a bit for my first use of a language.

Don't look for an excuse to learn something, though. Just do it. Give it some time. If you don't like where it's taking you, then take what you got out of it and learn something else.

If all you know is VB, though, it's going to take quite a bit of learning before you know what a good language feels like.

Re:Supprised

[Anonymous Coward]

I think he meant *through* a GUI, not "make a GUI".

There's plenty of python "dev studio" things. The latest kdevelop supports it natively, and there's also 'idle'. thekompany produces 'blackadder' too.

There's loads of other half-arsed attempts at creating a nice gui, and probably some full-arsed ones that I've not thought of.

Re:Supprised

[Junks Jerzey]

Can one tell me why I should learn python and not any other programming language anyway?

I expect this isn't the answer that true Python devotees would express, but here goes anyway: It's a very high-level, very dynamic, language that's reliably cross-platform.

"Very high-level" differentiates it from Java, which I see as more mid-level. It's also different than Perl 5, which is higher-level than Python in some ways, but convoluted and crusty in other ways (anything involving nested data structures, for example).

"Dynamic" means you can test code interactively, you don't a build process, you don't waste time enumerating things and creating redundant headers and so on.

"Reliably cross-platform" is the key. This is where Scheme and Lisp and Haskell fall down. Lisp has a standard definition, but the community is fractured by there not being a standard implementation. You can argue that diversity is good and all that, but it does tend to hurt overall. Python has a huge number of standard library modules as a result.

Re:Supprised

[m50d]

The reason I love python is that it's a language that doesn't get in your way. If you want to do OOP in it, you can do OOP in it, but you don't have to make everything an object like in java. Ditto for functional programming or anything you want to do, really. Another one: it's the largest language for which there isn't an obfustucated coding contest. And the reason for this is simple: the syntax is such that python programs make sense. I can go back to python programs I wrote six months ago and never ever think "Hey, what was I doing there?". The indentation might look like it would get in the way, but in fact it just saves typing braces, because you'd indent like that for style anyway.
Last one: with python you can do Qt the way it was meant to be done, without messing with moc or declaring slots or anything. Try writing a simple gui program in python and Qt, you won't want to go back.

Re:Supprised

[Tiny Elvis]

"Reliably cross-platform" is the key. This is where Scheme and Lisp and Haskell fall down.

Oh I don't know. I have a ton of code that runs identically on Linux (CMUCL) and Windows (ACL) with a small amount of implementation specific coding. FWIW I am using external libs for writing PDF files and reading/writing ZIPs. The linkage to these libraries is the primary place where there are coding differences, but again they are small and localized.

Re:Supprised

[krumms]

Check out tkinter and wxPython.

Unless you use Linux.

I can't stand tkinter and wxPython - wxPython/wxWidget's GTK implementation seems to use some nasty generic tree instead of GtkTreeView. It's _ugly_ in a big way. tkinter doesn't rely on an underlying toolkit in Linux and is also rather ugly.

I recommend pygtk There's even Windows bindings for it - and the applications look almost native on Windows. IMHO, more 'native'-looking than wxPython on GTK.

I generally find PyGTK to be cleaner than wx too, but that's just my opinion. :)

And then there's PyQT ... but I've never used it before ... anyway, I'm a gnome user ;)

so....vPython?

[frogg320]

Is this going to outdate vPython now? If so, do you think we'll see an update any time soon?

Is it just me?

[digitaltraveller]

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.

Re:Is it just me?

[Anonymous Coward]

python did not remove the easy way of doing things, the newbies can still use the simple syntax to get a lot done, and those who know a lot more can use the advanced features.

segmond

Re:Is it just me?

[Anonymous Coward]

It's not just you.

The "eye opener" for me was reading the Python cookbook. Almost every recipe listed 2-3 ways to do everything, most of them hard to understand and using Python "tricks". Many of them depended on new 2.x features. I realized that there are now two kinds of classes in Python for instance.

The Python community has also grown arrogant like the Perl community. If a newbie writes something that can be re-written with a list comprehension for instance, it's pretty much given that nobody will actually answer his question, choosing instead to re-write his program for him using tricks and shortcuts.

I'm using Ruby almost exclusively for new projects and it just kicks Python's ass up and down the street. Simple, orthogonal, consistently designed to *begin* with, easy to read, small and friendly community.

Re:Is it just me?

[pclminion]

If a newbie writes something that can be re-written with a list comprehension for instance, it's pretty much given that nobody will actually answer his question, choosing instead to re-write his program for him using tricks and shortcuts.

List comprehensions are not "tricks," they are an extremely powerful language feature. Newbies should be taught how to use them, and translating their loop-based code into list comprehensions is probably the best way to do that.

Python can be written from either an imperative standpoint or a pseudo-functional one. Most of the highly skilled Python programmers code in the pseudo-functional style, because it is more efficient and (arguably) more elegant.

Sure, you can get into some pretty scary territory with various combinations of sum(), map(), reduce(), and list comprehensions but that's your choice. I admit that there should not be such a big performance gap between the different styles... This is due to not enough effort being spent on improving the VM.

Re:Is it just me?

[Anonymous Coward]

No. Python was clean, it is no more. Sad, but it seems to be the fate of all successful languages: they lose the KISS principle.

Small really is beautiful.

Re:Is it just me?

[PythonCodr]

No, it's not just you.

I forget what version of Python 1.X I learned on, but it really is starting to feel like it has lost the "fits in your head" elegance it once had.

I'm a systems programmer (20 years), and I look at some of the esoteric additions and think "yeah, that's nice, but... would I try to teach that to a junior sysadmin?" And that's where I think Python begins to lose its original beauty. The early Python versions I worked with were much more readable and understandable, and I had no quams about teaching it to novice programmers as a first language. Now, I take a look at things like generators and the like and think "Where is all that Perl'esque line noise coming from, and do we really need it?" Sure, you can only limit yourself to the basic parts of the language to start with, but it seems to me that what was once considered elegant Python code is now considered verbose...

The march of progress, I guess ... but it makes me wonder if I'll be teaching my kids Python in a few years or looking for a more suitable learning language. Heh ... I wonder if ABC is still around? ;-)

Re:Is it just me?

[Defiler]

Take a look at this, and the very elegant Scheme dialect that was designed to go along with it.
How To Design Programs
One semi-unique feature is that it asks you what your skill level is when you launch the environment, and tailors the feature-set accordingly.
Novices see a simple subset of the language, and experts get the full power inherent in a real-deal Lisp dialect.

Re:Is it just me?

[Jerf]

Or has python strayed from it's original philosophy of 'one best way to do it'?

To a degree, yes. Largely to the extent it has it is a result of backwards-compatibility; while the Python designers do not make the mistake of enshrining reverse compatibility above all else, they do try to avoid gratuitously compromising it.

As a result, as better ways to do things have emerged, sometime the old ways hang around and muss things up. However, for any given version there is always a "core" that you can stick to that is very close to "one best way to do it"... and despite what a first reading tells you, you really don't throw much of the language away.

For instance, while in modern Python you can say either

a = []
for i in range(5):
a.append(i*2)

or

a = [i*2 for i in range(5)]

the latter is the "one right way to do it". Few, if any, new additions truly leave you with two equally good choices.

(One of Guido's examples is the "lambda" statement, but a lot of people, including me, rather like not needing to replace

self.register("event", lambda event: self.keyPressed())

with

def handler(event):
self.keyPressed()
self.register("event", handler)

but hey, that's life. (While that isn't code for any GUI toolkit in particular that is a pattern common to all of them.))

By and large, none of these things have affected the difficulty of learning Python from scratch and using its libraries. It has affected the difficulty of reading other people's code, but I find the alternative, "keeping the language stagnant indefinately", completely unacceptable, and frankly, reading code is hard anyhow. (I was writing code for others long before I was reading other's code.)

In fact, given as that is the alternative, "keeping the language stagnant indefinately", while I concede it is somewhat sad that we can't jump to an optimal language immediately so that nobody ever has to learn anything past their first impression (not sarcastic, that would be the ideal), that doesn't seem to be working for folks. You might try LISP, though, I gather that hasn't changed syntax, much. (Though I also gather mature programs in that language tend to start looking like their own languages themselves, so that just may move the pain...)

Re:Is it just me?

[pthisis]

I realized that there are now two kinds of classes in Python for instance.

True, but only for backwards compatibility. There's no reason to ever use old-style classes, and they are slated for removal in a future version of Python.

If a newbie writes something that can be re-written with a list comprehension for instance,

If that newbie was using map/reduce/etc, it's a good idea to rewrite it--part of the point of introducing generator expressions and list comprehensions is so they can get rid of all those confusing map/reduce/zip/etc functions and simplify things. Like old-style classes, map/reduce/etc are slated for removal in a future version.

Re:Is it just me?

[tungwaiyip]

The 'one best way to do it' mostly mean basic language operations, like iterating over a list. Many recipes in the Python cookbook are really mildly complex utility programs. They are differ in features, complexity, performance and intented use. The are naturally many ways to do similar things. And if you take these variables into account, you will find they are not really doing the 'same' thing.

Since Python 2.x there is a move toward iterators and generators. Rather than seeing this as bloats I would say this Python is maturing to handle real world applications. If you are handling simple data and performance is not an issue, use regular lists. If you writing application to handle arbitrary large data set or performance is an issue, go for iterators and generators. List comprehension is a neat language construct but I don't see any need to rush rewriting anything.

Re:Python is a pathetic language.

[Anonymous Coward]

Why don't you try Ruby? It's like if Python was designed properly to begin with.

Here's your example in Ruby for instance:

puts Dir['/tmp/*']

But...

[Anonymous Coward]

In Korea, only old people use Python.

Re:But...

[Anonymous Coward]

Really?

Re:But...

[Vishruth]

Ah... the follies of youth. And what do anonymous cowards use in Korea? :p

Re:In a certain east asian country...

[Anonymous Coward]

Only old people ..?
Are you talking about north Korea? :)

I think many open-source developers in south Korea are familiar with Python.

Sets in Python

[stdcallsign]

>>> a = set('abracadabra') # form a set from a string
>>> 'z' in a # fast membership testing
False
>>> a # unique letters in a
set(['a', 'r', 'b', 'c', 'd'])
>>> ''.join(a) # convert back into a string
'arbcd'

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.

Re:Sets in Python

[Anonymous Coward]

''.join(a)

Ignoring for the moment Python's bizarre syntax for joining lists...

aren't sets inherently UNORDERED? How can you "join" a set?

Re:Sets in Python

[tuffy]

Sets can operate on anything. But you need to pass in a list of those things to build a set out of, such as:

>>> s = sets.Set(["foo","bar"])
>>> s
Set(['foo', 'bar'])
>>> 'foo' in s
True

Re:Sets in Python

[poincaraux]

>>> a = set(('this','works','with','words','too','this','a lso','works','with','objects','like','numbers',1))
>>> 'this' in a
True
>>> 'that' in a
False
>>> 1 in a
True
>>> '_'.join(str(item) for item in a)
'1_like_this_also_objects_too_words_works_with _numbers'

Re:Sets in Python

[pclminion]

aren't sets inherently UNORDERED? How can you "join" a set?

Simple algorithm:

1. Apply an arbitrary ordering on the elements of the set to produce a list
2. Join the list

What's so frickin' hard?

Re:Sets in Python

[Anonymous Coward]

it works on any type, this is just a contived example

Re:Sets in Python

[slinkp]

I think the point of the ''.join(a) example is simply to show that for many practical purposes, sets can be treated as a sequence with unpredictable ordering. The join method of strings works on anything that looks like a sequence of strings. (Works with arbitrary iterators too as long as they yield strings.)

The "bizarre syntax" was rather controversial. The rationale is that joining is a feature of strings, and thus should be the responsibility of strings, not of every sequence class under the sun. If it were a.join(''), the class implementing a would have to know how to join itself into a string. But with ''.join(a), a's class only needs to know how to represent itself as a sequence or iterator. This is useful in a much more general way.

To me it makes sense from an implementation standpoint, but I do remember at first finding the syntax odd, especially with literals. You get used to it.

Use a toolkit

[gregarican]

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.

Re:Use a toolkit

[Anonymous Coward]

There are GUI toolkits which typically are added on as an extension to something like Python.

Care to name any?

Re:Use a toolkit

[Stradenko]

http://www.python.org/cgi-bin/moinmoin/GuiProgramm ing

Re:Use a toolkit

[Synistar]

Yes, there are some excellent ones too. WxPython is especially good:

www.wxpython.org

Also a simpler toolkit to use that sits on top of WxPython is Python Card:

pythoncard.sourceforge.net

And if you are into GUI builder kits try WxGlade:

wxglade.sourceforge.net

Supporting software in 2.4 format?

[BestNicksRTaken]

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

Good Stuff, but not enough to make me learn it yet

[Onimaru]

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.

lazy question

[hey]

Does it use that new Parot thingie that Python and Perl were supposed to share?

Re:lazy question

[slinkp]

No.

Re:lazy question

[Anonymous Coward]

Dan lost the bet, as reported in http://www.oreillynet.com/pub/wlg/5346 among other places. Parrot wasn't necessarily supposed to replace the CPython interpreter (whose latest version is part of this release) but Python has had multiple language implementations for a long time. At best, Dan was hoping for a status similar to JPython.

Re:lazy question

[chromatic]

No, but Sam Ruby is making really good progress on Pirate, which is Python on Parrot.

Re:lazy question

[idlemachine]

Now, if he was working on Ruby for Parrot, it'd certainly make my search results a lot more accurate... :)

Re:Python is a pathetic language.

[tuffy]

I dare python lovers to write something like that in python in one line.

for f in glob.glob("/tmp/*").sorted(): print f

Though you will need to import glob in a seperate line. But I fail to see how doing trivial things trivially is a helpful measure of a language's usefulness.

Heated Discussion?

[Senjutsu]

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.

Re:Python is a pathetic language.

[sunami]

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.

Also new in 2.4: WinSock 2

[Anonymous Coward]

Since Python first ran on Windows, it used WinSock 1.1. Starting with Python 2.4, the socket module uses WinSock 2.0.. Most users probably won't notice the difference, but WinSock 2 is highly improved over 1.1 and offers many advanced features such as QoS.

Good sir! You have misunderstood.

[Anonymous Coward]

PERL is what happens when you fuse BASIC with a Macro language: maximum flexibility for filesystems. I 3 PERL and use it all of the time for this reason.

Python is the kind of language in which you could develop a small or midrange app without going nuts over mindless "complexity" in the task imposed by the client at the last minute while drinking Starbucks and circling their Jaguar around Central Park waiting for the Opera to start. IMHO.

I would code anything in Python, but I might fix up a library first to give me PERL-like ability on those files, text strings, etc.

Re:Good sir! You have misunderstood.

[Anonymous Coward]

Why do you keep saying PERL, and not PYTHON?

cobol

[hey]

The Decimal type! Finaly Python is catching up to COBOL. Yeah.

Actually, its useful. Every language should have it.

Re:cobol

[gregarican]

Funny. And read the post just below yours. They finally have included Winsock2 support. This is about 5 years after its original release. Sweet.

Re:Python is a pathetic language.

[i_am_pi]

Perl reads like that as well:

print "Hello World\n";
$answer = read_string("What is the answer?");

sub read_string($)
{
$prompt = shift; # could also be ($prompt) = @_
print "$prompt\n";
chomp($answer) = <STDIN>;
return $answer;
}

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.

CommonLisp for the 21st century?!

[geg81]

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.

Re:CommonLisp for the 21st century?!

[Anonymous Coward]

Python looks NOTHING like common lisp.

For once thing is the "big difference" you describe: you can't transparently process code as data. That means no MACROS, which is what makes Lisp so damn powerful.

I think people see "lambda" and they somehow think that Python has something to do with Lisp.

How do you return an anonymous function from a function in Python? How do you build a function at run time? It's not easy or obvious.

Re:CommonLisp for the 21st century?!

[Frater 219]

How do you return an anonymous function from a function in Python?

You don't use lambda. You define a function (with def) under a temporary name and return it. The temporary name is local to the enclosing function, so it doesn't pollute the namespace: Python def differs in this regard from CL defun.

But seriously, Common Lisp is the Common Lisp for the 21st century. It's doing quite nicely; in the past couple of years folks have taken this "old" programming language and added excellent support for all kinds of current needs -- a Web application server (TBNL), a remarkable SQL interface (CL-SQL), general-purpose dataflow programming (Kenny Tilton's Cells), PDF typesetting and generation (CL-PDF, a rival to TeX!), OpenGL ....

(Peter Seibel's Practical Common Lisp is highly recommended for the "modern" programmer interested in this "old" language. Practical examples include spam filtering, an MP3 database, and a Shoutcast server.)

Re:CommonLisp for the 21st century?!

[geg81]

Python looks NOTHING like common lisp.

Python is a lot like CommonLisp: dynamic typing, reflection, eval, lexical scoping, extensive iteration and looping constructs, strings-as-sequences, and on and on.

For once thing is the "big difference" you describe: you can't transparently process code as data. That means no MACROS, which is what makes Lisp so damn powerful.

Go back and read the original papers on hygienic macros: you don't need Lisp syntax or code-as-data in order to have a macro facility as powerful as Scheme's (and Scheme got by for many years without macros anyway). I wouldn't be surprised if Python at some point gets a hygienic macro facility. Furthermore, there is a separate data syntax for Python that takes source that looks very similar to Python code and represents it as a DOM tree.

How do you return an anonymous function from a function in Python?

In the obvious way:

A ``def'' form executed inside a function definition defines a local function that can be returned or passed around. Free variables used in the nested function can access the local variables of the function containing the def.

That part is actually more natural than doing the same in CommonLisp (Python, like Scheme, but unlike CommonLisp, does not have separate value and function slots on symbols).

How do you build a function at run time? It's not easy or obvious.

There are two things you could mean by that. The first is to build it from source or structure. You can do this:

exec "def c(x): return x*x*x"

The second is to build complex functions using functions that take functions as arguments. You do that the same way you do in CommonLisp, since Python supports the same primitives: lexical closures, dynamic typing, and functions that take functions as arguments.

I think people see "lambda" and they somehow think that Python has something to do with Lisp.

I think Lisp zealots incorrectly think nothing that isn't exactly Lisp could even come close. Python, in fact, is very close to Lisp; the two big differences are syntax and lack of macros. Lack of macros can be addressed, and there are separate Python-like syntactic representations of data.

Re:CommonLisp for the 21st century?!

[Anonymous Coward]

But seriously, Common Lisp is the Common Lisp for the 21st century. It's doing quite nicely

Well, it's not dying, but it's not exactly flowering either.

Common Lisp still needs what it has needed for nearly two decades: a cleaned up and thoroughly revised standard. There is a lot of cruft in it that simply doesn't matter anymore these days.

Re:CommonLisp for the 21st century?!

[pkhuong]

Wait. You're saying the standard covers too much? Just ignore the parts that aren't relevant, if you insist...

Re:CommonLisp for the 21st century?!

[Tiny Elvis]

In the obvious way:
A ``def'' form executed inside a function definition defines a local function that can be returned or passed around. Free variables used in the nested function can access the local variables of the function containing the def.
That part is actually more natural than doing the same in CommonLisp (Python, like Scheme, but unlike CommonLisp, does not have separate value and function slots on symbols).

I didn't realize Python supported closures. Can the closure variables be modified or are they read only? Also, using 'def' in a Python function sounds identical to using FLET or LABELS in a CL function. Of course in CL you can also just use LAMBDA.

Also, could you define more than one local 'def' function and return them all? Could they access the same closure variables?

Re:CommonLisp for the 21st century?!

[geg81]

I didn't realize Python supported closures. Can the closure variables be modified or are they read only?

You can't modify them. That's a deliberate decision based on Python design principles (see here for a discussion). Personally, I disagree with the decision because I consider the consequences unintuitive, but it isn't worth worrying about it because it's not a big issue in practice: Python has much less need for them because it supports bound methods, iterators, and comprehensions, and when you really need a modifiable location in the enclosing scope, it's still easy to express. (If you want to talk language cleanliness, I think Python makes up for that wart relative to CL just by treating functions and closures consistently as values alone.)

Also, using 'def' in a Python function sounds identical to using FLET or LABELS in a CL function. Of course in CL you can also just use LAMBDA.

Yes; I would argue, however, that the Python syntax is a bit more natural. Scheme implementations also often support nested DEFINEs.

Also, could you define more than one local 'def' function and return them all? Could they access the same closure variables?

Yes, but you really want to use a class in that case.

Re:CommonLisp for the 21st century?!

[Daverz]

" there is a separate data syntax for Python that takes source that looks very similar to Python code and represents it as a DOM tree."

I'm intrigued about what you're referring to here. Do you have an example?

Re:Python is a pathetic language.

[Anonymous Coward]

Removing all the structure from each of your examples leaves:

For f in glob glob sorted print

Whereas the perl example is

print for each sorted glob

Python introduces unnecessary syntax. Perl lets me get done what i want, in whatever style I want. Python ties you down to it's style.

Perl: Maximum flexibility

Python: Maximum bondage.

Re:Damn

[slinkp]

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.

Re:Python is a pathetic language.

[MC6809]

And don't think that all languages don't have this kind of unreadable code.

Very true. One can even write readable code in PERL if one practices self-control. OTOH, I once wrote the following in Ruby (normally very clean and readable) just because it was conveninet:

df = `df -k /juke`.split(/\n/)[1].tr_s(" ", " ").split(/ /)[3].to_i

Why the Decimal data type is needed

[dstone]

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

Re:Why the Decimal data type is needed

[pkhuong]

No. This shows that interval arithemtic is needed. Why can't I know the precision of results? The printer should be able to know that the value is only accurate to n decimals (or binimals or whatever they're called :), and not print more. We let programs make a mistake that would have made us lose marks in Junior High, and (hopefully? I'm in health now, so I don't know) failed us in College.

Re:Why the Decimal data type is needed

[smallpaul]

No. This shows that interval arithemtic is needed. Why can't I know the precision of results? The printer should be able to know that the value is only accurate to n decimals (or binimals or whatever they're called :), and not print more.

How is keeping track of precision more helpful than merely preserving the exact number that the user typed in? Surely that's what they taught you in high school!

Re:Why the Decimal data type is needed

[pkhuong]

Ok, so not showing 2/3 correctly is all right, since it can't be done in decimal, but 2/5 isn't? When I want results, I want good results, not good-if-they-print-in-radix-10.

Not a Python Programmer...

[pragma_x]

...but I am impressed with the whole funciton-decorator addition to the language.

Function Decorator Proposal/Specification

Its nice to see a language evolve in favor of use without sacrificing readability and overall utility.

Before:

def foo(cls):
pass
foo = synchronized(lock)(foo)
foo = classmethod(foo)

After:

@classmethod
@synchronized(lock)
def foo(cls):
pass

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.

Re:Not a Python Programmer...

[percivall]

The feeling was that it was unnecessary since metaclasses already provide the functionality that class decorators would have provided.

For those of you who aren't Python programmers: Metaclasses are to classes as classes are to instances. At compile-time (at runtime) the metaclass constructor is given the newly created class object for initialization. This provides the possibility for manipulation and more.

Re:Not a Python Programmer...

[Ian Bicking]

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.

Another important part has been Python 2.2's new-style classes and descriptors. Descriptors are basically objects with special methods (__get__, __set__, __delete__). When you access a class or instance attribute, instead of returning the descriptor, the a method of the descriptor is called. This is what allows classmethod, staticmethod, and property, but also a number of other declarative techniques for class definitions. Well, it's one of several things that work together to create interesting new possibilities in Python.

Re:Not a Python Programmer...

[MC6809]

It's refreshing to be see functions treated as objects...

Refreshing how? You should expose yourself to Scheme to see how functions-as-data was really meant work.

sigils sneaking in

[CatGrep]

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

Re:sigils sneaking in

[jkujawa]

Done.

Re:sigils sneaking in

[bill_mcgonigle]

Jumpin' Jesus - Python is now indistinguishable from line noise!

Re:Python is a pathetic language.

[Anonymous Coward]

Perl programmers actually believe any of that any-style-I-like shit is significant? And they wonder why their language is dying...

Re:Python is a pathetic language.

[Anonymous Coward]

What is pathetic is that you think that Perl's use of implicit variables like $_ or its unusual backwards syntax are anything to brag about.

And your understanding of Perl seems to be a tad limited, since the canonical way to write this in Perl would be:

print "$_\n" foreach sort <*>;

If you are going to badmouth another language, at least have a working knowledge of the language you are advocating (even if the language you are advocating is a piece of shit).

Erratum

[garaged]

a = [7,8]
b,c = "5" * len(a), ("5 " * len(a))[:-1]
c = c[:-1]
print b, c

Re:Erratum

[Slick_Snake]

The typo was due to changing how I truckated the extra space. I forgot to remove the c = c[:-1] line so it should have been.

a = [7,8]
b,c = "5"*len(a),("5 " * len(a))[:-1]
print b,c

Re:Python is a pathetic language.

[roju]

Divide-and-conquer. Any program is a sum of many smaller bits. The easier the smaller bits...

Compiled binaries are dirt simple and have been

[jbellis]

google for py2exe.

Re:Compiled binaries are dirt simple and have been

[Onimaru]

Score: 1 Hojillion, Informative

Re:Compiled binaries are dirt simple and have been

[Bugaboo]

Or cx_Freeze, it's easier to use and can make binaries on Windows and Linux.

Re:Python is a pathetic language.

[Omicron32]

import glob; for f in glob.glob("/tmp/*").sorted(): print f

You're still allowed to use ; to break lines.

Try D instead

[GCP]

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.

Re:Try D instead

[Teckla]

I've looked into D and, frankly, it looks amazing. I've often told C and C++ programmers that the natural direction to evolve is D. Still, I'm concerned about the future of D in terms of market acceptance. It's the only thing stopping me from learning D well and trying it out on some projects.

One thing I'd love to see is a "D source to C source" converter. That would reduce my concern enough that I'd start using D, because I'd know I could always "fall back" on the C code if necessary.

Re:Try D instead

[Anonymous Coward]

D looks okay, but just evolutionary, and not much better than C#. Thing is, if you want me to give up snazzy tools like the MSVC debugger and Visual Assist, you better give me a language with a stunningly good feature set to compensate. I'm talking HOFs, pattern matching, currying, and so on. I took a look at Cyclone (which does compile to C, but not C you'd want to touch), but Cyclone is so noisy looking that it makes perl look like python (getting back on topic).

Kids these days....

[Anonymous Coward]

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

/C/assembler/ Assembler programmers know what the computer is doing. C programmers have to guess (assuming they can't read assembler output).

- called Wumpus elsewhere.

Re:Kids these days....

[pclminion]

/C/assembler/ Assembler programmers know what the computer is doing. C programmers have to guess (assuming they can't read assembler output).

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.

Re:Kids these days....

[eidechse]

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.

WTF?

[ArbitraryConstant]

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.

Re:WTF?

[owlstead]

Learn Java and C#? What the hell for? They are too much alike. Just use Java and J# (which is more or less Java 1.4 compatible) and .NET makes sure that you can switch at any time. To learn Java, try Eclipse - easy to install, easy to use IDE and free. Way better than the IDE of .NET (I tried both).

Now to get that Eric GUI installed (missing Qt, SIM - whatever that is - and PyQt, oh well). But I don't think it will go as far with supporting me as Eclipse does. The Python language seems to me too complex to parse the way Eclipse does while editing (try it before you knock it).

Re:WTF?

[ArbitraryConstant]

I'm mostly making fun of the concept that any two languages can satisfy a programmer that wants to be able to do a wide range of things, I'm not actually advocating C# or Java, I just picked them because they're the languages that Management likes to use without actually having an idea of the merits of other languages.

Re:WTF?

[owlstead]

Well, maybe they don't know the reasons, maybe they do. But "Management" has chosen the right languages for most current systems that do not have too much legacy code or a too low level interface in my opinion. Managed code and an up to date syntax is definately a plus. And there are plenty of software libraries available for either. Python of course shares some of these features.

Re:WTF?

[ArbitraryConstant]

"Well, maybe they don't know the reasons, maybe they do."

meh. Depends on the manager I guess.

I've been asked to do stuff in Java that was basically the definition of an ideal candidate for Python. Occasionally the Python advantage is so substantial that I'm able to present a completed project almost immediately (eg within a day) that would have taken weeks in Java, but otherwise they don't listen.

Management wants one language that's good at everything, a standard tool so they don't have to look at particulars. That's damaging a lot of the time.

python - awesome

[hashmap]

In some of my last projects I had to analyze a Perl and a Java program. I programmed a few years in both of these, but now after a year with Python I was truly suprised of how primitive these languages felt.

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:

foreach my $val(@{$G->{spec_val}}) {
...@{$G->{species}} = $G->{dbh}->selectrow_array($G->{sth_species},undef ,$val);
...if(@{$G->{species}}) {
......$G->{spec_label}{$val} = $G->{species}[0]. '; '. $val;
...}
}

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:

for val in G.spec_val:
...G.species = G.dbh.selectrow_array(G.sth_species, None, val)
...if G.species:
......G.spec_label[val] = G.species[0] + ';' + val

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

Re:python - awesome

[pclminion]

Somewhat offtopic, but there's a slight optimization you can make...

Instead of using the '+' operator to concatenate strings, build the entire result at once with the '%' operator:

G.spec_label[val] = '%s;%s' % (G.species[0], val)

This avoids creating and discarding a temporary intermediate result.

Re:python - awesome

[Chandon Seldon]

You came up with an especially python-favored example. Direct access of list data members does end up looking a little weird in perl.

One thing that keeps annoying me about python is the scoping rules. There's three scopes: Global, A Whole Class, and A Whole Function. Even C has block scoped variables.

Another thing that annoys me is the lack of compile time checking. Take two code snippets:

use warnings FATAL => 'all';
use strict;

my $variable = get_some_data_with_side_effects();
$varaible = process($variable);

do_something_else_with($var iable);

versus the closest you can get in python.

variable = get_some_data_with_side_effects()
varaible = process(variable)
do_something_else_with(variable )

When you run that perl code, it doesn't even compile. Perl sees the bug, and won't run the program.

When you run the python code, it seems to work. There's no sign that something's wrong, and you could randomly clobber an arbitrary amount of data with a bug like that.

If the program was a little different, say the misspelling was to the right of the = sign, then python would catch it at runtime and puke... after it had already called get_some_data_with_side_effects() - still not good behaviour.

Re:python - awesome

[hashmap]

You came up with an especially python-favored example.

I didn't come up with it, I actually have to rewrite a long strech of code that looks all like that

When you run that perl code, it doesn't even compile. Perl sees the bug, and won't run the program.

You should put that into context. The auto-vivification (where undeclared variables would just spring into life) was such an atrocious feature that Perl was practically unusable for larger projects. They had to invent something to mitigate that, in this case the strict mode

If you ask me Perl is still in a very sorry shape where variables can be evaluated in numerical and string contexts without any kind of warning.

Python never had that kind of problems to begin with. Unlike Perl, variables have types and therefore programming errors that would be deviously hard to catch in Perl manifest themselves in a very explicit manner.

Re:python - awesome

[Chandon Seldon]

It's possible to write bad code in any language, no competent perl programmer has seriously suggested writing any major software in Perl without use strict since the feature was implemented. I might as well complain that Python is horrible because it allows global variables.

We're not talking about some archaic version of Perl versus the current version of Python.

If properties of any version were open for complaints, I'd get to complain about things like Python (1.x) not having "+=" operators or "there's memory leaks in classes with a __getattr__ method" (fixed in 1.5).

Re:python - awesome

[MikeBabcock]

I use that "trick" all the time myself as well. The string formatting being a syntactical operation is so useful it kills me.

I stopped doing that type of thing in C a long time ago because of allocation issues dealing with sprintf all the time.

Now I can just use:

raise UserWarning("Error %d: %s\n" % (errno, errstr))

... and so on.

Re:python - awesome

[pthisis]

When you run the python code, it seems to work. There's no sign that something's wrong, and you could randomly clobber an arbitrary amount of data with a bug like that.

pylint will easily catch that error (and a lot more). It's trivial to have an import hook that automatically lints modules before loading them.

Re:Python is a pathetic language.

[Anonymous Coward]

You are right. Writing this is just too much for any programmer to bare

tmp_files = glob("/tmp/*)
tmp_files.sort()
for f in tmp_files : print fil

Gotta have a one-liner; otherwise, it sucks, right?

You're not mistaken

[Craig Ringer]

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

float

[Craig Ringer]

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

Doing it now

[Craig Ringer]

I'm doing it now, and I must agree - it's pretty slow going.

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

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

Functional style

[Craig Ringer]

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.

Re:Python is a pathetic language.

[Anonymous Coward]

Perl: Maximum flexibility Python: Maximum bondage.

Yes, that is why you have a choice. Now if you have to maintain code written by other people, you'll appreciate Python's forced structure. I've been there and done that. And how many times have I wanted to whack some Perl hacker on the head who only thought of himself when he was writting his code.

Same in Java

[tungwaiyip]

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.

You need to learn the language before complaining

[tungwaiyip]

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.

Re:Python is a pathetic language.

[tuffy]

You're still allowed to use ; to break lines.

Normallly yes, but using them between an "import" and a "for" triggers a syntax error. Try it yourself and see:

>>> import os;for i in range(0,10): print i
File "<stdin>", line 1
import os;for i in range(0,10): print i
^
SyntaxError: invalid syntax
>>>

Re:Python is a pathetic language.

[Anonymous Coward]

for f in glob.glob("/tmp/*").sorted(): print f

Traceback (most recent call last):
...
for f in (glob.glob("/tmp/*")).sorted() : print f
AttributeError: 'list' object has no attribute 'sorted'

# python -V
Python 2.3.3

Re:Python is a pathetic language.

[Omicron32]

Then I stand corrected. :)

Python isn't too bad.

[mandrake*rpgdx]

But I like Lua better for embedding into apps. And as a lnaguage as well. Pygame is horrible and slow IMHO.

Numerical programming needs an array type

[Latent Heat]

Any serious numerical programming needs an array type. List types based on indirection, whether from Lisp or Python just don't do the job -- too much overhead.

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.

Re:Numerical programming needs an array type

[Anonymous Coward]

Almost all of the (good) Python plotting libs use Numeric and/or Numarray. The more comprehensive ones have less-efficent list based fallback if Numeric is unavailable.

If you're used to matlab, you may find matplotlib interesting.

Re:Numerical programming needs an array type

[Latent Heat]

I guess a lot has happened in the 6 months since I was seriously looking at all of this.

The STSciI is recommending matplotlib which you link to. They had this thing called Chaco -- is that still around?

I see that matplotlib has support for numeric/numarray. I know that the Web sites tell all new users to adopt numarray, but they indicate there is a performance hit for 20,000 array elements and that it is still a work in progress. Any tips on this?

Re:Numerical programming needs an array type

[fperez]

A few things:

1. matplotlib right now will detect both numeric and numarray, and _not_ resort to the sequence protocol. The poster above said this, and while it used to be true, recent versions have removed this limitation.

2. If you are dealing with large arrays, numarray is _far_ more efficient than Numeric. The problem is for those (like me) who need millions of small arrays rapidly created. Here, numarray has significant creation-time overhead which becomes a killer.

3. Chaco continues to be developed by enthought, but it remains for now somewhat under the radar, since it's not really in shape for public consumption. But matplotlib continues to make great strides, and is being heavily used in production environments.

Re:Numerical programming needs an array type

[geg81]

Any serious numerical programming needs an array type. List types based on indirection, whether from Lisp or Python just don't do the job -- too much overhead.

Python "lists" are extensible 1D arrays; there is no extra indirection.

Python is working on arrays -- Numeric and Numarray -- but adoption seems slow in stuff like plot and graphics packages.

Numeric and Numarray are widely used by people who need them and they are great and mature packages. But I think the fact that they aren't used universally is deliberate: if their performance and/or functionality isn't needed for a particular application, it's probably better to stick with regular Python lists to keep things simple.

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 fully agree there. And the way to make that happen is to create more packages. I am writing numerical Python packages and making them available publicly. The more people do that, the sooner we can replace Matlab.

Re:Numerical programming needs an array type

[Anonymous Coward]

Look at SciPy if you are looking for a matlab replacement.

Re:Numerical programming needs an array type

[Anonymous Coward]

SciPy is great. But the real reason people use Matlab is not what is built-in, but all the add-ons and research results other people have published for it. In order to catch up, we need to replicate a lot of those, and then we need to convince others to use Python for their research.

Re:Python is a pathetic language.

[tiptone]

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.

2.4 is built with MSVC 7. Yeah!

[edsterino]

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.

As MSVC 6 is so truly horrible for writing anything advanced (or using Boost ...), 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.

18 months and they hit the release target almost bang on. Way to go!

Difference:

[Anonymous Coward]

Assembly maps one-to-one to machine code while C doesn't map one-to-one to machine code (particularly when high levels of optimization are involved).

Re:Difference:

[pclminion]

Assembly maps one-to-one to machine code

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.

Re:Python is a pathetic language.

[Anonymous Coward]

>>> import os; print [i for i in range(0,10)]

How's that ?

BlackAdder

[kinema]

Many of these things can be found in other languages as well. So it largely comes down a matter of preference.

Check out tkinter and wxPython.

What about BlackAdder from theKompany? I've never used it but I would love to hear from those that have.

No, no, just attach it as a property of the object

[Anonymous Coward]

No No, don't make a new keyword. Just make it an attribute:

myset.immutable = True

It may not be practical, however, to undo a change into immutability. Once immutable, always immutable.

Re:Good Stuff, but not enough to make me learn it

[m50d]

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.

Re:Python is a pathetic language.

[CRCulver]

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:

2.4 is hardly a python at all.

[Anonymous Coward]

I'll match my "Magnificent 7" against your measely 2.4 any day. Finally something to feel good about.

2.4...Bahhhh!

True dat.

[mandrake*rpgdx]

I was just being a smartass.

Re:Python is a pathetic language.

[julesh]

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

Re:Python is a pathetic language.

[pthisis]

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)

Re:Python is a pathetic language.

[pthisis]

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.