4 ms·

Python had them tacked on after the fact (version 2.0 as I recall, or was it 2.2?), they work pretty nicely IMO, as long as you treat functions as first class o

Python had them tacked on after the fact (version 2.0 as I recall, or was it 2.2?), they work pretty nicely IMO, as long as you treat functions as first class objects the whole time you're ok.

stcredzero 17y ago
they work pretty nicely IMO, as long as you treat functions as first class objects the whole time you're ok Clarify this? Also, isn't there some inconvenience due to the indentation thing?
- kingkilr 17y ago
  There's no inconvenience, it reads pretty normally, for example: http://code.djangoproject.com/browser/django/trunk/django/views/decorators/http.py#L22 http://code.djangoproject.com/browser/django/trunk/django/vi...
  - stcredzero 17y ago
    I meant lambdas in particular. Example is too long for a discussion specific to lambdas.
dantheman 17y ago
Python lambdas do not work well, in fact they can only be one line long. For some cases this may be ok, especially if python was were the programmer learned about lambdas, but from those who come from with languages with real lambdas it is quite limiting.
- deleted 17y ago
  [deleted]
- kingkilr 17y ago
  We aren't talking about lambdas, we are talking about closures. Lambdas are simple syntactic sugar for a function definition that has a single expression, closures are a concept to capture the outer scope.
silentbicycle 17y ago
Not really. For one thing, you can't modify the closed over values unless you manually box them in a list, due to scope ambiguity. (This may be fixed in 3.0.) It's a little thing, but it makes code that depends on manipulating closures pretty ugly, discouraging their use. Scheme avoids the issue by having a non-ambiguous syntax (a big advantage of those parens), and Lua avoids it by defaulting to global scope* unless you declare them with "local", which also anchors their scope unambiguously. * Which is actually not a big deal - the global table is just another table, so you can hook its set method to catch unexpected globals (see strict.lua). It's far less trouble than Python's solution.
- kingkilr 17y ago
  Python 3.0 introduces the nonlocal keyword which allows you to assign to closed over names.
statictype 17y ago
Someone correct me if I'm wrong, but, I think it was less of "tacking on closures" and more of getting the lexical scoping issues right. i.e, there was issues with scoping that had nothing to do with closures per-se. When they fixed it, closures automatically became possible.

Python had them tacked on after the fact (version 2.0 as I recall, or was it 2.2?), they work pretty nicely IMO, as long as you treat functions as first class objects the whole time you're ok.

stcredzero 17y ago

they work pretty nicely IMO, as long as you treat functions as first class objects the whole time you're ok Clarify this? Also, isn't there some inconvenience due to the indentation thing?

kingkilr 17y ago
There's no inconvenience, it reads pretty normally, for example: http://code.djangoproject.com/browser/django/trunk/django/views/decorators/http.py#L22 http://code.djangoproject.com/browser/django/trunk/django/vi...
- stcredzero 17y ago
  I meant lambdas in particular. Example is too long for a discussion specific to lambdas.

dantheman 17y ago

Python lambdas do not work well, in fact they can only be one line long. For some cases this may be ok, especially if python was were the programmer learned about lambdas, but from those who come from with languages with real lambdas it is quite limiting.

deleted 17y ago
[deleted]
kingkilr 17y ago
We aren't talking about lambdas, we are talking about closures. Lambdas are simple syntactic sugar for a function definition that has a single expression, closures are a concept to capture the outer scope.

silentbicycle 17y ago

Not really. For one thing, you can't modify the closed over values unless you manually box them in a list, due to scope ambiguity. (This may be fixed in 3.0.) It's a little thing, but it makes code that depends on manipulating closures pretty ugly, discouraging their use. Scheme avoids the issue by having a non-ambiguous syntax (a big advantage of those parens), and Lua avoids it by defaulting to global scope* unless you declare them with "local", which also anchors their scope unambiguously. * Which is actually not a big deal - the global table is just another table, so you can hook its set method to catch unexpected globals (see strict.lua). It's far less trouble than Python's solution.

kingkilr 17y ago
Python 3.0 introduces the nonlocal keyword which allows you to assign to closed over names.

statictype 17y ago

Someone correct me if I'm wrong, but, I think it was less of "tacking on closures" and more of getting the lexical scoping issues right. i.e, there was issues with scoping that had nothing to do with closures per-se. When they fixed it, closures automatically became possible.