8 ms·

I wonder how much of this is still true. Python was a very compact language a decade ago (when I started using it), but gradually acquired bloat (perhaps becaus

• miloshasan 16y ago
  Didn't downvote you, but the difference is that lambdas can only be executed (i.e. applied to something) while decorators let you analyze the code of the function and do something else other than just executing it.
  • ekiru 16y ago
    How is this so? Decorators are just syntactic sugar for defining a function then replacing it with the result of calling another function (the decorator) on it.
    • miloshasan 16y ago
      The decorator can do introspection on the function object. This project uses the idea to execute (some) Python code on the GPU: http://code.google.com/p/copperhead/ http://code.google.com/p/copperhead/
      • JeremyBanks 16y ago
        Which being able to wrap the function definition in a function call could accomplish. Unfortunately that's not the direction the Python team wants to take the language.
      • cabalamat 16y ago
        > The decorator can do introspection on the function object. so can normal (i.e. not using decorators) code after the the function, e.g.: def myFunction(x): blah doSomethingWith(myFunction) Here, doSomethingWith() can introspect on myFunction()
        • miloshasan 16y ago
          Ah, yes - of course decorators do not fundamentally increase the expressive power of the language (and neither do lambdas, obviously). It's all just a matter of convenience and elegance, which are in the eye of the beholder anyway...
• neild 16y ago
  You complain that Python has acquired bloat in the past decade, and appear to be citing the presence of tuples, dicts, and lists as an example of this. Since tuples, dicts, and lists have existed in Python for well over a decade, I don't quite see how they can be an example of acquired bloat. As for decorators...well. @dec def somefunc(): pass is almost precisely identical to def somefunc(): pass somefunc = dec(somefunc) In other words, decorators are pure syntactic sugar. I suppose you could call that "bloat", although I'd rather strongly disagree. There's nothing at all wrong with making common patterns easier to write, and I've written plenty of code which has benefited from access to decorators. What really puzzles me is that it seems that what you really want is simply added syntax for multi-line anonymous functions...in other words, syntactic sugar. I suppose that "bloat" is any sugar that doesn't come in your preferred flavor.
  • silentbicycle 16y ago
    My complaint mixed two things - one, I'm not convinced that decorators are a special-case "feature" that would come for free with better lambdas. Two, does Python need tuples, dicts, AND lists? (I know it's had them for a long time.) Python seemed really refreshingly clean compared to Perl and C++, the languages I'd been using previously. I still think it's a decent language, but Python is to Perl and Lua is to Python along those lines. I've moved on. I'm probably still just annoyed about Guido's position on tail-call optimization, though.
    • wyuenho 16y ago
      Python's lambda is not broken, it's just that the notion of a (progn) from Lisp doesn't exist in Python, so Python's lambda is a lot harder to use because for anything more complicated then 1 expression, you'd have to define a fully named function somewhere. For the most part this isn't an issue because you probably wouldn't want to have more then 2 or 3 expressions in a lambda anyway. Granted, a lot of languages like Ruby, Lua, ML and even CoffeeScript have arguably even cleaner syntax then Python, but none has as vast a community and quality libraries that mirror Python. In choosing a language, the language itself matters, but the ecosystem equally matters IMHO.
• baddox 16y ago
  Decorators are just syntactic sugar. Are you arguing against syntactic sugar and perhaps for a slimmer "purer" syntax? If so, I think that's a valid point (though I happen to disagree in this case). All syntactic sugar actually adds nothing: we don't need +=, ++, or even C-esque array indexing. However, they often provide easier to read/write/maintain source code. As for Python decorators, one easy example of why they're neat is in Django: you've got your view functions, and if you want to restrict access to a view to only authenticated users, you add the line "@login_required" right about the function definition. I happen to think it looks nice.
  • cabalamat 16y ago
    > Decorators are just syntactic sugar. Are you arguing against syntactic sugar and perhaps for a slimmer "purer" syntax? If so, I think that's a valid point (though I happen to disagree in this case). I am in favour of semantic sugar, I just don't think it should be part of the language. Languages should be small, and have features that enable syntactic sugar to be written in the language. These features might include macros (like in Lisp, or at a pinch C) or overloaded operators (as in C++ or Python). Regarding decorators, I don't see that they bring much value. The decorator syntax is no shorter than doing it without decorators, so if you remove the decorator syntax you're making Python a smaller language which makes it easier to learn and understand.
    • wisty 16y ago
      Macros (and their more hygienic cousins) are not always a good idea. They make it very hard to understand what the rest of the program does, unless you can grep the whole thing. Lispers will violently disagree with me here. Regarding decorators, no they don't seem to be that useful. They do bloat the documentation, if not the language; and you don't ever really need them.
      • silentbicycle 16y ago
        > Macros (and their more hygienic cousins) are not always a good idea. They make it very hard to understand what the rest of the program does, unless you can grep the whole thing. So does object-oriented programming, more often than not. I'm not sure that's a sufficient argument, especially if there's no other way to do static metaprogramming in a language.
• cabalamat 16y ago
  or, more usually one of these: def somefunc(x, y): blabla dec(somefunc) def somefunc(x, y): blabla somefunc = dec(somefunc) The rationale for decorators, AIUI, is that if somefunc() is long, then putting the decorator at the end makes it easier to overlook, whereas putting it at the top is harder to overlook. Personally, I never use them; if I want the functionality of decorators, I write code immediately after the function, e.g.: def add(a, b): r = a.getValue() + b.getValue() return sm.UInteger(r) notify(add, "ii", "i", "+", cascade=True) BTW, lists, tuples and dicts have been in Python since forever (at least as far back as 0.9.1)
