10 ms·

I've done a lot of Python for many years and its all been Python 2. Python 3 seems to be a decent improvement, and if I was working on a Python 3 project, that

I've done a lot of Python for many years and its all been Python 2. Python 3 seems to be a decent improvement, and if I was working on a Python 3 project, that would be fine. But when it comes to new projects, I struggle to find a compelling reason to use Python at all, when there are so many amazing languages now to choose from. With a new project you could choose Scala, Haskell, Clojure, Erlang (or Elixir) or Go. And there's also the less popular ones like Haxe and Dart. I've even been playing around with Elm. And I'm sure I've missed a bunch of others too. So the question for me, for new projects is: why choose Python 3 (over all the other non python options) at all? Not what's better about Python 3 than Python 2, but what's better about Python 3 than those other choices. These other choices all have certain areas where they have great strengths. What is Python 3's strength when compared to these other languages? It's a mutable, imperative, single CPU bound language that can't target the browser and is extremely difficult to distribute and deploy. Or have these issues been fixed? I don't mean to troll any Python fanboys. I use Python 2 every single day at work and I'm very happy with it. But what does Python 3 offer that other new languages don't? Because when you are starting a new project you can choose anything. Why should I choose Python 3 for my new projects?

Odin78 11y ago
Noob question: What's so difficult about deploying/distributing python?
- hynek 11y ago
  ATM it takes work to create a deployable artifact. We package virtualenvs using fpm, others use Docker. But Go just spits out a single binary you can scp anywhere (the build process OTOH is more painful IMHO). That’s why I’m highly curious about https://us.pycon.org/2016/schedule/presentation/2122/ https://us.pycon.org/2016/schedule/presentation/2122/ .
- retrogradeorbit 11y ago
  https://glyph.twistedmatrix.com/2015/09/software-you-can-use.html https://glyph.twistedmatrix.com/2015/09/software-you-can-use...
  - monkmartinez 11y ago
    This should be the #1 comment/resource on this thread IMO.
    - zanny 11y ago
      I recently started writing a few Qt applications, and was strongly considering PyQt - I mean, why wouldn't I? The syntax is cleaner and I can get more work done faster using Python than C++. I spent a few days going back and forth - comparing the performance, design time, etc of both - and in the end I'm just using Qt's JS JIT for dynamic list comprehensions and other things C++ is bad at. In the end, the fact that distributing on everything but Linux would have been reduced to having to bundle CPython in was just a deal breaker. Linux isn't really bad for deployment, though. You can use the SUSE OBS to build packages for all the major platforms besides Arch, and since my main desktop is Arch, I'm building my software with PKGBUILD's from the get-go.
      - witty_username 11y ago
        Python isn't very big (about 10-20 MB or so). What's the problem with bundling CPython?
      - kweks 11y ago
        I've written a production app in Python 3 + QT4 (PySide as opposed to PyQT) - I've bundled with cxfreed, and it's great. Fully cross-platform.. easy to distribute. Quite nice all around.
  - mixmastamyk 11y ago
    That page dismisses py2exe, but I've used it successfully for over a decade. On unix it is as simple as: sudo pip install [package/repo]
    - elktea 11y ago
      Except, you often need a full compiler toolchain for all the c dependencies. Then you need to make sure you have the required header files. Then you try and deploy to a small EC2 instance and run out of RAM building lxml or similar.
gnur 11y ago
I often dabble in other languages but in the end always return to python (3). What it offers for me truly is the batteries included and easy, memorable and predictable syntax. (Probably due to experience). Sure, Go is easier to deploy, Erlang and by extension Elixir are easier to scale. But python does align very well with my personal though process. I don't think parallel and I don't have race conditions in my mind. If I want to quickly write something that will perform decently, I choose python, because the time I save by not having to learn a new language could be days or perhaps even weeks. I guess it boils down to this: with my current experience, I'm more then 10 times as productive in python as I would be in any other language. Sure, it would be neat if I had as much experience in Erlang as I have in python, but that will take years, and at the end of the day, I'd rather finish my project this year with python, then next year with any other language.
- crdoconnor 11y ago
  >Sure, Go is easier to deploy Go's lack of a package manager making deployment more painful is the thing that made me come back to python.
  - oofabz 11y ago
    Go is staticly linked, you don't need to deploy packages, just the binary.
    - hynek 11y ago
      But you have to build those with its dependencies. And the best thing Go came up with is vendorizing.
      - creshal 11y ago
        And good luck keeping everything updated. (Does go statically link the libc, too? If so, you should be rebuilding all your go applications right now, after the glibc issues reported on Tuesday…)
