5 ms·

I use Python and it's OK, but I find a lot of the breathless hype around it as a language a little baffling as there are more than an average number of stupidit

I use Python and it's OK, but I find a lot of the breathless hype around it as a language a little baffling as there are more than an average number of stupidities in there. However this piece is really around exploiting the amazing infrastructure that has built up around Python that empowers mathematical and statistical research, which is fair enough.

dunpeal 8y ago
What are these "stupidities" that bother you? Personally, I use Python a lot for anything related to data science. No language is perfect, but I'd say Python has a lot less deficiencies and warts than most other mainstream languages, and it's extremely well suited for tasks in data science and related fields such as machine learning. The main issue with Python is that its default platform (CPython) isn't very efficient. That's not a problem in the language itself; in fact, it's partly caused by all the benefits of a high-level language: you simply don't have the same facilities to optimize your resource consumption as you do in, say, Rust. The upside is of course that the code is far more concise and readable.
- Insanity 8y ago
  Whilst that is true, for data science related things I end up using Pandas (and Numpy) often which are fast. So most of the heavy lifting is not done by python itself.
  - dunpeal 8y ago
    Yes, that's the case for most data scientists, and often for users in general. You can get pretty good performance levels from Python by delegating to C correctly. Even end users tend to do that because the data science stack of Python (numpy and the many libraries using it) spend almost all of their runtime in C routines. If you are using Numpy correctly (even with little understanding of Python itself and its C-API) then virtually all your hot loops are executed in optimal C code.
  - mynewtb 8y ago
    So what? Pandas and numpy are still use with Python code using their APIs. The implementation details are not something the users care about. They write Python.
    - dunpeal 8y ago
      Not sure what you're arguing. If you use numpy and pandas properly, most of your computations happen in optimized C routines. So you will write Python, but get very good resource (both time and space) efficiency.
- dnautics 8y ago
  Here's a classic: def a(arg = []): return arg a([1]) #==> [1] arr = a() #==> [] arr.append(1) a() #==> [1]
  - dunpeal 8y ago
    That's slightly surprising, but I wouldn't call it a wart. A proper wart is something that bothers you even after years of using the language, not something that surprises you a couple of times as a beginner, but then ceases to be a problem - or indeed, in this case, has some good uses. The obvious alternative in this case would be to reconstruct the default value. This doesn't work very well with the language's evaluation model - since the function definition is only evaluated once, and it's very inefficient and in fact surprising to perform later re-evaluations. Furthermore, this behavior can be useful. If you don't want it, you just use `None` as the default and then assign in the function body. However, if you do want it, there would be no other way to get it, and no similarly easy workaround. Finally, had there been a consensus of it being a wart, it would have been removed in Python 3.x. It wasn't.
    - crdoconnor 8y ago
      >I use Python and it's OK, but I find a lot of the breathless hype around it as a language a little baffling as there are more than an average number of stupidities in there. There are many warts that will never go away simply because they're embedded so much within the culture of the language and because undoing the wart would break so much working code. I love python and I've used it every day for 15 years but there are core parts of the language I hate with a passion. If in 3.9: * "if x" started failing with an exception for most non-boolean values of x (e.g. lists, strings, numbers, etc.) * strings stopped being iterable by default then I'd be celebrating, but I know it's never going to happen.
      - dunpeal 8y ago
        > "if x" started failing with an exception for non-boolean values of x I would call that a personal preference, and one that is far from consensus, rather than a "wart". A wart is a known problem in the language, that most users consider to exert a negative impact on their usecases. Example would be Type Erasure in Java, which is there for historical reasons, can not be fixed, and is generally agreed by Java programmers to be a Bad Thing. There isn't anything like this consensus for the changes you are suggesting. All other mainstream languages support use of non-booleans as predicates, including for example C++ and Java, which are statically typed. This change would make Python more strict about typing than virtually all mainstream static languages! Given how Python is dynamically typed, I'd suspect this change would be extremely unpopular. > strings stopped being iterable by default Again, not something most people would use. There are many fields in which strings are used to store sequences of characters where each character has a meaning. In all those fields, `for char in string` is a very useful idiom. I'm not sure how this is a wart or what's your usecase that string iterability is breaking. Indeed, strings being iterable is in line with the general iterability philosophy and unlikely to change (which is a good thing for most users).
