6 ms·

I wouldn't say Python is dominant in startups across the board. Though it is strong in data-heavy environments (with all it's issues nonetheless). I've been a

I wouldn't say Python is dominant in startups across the board. Though it is strong in data-heavy environments (with all it's issues nonetheless). I've been a Pythonista for over a decade, and the API scene isn't quite as utopian as you describe. Date/time handling in particular is a really poorly handled area, but there's quite a few out there. That said, in general I agree the 'batteries included' approach is good, and the libraries _tend_ to be easy to use for most tasks. Compared to most Java libraries, it's a breath of fresh air.

cyphar 11y ago
> Though it is strong in data-heavy environments (with all it's issues nonetheless). Which is why numpy and scipy are so full-featured and pretty damn fast.
- drvortex 11y ago
  Techincally, Numpy and SciPy are C and Fortran extensions to Python, not Python code.
  - gh02t 11y ago
    I'm not sure if that's the best way to describe them. IMO, NumPy/SciPy are probably best described as Python wrappers for a wide range of C and Fortran codes, but they add quite a lot of value on top of that. If you've ever used e.g. LAPACK or VODE directly, you'll probably have horrible memories that you prefer not to recall. NumPy and SciPy have a large contribution in that they unify (admittedly, neither is really a paragon of consistency, but...) a huge range of disparate libraries under a much more accessible interface. To say NumPy or SciPy is just the sum of the libraries it uses is a bit like calling MATLAB a fancy interface for LAPACK. That really was what MATLAB was intended to be originally, but to reduce it to that is missing the appeal. As somebody who absolutely loathes MATLAB, even I wouldn't think that is fair.
  - deleted 11y ago
    [deleted]
  - Scarblac 11y ago
    Libraries are what make a language. The major feature of Python for me is that all its various open source modules for anything n-dimensional (matrices, image processing, GIS, machine learning, etc etc) all use the same data structure: the Numpy array. It's basically part of the standard library that is developed outside of it for pragmatic reasons. And with the speed of Fortran array operations. That's something that only Matlab really has as well, but Python is much better in other aspects.
meowface 11y ago
I think there's more of an interest in scalability and compile-time checking among startups nowadays, hence the shift from dynamic languages to lightly static languages like Go or all of the type-checking and Haskell-derived JS variants out there. This means Python and Ruby aren't as much of a first choice as they used to be, even if they're arguably a lot faster for getting MVPs out.
- snuxoll 11y ago
  > I think there's more of an interest in scalability and compile-time checking among startups nowadays Which is precisely why all of my new code targets Python 3 and I use PEP 484, and before that I always had type information in my docstrings. There's some places where duck-typing makes sense, but a lot of times I'm really just doing things like I would in a statically typed language so I just type the crap out of everything and run MyPy against it. Unfortunately the runtime itself doesn't benefit at all from the type information, but I know I any of my .Net-centric colleagues can easily inherit any of the Python code I've written and be able to read it without much headache - without having to intuit what magic goes on behind the scenes, especially with things like the Pyramid request/context objects.
ForHackernews 11y ago
> Date/time handling in particular is a really poorly handled area Just use Arrow http://crsmithdev.com/arrow/ http://crsmithdev.com/arrow/ everywhere, all the time(s). Now your date/time problems are solved.
- kdeldycke 11y ago
  Couldn't agree more. Developing for the last couple of years code that is highly sensitive to dates and time, and Arrow saved my life.

cyphar 11y ago

> Though it is strong in data-heavy environments (with all it's issues nonetheless). Which is why numpy and scipy are so full-featured and pretty damn fast.

drvortex 11y ago
Techincally, Numpy and SciPy are C and Fortran extensions to Python, not Python code.
- gh02t 11y ago
  I'm not sure if that's the best way to describe them. IMO, NumPy/SciPy are probably best described as Python wrappers for a wide range of C and Fortran codes, but they add quite a lot of value on top of that. If you've ever used e.g. LAPACK or VODE directly, you'll probably have horrible memories that you prefer not to recall. NumPy and SciPy have a large contribution in that they unify (admittedly, neither is really a paragon of consistency, but...) a huge range of disparate libraries under a much more accessible interface. To say NumPy or SciPy is just the sum of the libraries it uses is a bit like calling MATLAB a fancy interface for LAPACK. That really was what MATLAB was intended to be originally, but to reduce it to that is missing the appeal. As somebody who absolutely loathes MATLAB, even I wouldn't think that is fair.
- deleted 11y ago
  [deleted]
- Scarblac 11y ago
  Libraries are what make a language. The major feature of Python for me is that all its various open source modules for anything n-dimensional (matrices, image processing, GIS, machine learning, etc etc) all use the same data structure: the Numpy array. It's basically part of the standard library that is developed outside of it for pragmatic reasons. And with the speed of Fortran array operations. That's something that only Matlab really has as well, but Python is much better in other aspects.

meowface 11y ago

I think there's more of an interest in scalability and compile-time checking among startups nowadays, hence the shift from dynamic languages to lightly static languages like Go or all of the type-checking and Haskell-derived JS variants out there. This means Python and Ruby aren't as much of a first choice as they used to be, even if they're arguably a lot faster for getting MVPs out.

snuxoll 11y ago
> I think there's more of an interest in scalability and compile-time checking among startups nowadays Which is precisely why all of my new code targets Python 3 and I use PEP 484, and before that I always had type information in my docstrings. There's some places where duck-typing makes sense, but a lot of times I'm really just doing things like I would in a statically typed language so I just type the crap out of everything and run MyPy against it. Unfortunately the runtime itself doesn't benefit at all from the type information, but I know I any of my .Net-centric colleagues can easily inherit any of the Python code I've written and be able to read it without much headache - without having to intuit what magic goes on behind the scenes, especially with things like the Pyramid request/context objects.

ForHackernews 11y ago

> Date/time handling in particular is a really poorly handled area Just use Arrow http://crsmithdev.com/arrow/ http://crsmithdev.com/arrow/ everywhere, all the time(s). Now your date/time problems are solved.

kdeldycke 11y ago
Couldn't agree more. Developing for the last couple of years code that is highly sensitive to dates and time, and Arrow saved my life.