allowed_usernames = [user.username for user in all_users if user.is_admin()]

List comprehensions were added in 2.0, generator comprehensions were added in 2.4, and dictionary comprehensions came in 2.7

:)

http://www.haskell.org/pipermail/haskell-cafe/2010-November/...

(joke)

  val allowed_usernames = all_users.filter(_.is_admin()).map(_.username)

  val allowed_usernames = for(user <- all_users if user.is_admin()) { yield user.username }

    (map :username (filter admin? all-users))

    (for [username all-users] :when (admin? username))

    all_users.select(_.is_admin).map _.username

    allowed_usernames = user.username for user in all_users when user.is_admin()

    all_users.select(&:is_admin).map(&:username)

    deck = ['%s%s' % (n, s) for s in 'HDCS' for n in '23456789XJQKA']

Also, you can easily shuffle the deck using the standard library.

    import random
    random.shuffle(deck)

As far as "playing catch up with a moving target", I don't see how that's terribly relevant, the end result is still a platform that continues to improve and advance. If the C# code that runs on Windows and mono is still more advanced than, say, Java or Perl, and continues to advance (even though not as fast as C# on Windows alone) then that's still a benefit. Given the advent of monotouch and the coming of monodroid it seems like even a hard-core MS hater could come to appreciate C#.

The problem is that it's not. You can do anything you want when it comes to SaaS using python, ruby, php, node or java. Actually those have huge open source communities with tons of libs available to make work faster. This is not the case of C# and if it ever gets there, it probably won't be any better. So again, I don't see any reason to use it, and plenty of reasons not to and being a "hard-core MS hater" would probably come at the bottom of the list of reasons not to use C#, don't try to justify the lack of interest in MS by some kind of imaginary persecution. But to each his own , if you're happy with it go for it.

Some of them also believe Python, Ruby etc are for kiddies :)

And I agree that it's funny for a Java programmer to be able to read a file with open('bleh').read() instead of that 15 stream buffer stream reader stream whatever line of code.

    for line in open("todo.txt"):
        # do something with line

    [ do_something_to(line) for line in open('todo.txt') ]

String fileContents = FileUtils.readFileToString(new File("blah"));

Still not quite as concise as Ruby/Python/etc though.

But you are right --- I'm definitely not the first developer to have had that "moment of zen" when opening files in Python, but hopefully I'm also not the last.

Sometimes, pressing "view source" in the browser and looking at the HTML will reveal what it was supposed to look like.

I recently learned about them and they simplify a surprising number of simple parsing tasks.

How do you get away with none of this in Python? You need a try/catch block to catch exceptions on open and read don't you? There's no guarantee the file exists, or you have permission, or enough memory to read the file.

And while you don't necessarily need a for-loop to process the data, you often will.

      You need a try/catch block to catch exceptions on open and read don't 
      you? There's no guarantee the file exists, or you have permission, or 
      enough memory to read the file.

That isn't the case most of the times (you cannot get extra permissions to a file, you cannot recover from not having enough memory, and if the file is missing that's a bug).

What usually happens in both Java and Python is that you have a top-level try/catch that catches everything and just does logging.

The difference is that in Java you catch and re-throw the exception, or put the exception type in the method's interface, which IMHO leaks encapsulation. Or just turn everything into RuntimeExceptions with a little compiler-plugin magic.

Either way, checked exceptions are a big fail.

Top-level try/catch blocks that simply do logging and nothing below that may not always be a bad idea, but its usually a sign of a poorly designed app.

And why can't you get extra-permissions or recover from not having enough memory? I've certainly worked on systems with the later, where we catch an OutOfMemoryException and then do some stuff we're required to do -- including in some situations to get memory back (which is for example, why we'll often pre-JIT and keep loaded code required to free up memory).

Checked exceptions are a big fail, but largely because they're a broken way of thinking about exceptions (and why Java was the last major language to have them).

EDIT: I glossed over the fact that you may have been actually getting at which is the requirement associated with checked exceptions. You're absolutely correct there. No argument from me. I wasn't think of that originally, as I'm not a Java dev.

It's optional.

You don't have to catch any exceptions (unlike java), however if you want to you can catch, separately, any one of the dozen exceptions that could be raised (IOError, permission error, memory error etc.).

One reason I love python is that the common use case is easy. 90% of times people read from files they don't need to handle every exception there and then, ergo python makes that possible. This makes python much more enjoyable, productive and easy to use.

