4 ms·

Python is remarkable for having a dozen or so major language features disallowed by fiat (removal of the GIL, unrestricted anonymous functions, TCO, braces) but

by aristus 17y ago

Python is remarkable for having a dozen or so major language features disallowed by fiat (removal of the GIL, unrestricted anonymous functions, TCO, braces) but still being extremely powerful, expressive, and used by programmers of all skill levels. It's difficult to be obscure in Python. Yet if I really need to do something jinky like remapping an outside library's methods, I can do it with a few lines of slightly-uglier code. That's a very hard balance to make. Good design involves a lot of "no". I don't think languages are an exception.

chromatic 17y ago
> It's difficult to be obscure in Python. It's occasionally difficult to be obscure with Python syntax. It's not at all difficult to be obscure with anything in Python above that level. Even then, if you do weird things with metaclasses or decorators, it's easy to be obscure with Python.
- blasdel 17y ago
  Decorators are an odd case -- I find that they make code dramatically clearer at the call-site, but that the decorator definitions get hairy fast (and get worse the more life-saving they are). They ended up being one of the best macro systems ever devised (they're applied at compile-time!).
  - njharman 17y ago
    > they're applied at compile-time! I seriously don't under stand that statement. Decorators are callables that return callables, nothing else, nothing special. Decorator Syntax is just sugar. Decorators can be applied any time including runtime. I'm not even sure what you mean by "compile time" in regards to Python, import time?
    - blasdel 17y ago
      They're applied at parse-time, and they completely mask the def that they are applied to. Yes, the function being used as a decorator could just as easily be called at runtime, and that does break the similarity to macros somewhat.
      - njharman 17y ago
        Only decorator syntax happens somewhere around parse-time (which I call import time, but meh). > completely mask the def that they are applied to. @decorator reassign to the name of the def. But if there are other refs to that def they do not change and are not "masked". It is no different than assignment. You know that these two are identical, right? @foo def bar(): pass def bar(): pass bar = foo(bar) Also this is a perfectly valid decorater that doesn't mask the original func def deco(func): # do something terrible clever here return func decorator syntax != decorators is my main point. But by conflating the two I can begin to understand your statement.
jnoller 17y ago
Minor correction. The removal of the GIL is not disallowed by fiat. The removal of the GIL was attempted (via granular locking) and destroyed single threaded performance. That's unacceptable for a variety of reasons. In the same thread, Guido has repeatedly stated that the GIL was a tradeoff, and he would welcome anything that helped lessen it's impact/remove it should it be proven not to significantly harm Python's primary function. If someone showed up with a patch tomorrow which allowed free threading without seriously breaking python, or crippling single threaded performance, or making extension modules impossible to write, I could very well see it getting in. In reality, doing this requires a serious reworking of the interpreter (ala unladen swallow) to make it even feasible. There's a lot of things the GIL actually helps, for example the ease of writing c-based extension module, unfortunately they come with a price. The price is/was seen as an acceptable tradeoff, and I think it has served it well, even if if it disappeared tomorrow no one would shed a tear. Also, braces aren't a feature :p
- jacobian 17y ago
  Minor correction. The removal of the GIL is not disallowed by fiat. To piggyback: don't forget that CPython ≠ Python. The GIL is an implementation detail of CPython, not a feature of the language. Other Pythons -- Jython, for one -- have no GIL.
  - kragen 17y ago
    True enough. BTW, if you'd like to chat more about concurrency, I'm around all weekend (although I'm late getting to the University of Belgrano today). As my comments during your talk yesterday indicated, I think you're pretty off-base arguing that people aren't trying out interesting concurrency solutions in Python — ZODB is a (somewhat broken) STM that's been production-stable for many years, and Stackless is specifically targeted at actor-based modeling. So I think people in the Python community have actually been way out in front on these issues. It's just that most people use Python for production work, not research, so the researchy stuff doesn't make it into the mainline.

by aristus 17y ago

chromatic 17y ago

> It's difficult to be obscure in Python. It's occasionally difficult to be obscure with Python syntax. It's not at all difficult to be obscure with anything in Python above that level. Even then, if you do weird things with metaclasses or decorators, it's easy to be obscure with Python.

blasdel 17y ago
Decorators are an odd case -- I find that they make code dramatically clearer at the call-site, but that the decorator definitions get hairy fast (and get worse the more life-saving they are). They ended up being one of the best macro systems ever devised (they're applied at compile-time!).
- njharman 17y ago
  > they're applied at compile-time! I seriously don't under stand that statement. Decorators are callables that return callables, nothing else, nothing special. Decorator Syntax is just sugar. Decorators can be applied any time including runtime. I'm not even sure what you mean by "compile time" in regards to Python, import time?
  - blasdel 17y ago
    They're applied at parse-time, and they completely mask the def that they are applied to. Yes, the function being used as a decorator could just as easily be called at runtime, and that does break the similarity to macros somewhat.
    - njharman 17y ago
      Only decorator syntax happens somewhere around parse-time (which I call import time, but meh). > completely mask the def that they are applied to. @decorator reassign to the name of the def. But if there are other refs to that def they do not change and are not "masked". It is no different than assignment. You know that these two are identical, right? @foo def bar(): pass def bar(): pass bar = foo(bar) Also this is a perfectly valid decorater that doesn't mask the original func def deco(func): # do something terrible clever here return func decorator syntax != decorators is my main point. But by conflating the two I can begin to understand your statement.

jnoller 17y ago

Minor correction. The removal of the GIL is not disallowed by fiat. The removal of the GIL was attempted (via granular locking) and destroyed single threaded performance. That's unacceptable for a variety of reasons. In the same thread, Guido has repeatedly stated that the GIL was a tradeoff, and he would welcome anything that helped lessen it's impact/remove it should it be proven not to significantly harm Python's primary function. If someone showed up with a patch tomorrow which allowed free threading without seriously breaking python, or crippling single threaded performance, or making extension modules impossible to write, I could very well see it getting in. In reality, doing this requires a serious reworking of the interpreter (ala unladen swallow) to make it even feasible. There's a lot of things the GIL actually helps, for example the ease of writing c-based extension module, unfortunately they come with a price. The price is/was seen as an acceptable tradeoff, and I think it has served it well, even if if it disappeared tomorrow no one would shed a tear. Also, braces aren't a feature :p

jacobian 17y ago
Minor correction. The removal of the GIL is not disallowed by fiat. To piggyback: don't forget that CPython ≠ Python. The GIL is an implementation detail of CPython, not a feature of the language. Other Pythons -- Jython, for one -- have no GIL.
- kragen 17y ago
  True enough. BTW, if you'd like to chat more about concurrency, I'm around all weekend (although I'm late getting to the University of Belgrano today). As my comments during your talk yesterday indicated, I think you're pretty off-base arguing that people aren't trying out interesting concurrency solutions in Python — ZODB is a (somewhat broken) STM that's been production-stable for many years, and Stackless is specifically targeted at actor-based modeling. So I think people in the Python community have actually been way out in front on these issues. It's just that most people use Python for production work, not research, so the researchy stuff doesn't make it into the mainline.