andrewstuart 11y ago
I never thought I'd say it, but I'm loving programming the new ES2105 version of JavaScript. It really has a great deal in common with Python now. Clearly many programming languages are converging as they implement common good ideas from other programming languages. That's going to mean that whilst Python might have distinguished itself in the past for being streets ahead, in the future it's likely that many languages will also have many of those same good ideas incorporated. I posted about it: What language has decorators, generators, comprehensions, modules, but isn't Python? http://fourlightyears.blogspot.com.au/2015/08/what-language-has-decorators-generators.html http://fourlightyears.blogspot.com.au/2015/08/what-language-...
- coldtea 11y ago
  The "all async" model of Node kills it for practical programming compared to Python... And the worst thing is, Node/v8's JIT would kill Python in performance for a;; the kind of things people write Python scripts for, even if it run all synchronous. It would be nice if callbacks/promises/async-await were only optional and for network/web things, not for everything.
  - findjashua 11y ago
    async/await isn't too bad (es7 via babel)
  - goldbrick 11y ago
    You can still use the "-Sync" versions of functions in the standard lib.
    - coldtea 11y ago
      Yes, but not hundreds of thousands of npm libs.
- dragonwriter 11y ago
  > I never thought I'd say it, but I'm loving programming the new ES2105 version of JavaScript. Well, yeah, I'm sure ES2105 is cool, but most of us don't have the choice of using languages from the next century.
natrius 11y ago
Most of my development experience is in Python, and Clojure's what excites me the most these days. I've had to write a lot of Javascript for work, and it turns out that there's a large community of Javascript developers who wish they were writing Clojure, and they've built libraries like tcomb, Immutable.js and transducers.js to get pretty close. In the transpilers era, Javascript will never be so bad that choosing another dynamic language is a clear win. I'd go back to Python and Django for a CRUD app, but since Javascript is easier to write in a functional style than Python, I've actually started to prefer it as a first choice.
oxplot 11y ago
I personally find python in general to align almost perfectly with the way I think about writing software. It's interpreted so I can do things like compiling dynamic python in my code or fall into a python shell for debugging. Majority of time, I can use the standard library to do everything I need. And I love the clean syntax of Python — always a pleasure to look at. As for Py3, the standard libs are very clean and streamlined, (e.g. io). Oddly enough, the point that I love about Py3 is its handling of unicode vs bytes (which most people find it difficult for some reason). I'm not sure what you mean by "can't target the browser"? I don't find distributing/deploying python to be difficult or even involved at all. I do get annoyed at the single CPU bound limitation. If I had to summarize why I'd pick Py3 for new projects, I'd say because it thrives in being minimalist and I hate clutter.
stdbrouw 11y ago
Pick Python for the sheer amount of libraries that's available. Not just for web stuff, where Node.js and Ruby do fine, but also for scientific work, for statistics, for embedded work (Raspberry Pi or MicroPython), for systems administration, for command-line tools, for really just about anything you can imagine. And you can do all of those things while not having to switch contexts between different syntaxes and different standard libraries for basic things like regular expressions or HTTP requests. Picking the best tool for the job often gets in the way of actually getting things done. Python is the true swiss army knife of today's programming languages.
- abecedarius 11y ago
  That's a good reason, but note that it used to be the reason you picked Perl.
  - btreecat 11y ago
    Still a valid reason for people to chose Perl. Not advocating for Perl, just on behalf of Perl lovers like my office mate
  - JupiterMoon 11y ago
    The difference is that most people can read most other peoples' python code. Perl didn't tend to have that quality. EDIT Added another "most" to make it clear that not everyone can write readable python.
    - collyw 11y ago
      That depends entirely on who is writing the code. I have seen some truly awful Python as well as truly awful Perl.
      - JupiterMoon 11y ago
        This difference is that I've mainly seen decent Python and mainly seen awful Perl.