harshgupta 8y ago
> As there are more than an average number of stupidities there. Please post more meaningful comments. Sure it doesn't have static typing or performance of C, but it has a stable framework in every conceivable application (Web Dev, machine learning, CLI, you name it) and works as a top notch scripting language. This is not "stupidity", it was by design to make it batteries included and easy to use with a tradeoff with the above things.
crdoconnor 8y ago
>I use Python and it's OK, but I find a lot of the breathless hype around it as a language a little baffling as there are more than an average number of stupidities in there. There's fewer stupidities than languages like javascript or perl and it ends up being more practical than languages like haskell or ocaml. One of it's unappreciated facets is that it's good at language interop. Instead of trying to be all things to all people (e.g. like go) it just makes it easy to interop with C where you need speed and focuses on being a good high level language. I think the surprise surrounding its popularity is indicative of the fact that few people really understand what makes a great language.
tragomaskhalos 8y ago
I'm surprised people needed to ask, and I was very specifically talking about the language itself rather than the libraries (so "batteries included" is not a counterargument); but here is a small non-exhaustive assortment of nonsense in Python: 1. Does 3/2 == 1 or 1.5 ? Either answer would be logical and OK, provided you stick to it. The utterly daft answer that Python gives is "it depends on what version of the language you are using, and/or whether you do "from __future__ import division"" 2. Generalising 1, a painful set of breaking changes between 2 and 3 that could have largely been avoided by aliasing names or introducing new names for changed concepts / methods; eg make xrange = range; add a new function rather that redefine what 'print' is (and yes, failing to make 'print' a function in the first place was a shockingly bad decision). Read about the insane amout of effort that Dropbox put into migrating their codebase to see what a ballsup this all is - polite languages respect backwards compatibility. 3. The object system is a mess: type(some_obj_i_made) is <type 'instance'> - wat? - unless you explicitly inherit your class from object when it suddenly does something sensible; constructor inheritance is a confusing bog. Yes yes old style vs new style objects, but that's the problem. This stuff shouldn't be hard; see eg Ruby. 4. edit: scoping - oy vey Look, it's OK. It works. The ecosystem makes up for an awful lot of this rubbish. But don't be so devoted to a technology that you're blind to its faults.

dunpeal 8y ago

What are these "stupidities" that bother you? Personally, I use Python a lot for anything related to data science. No language is perfect, but I'd say Python has a lot less deficiencies and warts than most other mainstream languages, and it's extremely well suited for tasks in data science and related fields such as machine learning. The main issue with Python is that its default platform (CPython) isn't very efficient. That's not a problem in the language itself; in fact, it's partly caused by all the benefits of a high-level language: you simply don't have the same facilities to optimize your resource consumption as you do in, say, Rust. The upside is of course that the code is far more concise and readable.

Insanity 8y ago
Whilst that is true, for data science related things I end up using Pandas (and Numpy) often which are fast. So most of the heavy lifting is not done by python itself.
- dunpeal 8y ago
  Yes, that's the case for most data scientists, and often for users in general. You can get pretty good performance levels from Python by delegating to C correctly. Even end users tend to do that because the data science stack of Python (numpy and the many libraries using it) spend almost all of their runtime in C routines. If you are using Numpy correctly (even with little understanding of Python itself and its C-API) then virtually all your hot loops are executed in optimal C code.
- mynewtb 8y ago
  So what? Pandas and numpy are still use with Python code using their APIs. The implementation details are not something the users care about. They write Python.
  - dunpeal 8y ago
    Not sure what you're arguing. If you use numpy and pandas properly, most of your computations happen in optimized C routines. So you will write Python, but get very good resource (both time and space) efficiency.
