6 ms·

Good post with solid examples. At the risk of being down voted into oblivion (I know I would be on proggit by the fundamentalist Pythonistas there): it seems t

• masklinn 16y ago
  > At the risk of being down voted into oblivion (I know I would be on proggit by the fundamentalist Pythonistas there) You seem to be very well acquainted with proggit indeed as this kind of pre-whining is quite common there. Though the little twist about it at the end is a new (and quite despicable) addition to it. > it seems to me that this just adds to the list of Python issues Considering this page is at least two years old, it's older than e.g. most of the GIL hubbub. > The ongoing saga with the GIL (although I realize this has advantages in simplifying C extension development) The GIL saga makes the whole language simpler (running directly opposite your thesis that all these "points" make the language more complex), though it does make taking advantage of multiple cores harder (if you somehow have a beef against multiple processes). > String formatting changing seemingly from 2.4 and every version thereafter You might want to read and test things before that kind of claims. When the article you link says: > In Python 2.5 and later, there's a new formatter it means the old one is still there. It was not removed in Python 2.5 (or later, `"It is %s!" % foo` still works perfectly in Python 3.1). The second "point" of your article is hellishly disingenuous as it has nothing to do with formatting. It's also a pretty terrible article as it uses "long form" formatting in the `format` calls (which are used to make bindings clearer, whereas you can use C#-style positional formatting if your strings are short and readable in and of themselves)… and then whines that the formatting calls are too verbose. And of course, coming from Perl the article you link to suggests… implicitly pulling variables out of the context instead of explicitly sending them to formatting. > The 2.x/3.x split (yes I know there are reasons) Indeed, and a number of these reasons center around making the language simpler and more consistent (`print` as a function, reorganization of the stdlib, ...). > Version issues for scripting [2] This has nothing to do with Python as a language. > Syntax inconsistency. I know this one will be controversial but I'm referring to things like the fact that del() is a operation What are you talking about? What is `del()`? Are you talking about `del` as in `del foo` and expressing your dislike of it being a statement? Considering the original job of `del` (completely remove a binding from a scope), I'm not sure what else it could have been (though I can't say I like it much, be it to remove a binding from a scope or remove elements from structures). I'd also enjoy your explanation of how it demonstrates inconsistency: which other Python non-statement operation is able to destructively alter scopes? And is a majority of the scope-altering operation non-statements? If it is not, would not the non-statement scope-altering operations be inconsistent? > Other issues [3] Few of these are universally valid. In fact, I can find none that is apart from whitespace making it harder (if not impossible) to generate code[0]. Some of these complaints are plain nonsensical (Python being an "untyped language"), most others are personal preferences which you may or may not agree with (Python's scope confusion and crappy lambdas — or more precisely overuse of statements as Haskell's lambdas have exactly the same limitation — bug me a log, while TFAA's dislike of `eval` basically amounts to "I hate languages where not everything is decided at compile time) > Isn't something like Ruby or Lua a lot cleaner in this regard? Ruby definitely is not, though the choices it made are most definitely different. I don't know enough Lua to comment on it. But if you want orthogonal and consistent languages, you probably should not look at even remotely popular languages anyway: they're mostly hobbled together. Even Haskell, which your [3] seems to hold as some kind of holy grail, is a complex and not necessarily consistent language. Consistent languages are generally very small (syntax-wise, as every syntactic construct you add to the language exponentially increases your chances of breaking syntactic consistency) and provide lots of power to users (e.g. the ability to very easily define control-flow structures, increasing the risk of lowering the "external" consistency of produced code). Examples of such languages are Smalltalk, Forth, Lisp (especially, in my opinion, the Lisp-1 family). Though really all of those should be pluralized as they pretty systematically ended up forking from a common ancestor into a multitude of related-but-incompatible (usually library-wise, sometimes syntax-wise or semantics-wise) languages. [0] but then again, how often does that happen, and doesn't Python provide the tools to generate a running system rather than have to statically generate code which will then have to be compiled and run? I can't say I've often liked this kind code generation, which in my experience has more often lead to pain and suffering than enjoyment, e.g. in GUI toolkits)
  • deleted 16y ago
    [deleted]
    • masklinn 16y ago
      > Just to clarify, the GIL is worse than making writing multithreaded programs harder, it makes CPU bound singlethreaded tasks perform worse on multicore machines than on single core machines. This is incorrect. I'm guessing you're making that claim based on David's discoveries on the old (2.x) GIL last year and didn't actually bother seeing the presentations (or reading the slides, or the blog posts). All the issues he outlined are in multithreaded workloads (why would the GIL do anything for single-threaded loads?). His original outline (the one which basically went viral) was about "GIL battles" (GIL contention) in the old GIL [0], and GIL contention happens when the OS schedules two Python threads for running simultaneously and they both try to run at the same time. How do you do that without running two Python threads simultaneously? Later, David also exposed a convoy effect with IO-bound threads in the new (Python 3.2) GIL [1] [2] See also his Interactive Python Thread Visualizations [3] and note that all of them involve at least 2 threads. [0] http://dabeaz.blogspot.com/2010/01/python-gil-visualized.html http://dabeaz.blogspot.com/2010/01/python-gil-visualized.htm... [1] http://bugs.python.org/issue7946 http://bugs.python.org/issue7946 [2] http://dabeaz.blogspot.com/2010/02/revisiting-thread-priorities-and-new.html http://dabeaz.blogspot.com/2010/02/revisiting-thread-priorit... [3] http://www.dabeaz.com/GIL/gilvis/index.html http://www.dabeaz.com/GIL/gilvis/index.html