IndianAstronaut 11y ago
If you are building an application which does a lot of machine learning and statistics, I don't see a better language than Python. It has so many libraries to use for it. Note, I love R, but I can't imagine building an application with it.
- czep 11y ago
  You can build apps with R, but the result will be the ugliest code you have ever seen. For me, R for research and prototyping, then Python for productionalizing.
  - IndianAstronaut 11y ago
    Ugly isn't the problem. It is the poor error catching, erratic memory use, several ways to do one thing due to a lack of features in the standard libraries (regex), etc.
marklgr 11y ago
For personal projects, you can pick whatever language you want, possibly the most fun one that is still practical. Haskell or Elixir look promising in this regard. For companies, there are more factors to consider, eg. finding devs at a correct price, getting existing workforce to work on a new tech, size of standard/open source library, getting help and bugfixes from community instead of hacking on your own, risk of language/tech losing steam, etc. That's why several comparatively "boring" languages still thrive.
baldfat 11y ago
> I struggle to find a compelling reason to use Python at all My issue is I always see Python as the Second Best choice for what I am doing. There is always a better tool for the job. The one thing going for Python is that it is such a generalist BUT when doing work I prefer the Right Tool for the Job approach. I seriously can't think of a job that Python does best.
- deleted 11y ago
  [deleted]
- antod 11y ago
  > I seriously can't think of a job that Python does best. For me personally it is the best choice for non-throwaway shell scripting once the scripts becomes more complex and/or long lived than a sequence of shell commands. Python is part of the base install of just about every mainstream Linux distro, so in that regard its only real competitor is Perl.
mangecoeur 11y ago
For anything involving data analysis and scientific computing Python really shines - though I'm often surprised the extent to which web-oriented programmers are unaware of this, I read things like "you can write better web services in Go, therefore Python is obsolete". Python in science is kinda like the One Ring the Binds them - it is the glue that holds together the HPC code at CERN, ESA, NASA, and more, it crunches climate models and delivers your daily weather forcasts. Some really great projects like Cython, Theano, and Numba boost the performance of numeric code to native speeds with a fraction of the hassle of hand-written C. Mountains of machine learning research is done in Python, as well as statistics and analytics. And of course Numpy remains the de-facto standard of N-dimensional array libraries - if you look at numeric computing libraries in many other languages they will be framed as "Numpy-for-X".
- raverbashing 11y ago
  Yeah, I don't know While Numpy/Scipy is great with a capital G, it seems the underlying infrastructure is flaky. I'm talking about the messy process of building and installing it. And it seems everything is held with duct-tape Also it seems that "inside Scipy' it is a different world, and that to really "talk to the outside world" there seems to be a data-translation step needed.
  - kmike84 11y ago
    at least on OS X installing numpy and scipy is very easy - pip installs prebuilt wheels by default, no need to compile anything
  - ZenoArrow 11y ago
    > "I'm talking about the messy process of building and installing it." If you're using Python for scientific computing, you can use the Anaconda distribution of Python, it makes it painless to work with those packages. https://www.continuum.io https://www.continuum.io > "Also it seems that "inside Scipy' it is a different world, and that to really "talk to the outside world" there seems to be a data-translation step needed." Python has excellent ORMs, I'm not sure what you're getting at.
  - 11y ago