dnautics 8y ago
Here's a classic: def a(arg = []): return arg a([1]) #==> [1] arr = a() #==> [] arr.append(1) a() #==> [1]
- dunpeal 8y ago
  That's slightly surprising, but I wouldn't call it a wart. A proper wart is something that bothers you even after years of using the language, not something that surprises you a couple of times as a beginner, but then ceases to be a problem - or indeed, in this case, has some good uses. The obvious alternative in this case would be to reconstruct the default value. This doesn't work very well with the language's evaluation model - since the function definition is only evaluated once, and it's very inefficient and in fact surprising to perform later re-evaluations. Furthermore, this behavior can be useful. If you don't want it, you just use `None` as the default and then assign in the function body. However, if you do want it, there would be no other way to get it, and no similarly easy workaround. Finally, had there been a consensus of it being a wart, it would have been removed in Python 3.x. It wasn't.
  - crdoconnor 8y ago
    >I use Python and it's OK, but I find a lot of the breathless hype around it as a language a little baffling as there are more than an average number of stupidities in there. There are many warts that will never go away simply because they're embedded so much within the culture of the language and because undoing the wart would break so much working code. I love python and I've used it every day for 15 years but there are core parts of the language I hate with a passion. If in 3.9: * "if x" started failing with an exception for most non-boolean values of x (e.g. lists, strings, numbers, etc.) * strings stopped being iterable by default then I'd be celebrating, but I know it's never going to happen.
    - dunpeal 8y ago
      > "if x" started failing with an exception for non-boolean values of x I would call that a personal preference, and one that is far from consensus, rather than a "wart". A wart is a known problem in the language, that most users consider to exert a negative impact on their usecases. Example would be Type Erasure in Java, which is there for historical reasons, can not be fixed, and is generally agreed by Java programmers to be a Bad Thing. There isn't anything like this consensus for the changes you are suggesting. All other mainstream languages support use of non-booleans as predicates, including for example C++ and Java, which are statically typed. This change would make Python more strict about typing than virtually all mainstream static languages! Given how Python is dynamically typed, I'd suspect this change would be extremely unpopular. > strings stopped being iterable by default Again, not something most people would use. There are many fields in which strings are used to store sequences of characters where each character has a meaning. In all those fields, `for char in string` is a very useful idiom. I'm not sure how this is a wart or what's your usecase that string iterability is breaking. Indeed, strings being iterable is in line with the general iterability philosophy and unlikely to change (which is a good thing for most users).

harshgupta 8y ago

> As there are more than an average number of stupidities there. Please post more meaningful comments. Sure it doesn't have static typing or performance of C, but it has a stable framework in every conceivable application (Web Dev, machine learning, CLI, you name it) and works as a top notch scripting language. This is not "stupidity", it was by design to make it batteries included and easy to use with a tradeoff with the above things.

crdoconnor 8y ago

>I use Python and it's OK, but I find a lot of the breathless hype around it as a language a little baffling as there are more than an average number of stupidities in there. There's fewer stupidities than languages like javascript or perl and it ends up being more practical than languages like haskell or ocaml. One of it's unappreciated facets is that it's good at language interop. Instead of trying to be all things to all people (e.g. like go) it just makes it easy to interop with C where you need speed and focuses on being a good high level language. I think the surprise surrounding its popularity is indicative of the fact that few people really understand what makes a great language.

tragomaskhalos 8y ago

I'm surprised people needed to ask, and I was very specifically talking about the language itself rather than the libraries (so "batteries included" is not a counterargument); but here is a small non-exhaustive assortment of nonsense in Python: 1. Does 3/2 == 1 or 1.5 ? Either answer would be logical and OK, provided you stick to it. The utterly daft answer that Python gives is "it depends on what version of the language you are using, and/or whether you do "from __future__ import division"" 2. Generalising 1, a painful set of breaking changes between 2 and 3 that could have largely been avoided by aliasing names or introducing new names for changed concepts / methods; eg make xrange = range; add a new function rather that redefine what 'print' is (and yes, failing to make 'print' a function in the first place was a shockingly bad decision). Read about the insane amout of effort that Dropbox put into migrating their codebase to see what a ballsup this all is - polite languages respect backwards compatibility. 3. The object system is a mess: type(some_obj_i_made) is <type 'instance'> - wat? - unless you explicitly inherit your class from object when it suddenly does something sensible; constructor inheritance is a confusing bog. Yes yes old style vs new style objects, but that's the problem. This stuff shouldn't be hard; see eg Ruby. 4. edit: scoping - oy vey Look, it's OK. It works. The ecosystem makes up for an awful lot of this rubbish. But don't be so devoted to a technology that you're blind to its faults.