In Python, you don't need to add a try/catch block unless you specifically need to do something and continue execution after an exception.

The downside is that it is dog-slow (up until recently, it didn't even use explicit types that were provided and always used reflection under the hood) and has some flaws in its design, which make it a bit unpalatable once you really start getting into it.

The consensus of my office seems to be that Groovy/Grails makes you twice as productive as Java for 2 days, then you loose it all again fixing some stupid, incredibly non-obvious problem on the 3rd.

A 2x speed hit might not be a problem, but for a lot of people (myself included), 50x is way too much of a penalty when you've got options that offer effectively the same benefits with vastly better performance. Maybe things have improved since I last checked it out, but I'm not sure.

Java doesn't need to be ridiculously verbose, others have mentioned much of that verbosity stems from basic functions not being included in the standard library. Python's opening of a file isn't any more elegant than Java's if you look at the code behind open(), it's just abstracted away.

public Date submittedAt;

and set/get it as you would any other variable. Easily one of my favorite things about the framework, and saves my { and } keys work as well.

Also how to do one-liners? ;)

http://python-history.blogspot.com/2009/02/early-language-de...

1. "Open" statements (Pascal):

  IF x 
    THEN s1
    ELSE s2;

  IF x 
    THEN
      BEGIN
        s1;
        s2
      END
    ELSE
      BEGIN
        s3;
        s4
      END

  WHILE c DO s;

  WHILE c DO
  BEGIN
     s1;
     s2
  END

2. "Closed" statements (Algol 68)

  IF x 
    THEN 
       s1;
       s2
    ELSE 
       s3;
       s4
  FI // END IF

  WHILE c DO
     s1;
     s2
  OD // END WHILE

I more like "closed" syntax. But C syntax with it's brackets blocks "{...}" instead of "BEGIN...END" made this less an issue.

  if a == 42: print "Yes" ; do_stuff()

But in some cases, you could use a conditional expression instead [2]:

  x = f() if a == 42 else g()

[2] http://docs.python.org/reference/expressions.html#conditiona...

x = (a==42) ? f() : g();

Which is more readable:

  > condition ? value1 : value2

  > value1 if condition else value2

  > die unless condition;
  > return true if condition;
  > return false
  >     if condition1 && condition2 && condition3;

  > return condition1   ? value1
  >        : condition2 ? value2
  >        : condition3 ? value3
  >                     : value4;

  > return value1 if condition1 else
  >        value2 if condition2 else
  >        value3 if condition3 else
  >        value4

    f() if a==42 else g()

    f() if a == 42 else g()

  x = (a==42) and f() or g()

So I would prefer they were not possible :)

See my last attempt in Feb 2009: http://mail.python.org/pipermail/python-ideas/2009-February/...

lambda x: x*2

http://diveintopython.org/power_of_introspection/lambda_func...

Programmers can learn syntax. Regular humans can't. Both Python and Ruby failed to provide a simple way of building internal DSLs. In Python humans need to be specific about indentation and ":" and in Ruby they need to remember all these stupid sigils.

  Scanner in = new Scanner(new File(filename));
  while(in.hasNextInt()) {
    ...
  }

  Socket sock = new Socket("foo", 10101);
  Scanner in = new Scanner(sock.getInputStream());
  ...

For example, if you have an Integer object (not a primitive int) you should use .equals() and not == for comparison. The == is used for comparing references and not values.

That said, this only illustrates some extra complexity in Java.

Integer a = new Integer(10);

Integer b = new Integer(10);

Integer c = new Integer(1000);

Integer d = new Integer(1000);

a==b is true

c==d is false

Python 2.6.6 (r266:84292, Oct 17 2010, 15:53:05)

[GCC 4.4.3] on linux2

>>> a = int(10)

>>> b = int(10)

>>> c = int(1000)

>>> d = int(1000)

>>> a is b

True

>>> c is d

False

Same reasoning as Java?

Thinking about it now, I would rather the inverse in a language be true, and have == be used for value comparison, and have a more wordy function for reference comparison. In my experience, I feel that its a much more common usage, and would probably reduce errors caused by programmers choosing the wrong operator. The only downside to this is that you then have to override an operator if you want to change equality comparison, instead of a function.

I would suggest an alternate title: "Opinions on something I don't know much about yet."

And yet an evil part of my brain would like to subject you to annotations and spring config xml files. But that can wait till you Python lovers grow up and get a real job !!