klibertp 11y ago
> or Go. If you like Go, try Nim - it's like Go but without all the dogma. I wrote a blog post about my little Nim project: https://klibert.pl/output/slock_in_nim.html https://klibert.pl/output/slock_in_nim.html > Why should I choose Python 3 for my new projects? You shouldn't unless it fits all the constraints of your new project. Choosing a language is not, for the most part, a technical decision: sure there are language features and implementation features (those are separate matters!), but in the end it comes down to external factors: your experience with a particular paradigm, your taste in syntax, skills of potential collaborators and so on. One thing of note, though: there is no rule saying that you can't use more than one language for your project. On the contrary, you can mix-and-match languages with relative ease nowadays (see https://klibert.pl/output/python_interop.html https://klibert.pl/output/python_interop.html) and, in my experience, it works rather well. For example, in one of my projects I need to scrape a bunch of websites for data and then process this data. I wrote scraper in Elixir, which made dealing with network errors and parallelizing requests a breeze, and used Python with Pandas for the analysis part. It was a very pleasant experience: neither Python nor Elixir were up to the task on their own, but they worked very well together. It's even easier when you use a JVM, .NET or JavaScript-based languages.
- muraiki 11y ago
  In Nim, isn't it the case that concurrency is thread based? Something I really like about Go is that goroutines are cheap green threads, not full OS threads. This lets me spawn as many goroutines as I like without worrying about exhausting a thread pool.
  - klibertp 11y ago
    There is some support for coroutines with async/await (http://nim-lang.org/docs/asyncdispatch.html http://nim-lang.org/docs/asyncdispatch.html), but I don't know how mature or functional it is, never tested it. As mentioned, for anything involving concurrency I'd rather use Erlang or Elixir; but it may be a good idea to see how well Nim does in this area.
sametmax 11y ago
Readability. Ease of scripting. Libs. Multi-paradigm. Simplicity to debug. Good instrospection. Expressivity. Fantastic community. Great documentation (because hey, docstrings). It's a no brainer to teach and to learn or train for and gives you good habits. And it does the job.
- mturmon 11y ago
  All you said, and also: the REPL and ipython.
marmaduke 11y ago
"Better the devil you know". If it's a professional project, I prefer not to have to learn the undocumented potholes of new language while debugging before a deadline.
tomchristie 11y ago
Fair question. I can only speak from my own experience here: Productivity, productivity, productivity. Yes, there are faster, safer, and more modern languages out there. However Python for me still hits nails the hell out of getting stuff done, really really quickly. That applies both to the language itself, and from the standpoint of having such an extensive and mature ecosystem of packages to choose from.
autoreleasepool 11y ago
Python is still king for really boring and maintainable scripts. I mean boring in the best way. Every Python script o read is clean and elegant. It's easy to follow and well organized. Python 3 doesn't seem to make it any better at this. In fact all Python3 does is annoy me. I never know when I need it or not, it never seems to be clear either. The fact that it's packaged as a separate entity (i.e. /user/local/bin/python3) is even weirder. Mastering Python-foo is still on my todo list, though. As a Ruby user, I've noticed that Python scripts are much more straight forward and maintable. I still write my scripts in Ruby though because nobody seems to mind. This is perhaps because I try my best write good comments. In general, Ruby is better as Perl replacement than a Python substitute. In fact, one of my coworkers who is an oldschool perl scripters was sold on Ruby over Perl just by reviewing one of my scripts. I think the issue is people don't think of Ruby outside of Rails, where it's basically a readable purely object oriented Perl. As an aside, I think there is a bigger overall problem of using scripting languages for application development. I wouldn't use Python, Ruby, or Perl for anything that was more than, say, 500 lines. I almost cried when I tried to read the code for homebrew. Not that it's bad code (it's quite good actually), it's just way too much duck typing for me. I could never keep all that type information in my head. I prefer to pass that cognitive load to the compiler.
- SEJeff 11y ago
  Fundamentally, python3 fixes some of the serious WATs in python2 and makes it easier to write high quality and maintainable software. For a pretty quick overview take a look at: https://migrateup.com/main-difference-python-3/ https://migrateup.com/main-difference-python-3/ Perhaps if python3 annoys you more than makes you say, "Hey, this prevents lots of latent bugs I might have easily shipped to production before, cool!", then you need to learn python a bit better and re-evaluate what is annoying about it.
  - owtM 11y ago
    I believe the parent was talking about python3 from a users perspective (they said they aren't a Python programmer) For example when a script requires python3 and another requires python. Python3 is also not included in a lot of base systems. That could be annoying.
fsloth 11y ago
You did not define what that project would be. I suppose you should first figure out the domain, then figure out the language support and ecosystem around that domain and then pick one. That is, if you are implementing something practical whose aim is to provide value outside of personal learning. For example, several constraints still lead to a situation where C++ is a prime choice unless one is mostly interestes in hacking in a new domain and not finishing a project. Note! I'm not dissing trying out languages for the joy of it! Personally, I would pick Python for experimenting with syntax transforms, data mining and such. And as a basis for any offline tool that needs to chug bits from one place to another. Also, the numerical use cases listed elsewhere. Basically, for anything that does not need a GUI.

Odin78 11y ago

Noob question: What's so difficult about deploying/distributing python?

hynek 11y ago
ATM it takes work to create a deployable artifact. We package virtualenvs using fpm, others use Docker. But Go just spits out a single binary you can scp anywhere (the build process OTOH is more painful IMHO). That’s why I’m highly curious about https://us.pycon.org/2016/schedule/presentation/2122/ https://us.pycon.org/2016/schedule/presentation/2122/ .
retrogradeorbit 11y ago
https://glyph.twistedmatrix.com/2015/09/software-you-can-use.html https://glyph.twistedmatrix.com/2015/09/software-you-can-use...
- monkmartinez 11y ago
  This should be the #1 comment/resource on this thread IMO.
  - zanny 11y ago
    I recently started writing a few Qt applications, and was strongly considering PyQt - I mean, why wouldn't I? The syntax is cleaner and I can get more work done faster using Python than C++. I spent a few days going back and forth - comparing the performance, design time, etc of both - and in the end I'm just using Qt's JS JIT for dynamic list comprehensions and other things C++ is bad at. In the end, the fact that distributing on everything but Linux would have been reduced to having to bundle CPython in was just a deal breaker. Linux isn't really bad for deployment, though. You can use the SUSE OBS to build packages for all the major platforms besides Arch, and since my main desktop is Arch, I'm building my software with PKGBUILD's from the get-go.
    - witty_username 11y ago
      Python isn't very big (about 10-20 MB or so). What's the problem with bundling CPython?
    - kweks 11y ago
      I've written a production app in Python 3 + QT4 (PySide as opposed to PyQT) - I've bundled with cxfreed, and it's great. Fully cross-platform.. easy to distribute. Quite nice all around.
- mixmastamyk 11y ago
  That page dismisses py2exe, but I've used it successfully for over a decade. On unix it is as simple as: sudo pip install [package/repo]
  - elktea 11y ago
    Except, you often need a full compiler toolchain for all the c dependencies. Then you need to make sure you have the required header files. Then you try and deploy to a small EC2 instance and run out of RAM building lxml or similar.

gnur 11y ago

I often dabble in other languages but in the end always return to python (3). What it offers for me truly is the batteries included and easy, memorable and predictable syntax. (Probably due to experience). Sure, Go is easier to deploy, Erlang and by extension Elixir are easier to scale. But python does align very well with my personal though process. I don't think parallel and I don't have race conditions in my mind. If I want to quickly write something that will perform decently, I choose python, because the time I save by not having to learn a new language could be days or perhaps even weeks. I guess it boils down to this: with my current experience, I'm more then 10 times as productive in python as I would be in any other language. Sure, it would be neat if I had as much experience in Erlang as I have in python, but that will take years, and at the end of the day, I'd rather finish my project this year with python, then next year with any other language.

crdoconnor 11y ago
>Sure, Go is easier to deploy Go's lack of a package manager making deployment more painful is the thing that made me come back to python.
- oofabz 11y ago
  Go is staticly linked, you don't need to deploy packages, just the binary.
  - hynek 11y ago
    But you have to build those with its dependencies. And the best thing Go came up with is vendorizing.
    - creshal 11y ago
      And good luck keeping everything updated. (Does go statically link the libc, too? If so, you should be rebuilding all your go applications right now, after the glibc issues reported on Tuesday…)

andrewstuart 11y ago

I never thought I'd say it, but I'm loving programming the new ES2105 version of JavaScript. It really has a great deal in common with Python now. Clearly many programming languages are converging as they implement common good ideas from other programming languages. That's going to mean that whilst Python might have distinguished itself in the past for being streets ahead, in the future it's likely that many languages will also have many of those same good ideas incorporated. I posted about it: What language has decorators, generators, comprehensions, modules, but isn't Python? http://fourlightyears.blogspot.com.au/2015/08/what-language-has-decorators-generators.html http://fourlightyears.blogspot.com.au/2015/08/what-language-...

coldtea 11y ago
The "all async" model of Node kills it for practical programming compared to Python... And the worst thing is, Node/v8's JIT would kill Python in performance for a;; the kind of things people write Python scripts for, even if it run all synchronous. It would be nice if callbacks/promises/async-await were only optional and for network/web things, not for everything.
- findjashua 11y ago
  async/await isn't too bad (es7 via babel)
- goldbrick 11y ago
  You can still use the "-Sync" versions of functions in the standard lib.
  - coldtea 11y ago
    Yes, but not hundreds of thousands of npm libs.
dragonwriter 11y ago
> I never thought I'd say it, but I'm loving programming the new ES2105 version of JavaScript. Well, yeah, I'm sure ES2105 is cool, but most of us don't have the choice of using languages from the next century.

natrius 11y ago

Most of my development experience is in Python, and Clojure's what excites me the most these days. I've had to write a lot of Javascript for work, and it turns out that there's a large community of Javascript developers who wish they were writing Clojure, and they've built libraries like tcomb, Immutable.js and transducers.js to get pretty close. In the transpilers era, Javascript will never be so bad that choosing another dynamic language is a clear win. I'd go back to Python and Django for a CRUD app, but since Javascript is easier to write in a functional style than Python, I've actually started to prefer it as a first choice.

oxplot 11y ago

I personally find python in general to align almost perfectly with the way I think about writing software. It's interpreted so I can do things like compiling dynamic python in my code or fall into a python shell for debugging. Majority of time, I can use the standard library to do everything I need. And I love the clean syntax of Python — always a pleasure to look at. As for Py3, the standard libs are very clean and streamlined, (e.g. io). Oddly enough, the point that I love about Py3 is its handling of unicode vs bytes (which most people find it difficult for some reason). I'm not sure what you mean by "can't target the browser"? I don't find distributing/deploying python to be difficult or even involved at all. I do get annoyed at the single CPU bound limitation. If I had to summarize why I'd pick Py3 for new projects, I'd say because it thrives in being minimalist and I hate clutter.

stdbrouw 11y ago

Pick Python for the sheer amount of libraries that's available. Not just for web stuff, where Node.js and Ruby do fine, but also for scientific work, for statistics, for embedded work (Raspberry Pi or MicroPython), for systems administration, for command-line tools, for really just about anything you can imagine. And you can do all of those things while not having to switch contexts between different syntaxes and different standard libraries for basic things like regular expressions or HTTP requests. Picking the best tool for the job often gets in the way of actually getting things done. Python is the true swiss army knife of today's programming languages.

abecedarius 11y ago
That's a good reason, but note that it used to be the reason you picked Perl.
- btreecat 11y ago
  Still a valid reason for people to chose Perl. Not advocating for Perl, just on behalf of Perl lovers like my office mate
- JupiterMoon 11y ago
  The difference is that most people can read most other peoples' python code. Perl didn't tend to have that quality. EDIT Added another "most" to make it clear that not everyone can write readable python.
  - collyw 11y ago
    That depends entirely on who is writing the code. I have seen some truly awful Python as well as truly awful Perl.
    - JupiterMoon 11y ago
      This difference is that I've mainly seen decent Python and mainly seen awful Perl.

IndianAstronaut 11y ago

If you are building an application which does a lot of machine learning and statistics, I don't see a better language than Python. It has so many libraries to use for it. Note, I love R, but I can't imagine building an application with it.

czep 11y ago
You can build apps with R, but the result will be the ugliest code you have ever seen. For me, R for research and prototyping, then Python for productionalizing.
- IndianAstronaut 11y ago
  Ugly isn't the problem. It is the poor error catching, erratic memory use, several ways to do one thing due to a lack of features in the standard libraries (regex), etc.

marklgr 11y ago

For personal projects, you can pick whatever language you want, possibly the most fun one that is still practical. Haskell or Elixir look promising in this regard. For companies, there are more factors to consider, eg. finding devs at a correct price, getting existing workforce to work on a new tech, size of standard/open source library, getting help and bugfixes from community instead of hacking on your own, risk of language/tech losing steam, etc. That's why several comparatively "boring" languages still thrive.

baldfat 11y ago

> I struggle to find a compelling reason to use Python at all My issue is I always see Python as the Second Best choice for what I am doing. There is always a better tool for the job. The one thing going for Python is that it is such a generalist BUT when doing work I prefer the Right Tool for the Job approach. I seriously can't think of a job that Python does best.

deleted 11y ago
[deleted]
antod 11y ago
> I seriously can't think of a job that Python does best. For me personally it is the best choice for non-throwaway shell scripting once the scripts becomes more complex and/or long lived than a sequence of shell commands. Python is part of the base install of just about every mainstream Linux distro, so in that regard its only real competitor is Perl.

mangecoeur 11y ago

For anything involving data analysis and scientific computing Python really shines - though I'm often surprised the extent to which web-oriented programmers are unaware of this, I read things like "you can write better web services in Go, therefore Python is obsolete". Python in science is kinda like the One Ring the Binds them - it is the glue that holds together the HPC code at CERN, ESA, NASA, and more, it crunches climate models and delivers your daily weather forcasts. Some really great projects like Cython, Theano, and Numba boost the performance of numeric code to native speeds with a fraction of the hassle of hand-written C. Mountains of machine learning research is done in Python, as well as statistics and analytics. And of course Numpy remains the de-facto standard of N-dimensional array libraries - if you look at numeric computing libraries in many other languages they will be framed as "Numpy-for-X".

raverbashing 11y ago
Yeah, I don't know While Numpy/Scipy is great with a capital G, it seems the underlying infrastructure is flaky. I'm talking about the messy process of building and installing it. And it seems everything is held with duct-tape Also it seems that "inside Scipy' it is a different world, and that to really "talk to the outside world" there seems to be a data-translation step needed.
- kmike84 11y ago
  at least on OS X installing numpy and scipy is very easy - pip installs prebuilt wheels by default, no need to compile anything
- ZenoArrow 11y ago
  > "I'm talking about the messy process of building and installing it." If you're using Python for scientific computing, you can use the Anaconda distribution of Python, it makes it painless to work with those packages. https://www.continuum.io https://www.continuum.io > "Also it seems that "inside Scipy' it is a different world, and that to really "talk to the outside world" there seems to be a data-translation step needed." Python has excellent ORMs, I'm not sure what you're getting at.
- 11y ago

klibertp 11y ago

> or Go. If you like Go, try Nim - it's like Go but without all the dogma. I wrote a blog post about my little Nim project: https://klibert.pl/output/slock_in_nim.html https://klibert.pl/output/slock_in_nim.html > Why should I choose Python 3 for my new projects? You shouldn't unless it fits all the constraints of your new project. Choosing a language is not, for the most part, a technical decision: sure there are language features and implementation features (those are separate matters!), but in the end it comes down to external factors: your experience with a particular paradigm, your taste in syntax, skills of potential collaborators and so on. One thing of note, though: there is no rule saying that you can't use more than one language for your project. On the contrary, you can mix-and-match languages with relative ease nowadays (see https://klibert.pl/output/python_interop.html https://klibert.pl/output/python_interop.html) and, in my experience, it works rather well. For example, in one of my projects I need to scrape a bunch of websites for data and then process this data. I wrote scraper in Elixir, which made dealing with network errors and parallelizing requests a breeze, and used Python with Pandas for the analysis part. It was a very pleasant experience: neither Python nor Elixir were up to the task on their own, but they worked very well together. It's even easier when you use a JVM, .NET or JavaScript-based languages.

muraiki 11y ago
In Nim, isn't it the case that concurrency is thread based? Something I really like about Go is that goroutines are cheap green threads, not full OS threads. This lets me spawn as many goroutines as I like without worrying about exhausting a thread pool.
- klibertp 11y ago
  There is some support for coroutines with async/await (http://nim-lang.org/docs/asyncdispatch.html http://nim-lang.org/docs/asyncdispatch.html), but I don't know how mature or functional it is, never tested it. As mentioned, for anything involving concurrency I'd rather use Erlang or Elixir; but it may be a good idea to see how well Nim does in this area.

sametmax 11y ago

Readability. Ease of scripting. Libs. Multi-paradigm. Simplicity to debug. Good instrospection. Expressivity. Fantastic community. Great documentation (because hey, docstrings). It's a no brainer to teach and to learn or train for and gives you good habits. And it does the job.

mturmon 11y ago
All you said, and also: the REPL and ipython.

marmaduke 11y ago

"Better the devil you know". If it's a professional project, I prefer not to have to learn the undocumented potholes of new language while debugging before a deadline.

tomchristie 11y ago

Fair question. I can only speak from my own experience here: Productivity, productivity, productivity. Yes, there are faster, safer, and more modern languages out there. However Python for me still hits nails the hell out of getting stuff done, really really quickly. That applies both to the language itself, and from the standpoint of having such an extensive and mature ecosystem of packages to choose from.

autoreleasepool 11y ago

Python is still king for really boring and maintainable scripts. I mean boring in the best way. Every Python script o read is clean and elegant. It's easy to follow and well organized. Python 3 doesn't seem to make it any better at this. In fact all Python3 does is annoy me. I never know when I need it or not, it never seems to be clear either. The fact that it's packaged as a separate entity (i.e. /user/local/bin/python3) is even weirder. Mastering Python-foo is still on my todo list, though. As a Ruby user, I've noticed that Python scripts are much more straight forward and maintable. I still write my scripts in Ruby though because nobody seems to mind. This is perhaps because I try my best write good comments. In general, Ruby is better as Perl replacement than a Python substitute. In fact, one of my coworkers who is an oldschool perl scripters was sold on Ruby over Perl just by reviewing one of my scripts. I think the issue is people don't think of Ruby outside of Rails, where it's basically a readable purely object oriented Perl. As an aside, I think there is a bigger overall problem of using scripting languages for application development. I wouldn't use Python, Ruby, or Perl for anything that was more than, say, 500 lines. I almost cried when I tried to read the code for homebrew. Not that it's bad code (it's quite good actually), it's just way too much duck typing for me. I could never keep all that type information in my head. I prefer to pass that cognitive load to the compiler.

SEJeff 11y ago
Fundamentally, python3 fixes some of the serious WATs in python2 and makes it easier to write high quality and maintainable software. For a pretty quick overview take a look at: https://migrateup.com/main-difference-python-3/ https://migrateup.com/main-difference-python-3/ Perhaps if python3 annoys you more than makes you say, "Hey, this prevents lots of latent bugs I might have easily shipped to production before, cool!", then you need to learn python a bit better and re-evaluate what is annoying about it.
- owtM 11y ago
  I believe the parent was talking about python3 from a users perspective (they said they aren't a Python programmer) For example when a script requires python3 and another requires python. Python3 is also not included in a lot of base systems. That could be annoying.

fsloth 11y ago

You did not define what that project would be. I suppose you should first figure out the domain, then figure out the language support and ecosystem around that domain and then pick one. That is, if you are implementing something practical whose aim is to provide value outside of personal learning. For example, several constraints still lead to a situation where C++ is a prime choice unless one is mostly interestes in hacking in a new domain and not finishing a project. Note! I'm not dissing trying out languages for the joy of it! Personally, I would pick Python for experimenting with syntax transforms, data mining and such. And as a basis for any offline tool that needs to chug bits from one place to another. Also, the numerical use cases listed elsewhere. Basically, for anything that does not need a GUI.