• wyuenho 16y ago
  Decorators and lambdas are completely different and separate topics, one CAN exist without the others. A decorator is a function that takes a function, optionally some parameters and return a function. What this tells you is that a decorator is a special instance of a higher-order function, that takes a (partially applied) function, fudge around with its internals and return that same function, fully applied. When I said function, they can be named of course, which is the case for most of the Python functions. Your second example would accomplish the same thing, but let's change it to something like this: somefunc = dec(def (x, y): blabla) However, this proposal instead of introducing a new language syntactic feature, you would have to change how the interpreter parses and compiles function argument, namely it'll need to understand a def function definition without a name as an expression. The interpreter would also need to assign an internal name to the lambda and compile it to a function object. That's not a trivial change in the grammar of the language. However, I'd agree that having that instead of a Python lambda would make a lot of HO functional style programming a lot more fluid.
  • wkornewald 16y ago
    I've implemented a Python-inspired syntax for JavaScript which supports multi-line lambdas. This is what it looks like: http://bitbucket.org/wkornewald/pyvascript/src/tip/pyvascript/stdlib.pyva#cl-30 http://bitbucket.org/wkornewald/pyvascript/src/tip/pyvascrip... It would look better with syntax highlighting, but I'm not sure if the code stays readable enough with multi-line lambdas. It also becomes more ugly once you want to use lambdas within dicts or lists: http://bitbucket.org/wkornewald/pyvascript/src/tip/tests/test.py#cl-259 http://bitbucket.org/wkornewald/pyvascript/src/tip/tests/tes... The problem here is that return x, could be either a lambda returning the tuple (x,) or the dict/list item separator, so the separator must be put on a separate line. I'm sure something like this was already proposed, so what were Guido's objections against it? I suppose it's not possible to make multi-line lambas readable enough? Maybe we need more powerful IDEs that go beyond editing text in a "stupid" text field and instead work directly on the AST and use other visual hints like boxes around functions/lambdas, etc.
    • wyuenho 16y ago
• rwmj 16y ago
  Don't know about decorators. The real issues with Python that I find working at Red Hat (unfortunately Python and Ruby are popular choices here): - generally poor choices for implementation: inefficient storage of values - 64 bit version approximately doubles the size of all data - interpreted, no code generator so it's very slow - lack of type safety is a constant source of bugs that just wouldn't appear in other languages - whitespace layout screws up patches silently Edit: don't downvote, comment on what I have to say.
  • viraptor 16y ago
    - 64 bit issue is going to be the same for all languages. Twice the pointer size, twice the data size (unless you're using a very specific type) - No code generators? You could complain that they're not good enough, don't support some specific extensions, don't play nice with threading, or something else, but there are many versions of python which work as compilers. Just google a bit. - Lack of type safety is there by design. If you want type checking, why are you even looking at duck-typed scripting languages? It's a basic design decision, not something that could be changed / improved. - Why is whitespace even an issue in patches? If anyone submits a patch, they should use exactly the same style as the rest of the file. If they don't, patch should be rejected. The same thing happens in projects where indentation doesn't really matter. Also, it's hard to "silently" screw up code covered by tests. Any big enough project should have those...
    • rwmj 16y ago
      Thanks for replying. The 64 bit issue is definitely not the "same for all languages". Programs get slightly bigger, but don't double in size as happens for Python programs. Most Linux 64 bit C programs will be using 32 bit 'int'. Python consumes 24 bytes to store any single int on 64 bit. Code generators: I mean ones which anyone uses. Lack of type safety: it may well be "by design", but it's a dumb design which causes lots of problems. Search Bugzilla for Python tracebacks and you'll see hundreds of bugs caused by lack of basic compile-time type checks. It's easy for a compiler to check that a function you're calling requires 3 arguments of type foo, bar and baz, and not doing that simply causes lots of errors. The whitespace issue is also real: if/else changes its meaning completely if you're not hyper-careful about how you apply patches (especially when you have to make manual fixes to patches to get them to apply).
• zephyrfalcon 16y ago
  Hmm, Python had tuples, lists, dicts and classes from the very beginning (version 0.9.1). Much bloat was tacked on after the simple class model was deprecated in favor of new-style classes... class methods, static methods, metaclasses, descriptors, properties, decorators, you name it. Then there were additions like list comprehensions and generators (although those are actually useful). IMHO, Python's indentation-based syntax is a great way to make (and keep) the language readable, but at the same time it's an impediment to language flexibility. In a more flexible language, you could have implemented most (or all) of the aforementioned features yourself. (This sounds like something a Lisper would say, but it would work in other languages as well, like Io and Ruby.)
• msie 16y ago
  I think you can go too far in keeping a language compact. If there are common patterns in programming then they should be captured in the language. It makes code easier to write and understand.
• okmjuhb 16y ago
  I'm surprised no one has mentioned yet what I regard as the key reason decorators are useful: they maintain the property that you can always find the definition of a function named "foo" by textually searching for "def foo". Lots of alternate syntaxes break that.
  • deleted 16y ago
    [deleted]