• limmeau 16y ago
  The GIL is actually a way of keeping Python internally uncomplicated at the price of lost efficiency. String formatting: that's a case of the "explicit is better than implicit" dogma. As for "complicated": I'd rather explain to a newbie that % takes a string template and data and substitutes, than that string literals are actually complex expressions with possibly side-effect-ful subexpressions. Versioning problems in language distributions vs Linux distributions: is there a language community without?
  • masklinn 16y ago
    > The GIL is actually a way of keeping Python internally uncomplicated at the price of lost efficiency. Lost efficiency? Barring significant engineering effort, the GIL is definitely more efficient than more fine-grained locking in a single-threaded situation. Which the Python core team considers of prime importance and the main use-case for Python (whether you agree or not is a different issue): previous tentatives to break-up the GIL lead to performance hits considered unacceptable (~20% across the board I believe). It also tends to keep Python code less complicated as — much as with Javascript — you can not have two threads of Python code running at the exact same time within a process (this, on the other hand, is a very mixed blessing: it prevents people from learning about the brokenness of thread-based concurrency, and it generally breaks code migrated on a GIL-less implementation such as Jython or IronPython)
    • limmeau 16y ago
      Splitting the same hair from the other side: If an experimental fine-grained locking variant of CPython scales better for, say, CPU-intensive multi-threaded programs on eight-cores, then the decision to use a GIL instead of fine-grained locking loses efficiency in the case of CPU-intensive multi-threaded programs on eight-cores. (Edit:) I agree with you on GIL being better for the typical case.
      • masklinn 16y ago
        > If an experimental fine-grained locking variant of CPython scales better for, say, CPU-intensive multi-threaded programs on eight-cores, then the decision to use a GIL instead of fine-grained locking loses efficiency in the case of CPU-intensive multi-threaded programs on eight-cores. True, but as far as I know, so far Python core developers haven't been very interested in switching locking strategy depending on the hardware and workload (to be fair, the GIL is so embedded throughout the interpreter and code utilities the mere act of making this more pluggable would likely generate a higher workload than just ripping out the GIL and building a brand new and more modern interpreter/VM from scratch)
• dagw 16y ago
  Well I'm mainly a python programmer and a fan of the language (but refuse to use the word "pythonista" and believe that whoever coined that word deserves a punch in the face) so take what I say with an appropriate grain of salt. Yes python has a few warts you need to aware, and when you list then they sound quite overwhelming, but having programmed in python for, on and off, 10 years, very few of them have actually tripped me up in any serious way. The GIL for example gets talked about more than it actually causes problems (and there are python implementations that don't have the GIL if it is truly a problem). If I really need multiprocessing within python, the multiprocessing library normally solves my problem. The string formatting "problem" you link to is hardly a problem at all in python 2. The "%s" % (foo) approach didn't stopped working after 2.4. They simply added a way to deal with non-positional arguments. That being said I'm not really a fan of the new python3 print syntax, but maybe I'll eventually get used to it. as for the 2.x/3.x thing, yea I'll agree it's sub-optimal. Let's just say I still write all my python code using 2.x since most of the libraries I use still don't have stable (or any) 3.x versions. The version issue you link to is problem of forwards compatibility rather than backwards compatibility and many languages fail at forwards compatibility. As far as I know there has only been one backwards compatibility break in python2, and that was that 'with' became a keyword. Some syntax inconsistency is annoying I agree, but they're mostly there for backwards compatibility, and many have already been fixed. Hopefully they've gotten it mostly cleaned up in python 3. The other issues you link to seem to be mix of personal opinion and minor annoyances. Sure the scope rules are a bit odd a times, but I've never really had problems with them in actual real code. I really don't get the complaint about lack of information hiding. Yes python doesn't have "real" information hiding, but you can get most of the useful parts of information hiding by adding underscore to start of your variables and method names. The only point on that list that I actually agree with to any extent, is the lambdas/anonymous functions, complaint. But again, it is a minor annoyance rather than a major deal breaker. At the end of the day, I agree that there are a lot of odd corners in Python that have arisen from how the language has grown organically over the years, and yes there are 'cleaner' languages out there (although I'm not sure Ruby is one of them). But for when it comes to getting things done in a quick, clean and efficient manner, python just works for me.
• seabee 16y ago
  Lua is cleaner because it's a tiny language. Whether that's better or not depends on what you want from it. But let's just say people don't solve their problems with OOP when OOP isn't a built-in.
  • limmeau 16y ago
    And even in its small size, Lua has its ways of being complicated. The interaction of multiple return values with varargs, for example. Or having to use pcall when you want exception handling. Or the distinction between the length and the size of a table. Not to say that these things are bad! Just that you find ugliness in any language if you look for it hard enough.