Hacker News Reader

> How we'd override "pass" boggles my mind.

An expression that does nothing. Putting `''` in a function is equivalent to `pass` in that it lets the parser do its stuff. `pass` could be a builtin defined as `None` and the behavior would be the same as today, without a keyword.

> Same for break and continue

I'm not saying I know how to replace everything (though I'd probably just remove break and continue, they're nice from time to time but not exactly essential), just that there's a lot of stuff which isn't first-class in Python.

> if, while, and try are effectively atomic, but "for" loops can be redefined by defining an iterator, and with is specified entirely in terms of an interface that allows you to affect what it does too.

I don't get what you're trying to say here.

For loops aren't as magical as "break" or "continue". They are just a particular client for iterators. C has hard-coded for loops. Python's for loops do almost anything you want or need them to do, and indeed, coming at them from a C point of view is really missing the point. Anything conforming to the iteration protocol can be used in a for loop [1], and indeed, if you're feeling evil, code in the for loop can even manipulate the iterator as it goes. Not recommended, but it would work.

"with" is a special statement, yes, but the specialness is all stuff you can access from a first-class point of view, up to and including dynamically creating a class that implements the "with" behavior you want, then using that with "with". Yes, you can't create your own arbitrary special-purpose statements the way you can in Lisp, but neither is it true that "with" is cast in stone such that you can't do anything with it. Write anything that conforms to the "with" protocol [2] and it'll work.

Also "first class" in the sense that you can program them are . (the attribute retrieval operator) and [] (usually the dict-lookup operator, but it can be rewritten to do anything you like for a given object).

Mind you, I'm not saying that Python is as flexible as Lisp, it clearly isn't. But it does not lead to understanding to say that "with" has no "first-class" aspects to it. It occupies a middle-ground between C and Lisp. Python has chosen this approach with due deliberation. You might still not like it after you understand it, but let us damn it for what it is, not for what it isn't.

[1]: http://docs.python.org/library/stdtypes.html#typeiter

[2]: http://docs.python.org/reference/datamodel.html#with-stateme...

You're very cute, but I know what Python is and how it works thank you very much, I've been coding with and in it for years. Doesn't change anything: Python's statements are not first-class objects.

And lisp's got nothing to do with that either.

> You might still not like it after you understand it, but let us damn it for what it is, not for what it isn't.

You… completely missed the point?

>> How we'd override "pass" boggles my mind.

> An expression that does nothing. Putting `''` in a function is equivalent to `pass` in that it lets the parser do its stuff. `pass` could be a builtin defined as `None` and the behavior would be the same as today, without a keyword.

The net behaviour would be the same but actually referencing None in the function body increases the refcount of None and immediately decreases it again.

  >>> def foo(): pass # no function body, after all
  ... 
  >>> def bar(): None # reference to None
  ... 
  >>> def frob(): "" # docstring
  ... 
  >>> import dis
  >>> dis.dis(foo)
    1           0 LOAD_CONST               0 (None)
                3 RETURN_VALUE        
  >>> dis.dis(bar) # incref, decref
    1           0 LOAD_CONST               0 (None)
                3 POP_TOP             
                4 LOAD_CONST               0 (None)
                7 RETURN_VALUE        
  >>> dis.dis(frob) # see "1 (None)" instead of "0 (None)"
    1           0 LOAD_CONST               1 (None)
                3 RETURN_VALUE
  >>> foo.__doc__, frob.__doc__
  (None, '')

I admit the difference is merely an academical one but saying pass is not special is not true.

>Same for break and continue, and mostly raise

These are all escape continuations.

>which unfortunately I don't have a snappy word on hand for

Abstractions?

Io has no keywords; everything is a message. This includes return, break and continue.

Yes, but late-binding everything is not free, or even always a clear win - it's a major language design trade-off, with implications for both performance and compile-time analysis. What happens to existing code if someone changes the meaning of 'return', for example?

You catch changes in the meaning of return that break things because you write tests and monitor your processes (business and OS) so that you know when something goes wrong.

I've never changed the meaning of return, but I easily added a new construct called returnIfError. Instead of having to type the following over and over:

  possibleError := attemptSomething
  if(possibleError, return(possibleError))

I can now type:

  trySomething returnIfError

The power granted by quick iteration of ideas is almost always worth the performance and compile time analysis trade off for the things that I work on.