The Incredible Growth of Python • Hacker News Board

Re: The Incredible Growth of Python

#101

Post by int_19h » Thu, Sep 07, 2017, 3:25 AM UTC

jaco8 wrote: post #43

coldtea wrote: post #11

Earlier quoted context omitted.

Don't hold your breath. Nim doesn't have the kind of ecosystem, and hasn't shown signs of having one.

Do not worry ,still breathing here , when I started Fortran,RPGII and Cobol was the thing and Python did not exist. Now Python is becoming the old elephant and new languages like Nim will evolve and they will grow an ecosystem over time.

It's undeniable that some new languages will supplant the current bunch (except possibly for C; this thing might well be unkillable by this point). But I don't see any particular reason why it would be Nim.

Re: The Incredible Growth of Python

#102

Post by kranner » Thu, Sep 07, 2017, 3:28 AM UTC

joshuamorton wrote: post #55

photojosh wrote: post #53

Earlier quoted context omitted.

Why won't it be the fastest? I didn't think there would be any difference between "native" in the system paths and in a virtualenv.

So, for things like tensorflow, you have to build from source to enable certain optimizations. Wheel's aren't source builds essentially.

I think GP is talking about virtualenv, not pip. Using an optimized build in a virtualenv environment should not be any slower than using it outside the environment, right?

Re: The Incredible Growth of Python

#103

Post by e12e » Thu, Sep 07, 2017, 3:32 AM UTC

ufmace wrote: post #40

brianwawok wrote: post #27

Earlier quoted context omitted.

Really? Pip should be pretty straight forward. Maybe you use different libraries than I do.

I do mostly Ruby professionally and dabble in Python, and I agree with heydonovan. Pip works fine for installing things, but near as I can tell, Python has no equivalent of bundler - a tool to install specific versions of a bunch of libraries, generate a lockfile ensuring that your production server and all of the devs are all running it with the same version of everything, and letting you have as many versions of a…

> Python has no equivalent of bundler - a tool to install specific versions of a bunch of libraries

Zope and plone, the project(s) that came up with python eggs, used to have the concept of "known good sets"[1], which were massaged and used with zc.buildout :

http://www.buildout.org/en/latest/

I'm not sure I'd recommend it for greenfield projects - splitting things up in sane-sized chunks, and using the now in-standard-lib vevn (python3 -m venv) is probably a better idea.

But just for the record, there exists a canonical(ish) solution to some of these issues in python-land.

[1] http://grok.zope.org/doc/community/life_cycle/known_good_set...

Re: The Incredible Growth of Python

#104

Post by princeb » Thu, Sep 07, 2017, 3:39 AM UTC

BeetleB wrote: post #82

pen2l wrote: post #9

Earlier quoted context omitted.

Three of us (including me), in an academic lab, are making the jump from matlab to python. We use py3 (of Anaconda, on Windows10). We like it, but we are constantly screaming and bitching about the complications of 2 3 ("Ahhh X and Y module only works on py2!", "Ahhh device developer only provides example code for Labview and Matlab!", "Ahhh python isn't even supported for this device/application!"). Package manageme…

>I think the one thing we are all learning from this experience is: JUST USE UBUNTU, doing python with Windows is a headache. Meh. I use python on Windows all the time - it's not a problem. Mostly pip just works. Of course, I have over a decade of experience with Python - albeit only the last few years in Windows.

the #1 issue i have with py on win is having to download a million different C++ compilers esp for packages not distributed on pip, and esp the more obscure ones with no support whatsoever (e.g. data processing or math packages that were put together by some chap who was working on it for a specific set of research papers and has since moved on).

chris gohlke's website was a real lifesaver back then, although now pip seems much better. nowadays it can be a bit difficult replicating environments across different machines especially since conda is moving rapidly from python ver to ver while some obscure packages i rely on are still stuck on 3.4 or earlier... or if c++ 10.0 or 9.0 or 14.0 is not set up correctly. then it becomes an issue of crossing fingers and hoping "python setup.py install" doesn't fail.

Re: The Incredible Growth of Python

#105

Post by sotojuan » Thu, Sep 07, 2017, 3:39 AM UTC

stupidcar wrote: post #22

twobyfour wrote: post #12

The chart there really emphasizes to what degree Java, C++, and to a lesser degree Javascript are used as teaching languages. There's a clear cyclical pattern in their question frequency that presumably corresponds to academic semesters.

Hmm. Interesting that JS's cycle is the inverse of Java's. People learning Java during term-time, then JS during their holidays?

This was the case in college. We had C++ classes but people learned Python and JS during breaks for internships because the are very little C++ jobs for college students.

Re: The Incredible Growth of Python

#106

Post by erikb » Thu, Sep 07, 2017, 3:45 AM UTC

pen2l wrote: post #9

andrewstuart wrote: post #6

Python 2 advocates were quite firm in telling us that Python 3 and its incompatibility with Python 2 had killed Python and people would abandon Python altogether in droves for other languages. This post is suggesting the opposite, that Python is more healthy than ever and growing incredibly fast.

Three of us (including me), in an academic lab, are making the jump from matlab to python. We use py3 (of Anaconda, on Windows10). We like it, but we are constantly screaming and bitching about the complications of 2 3 ("Ahhh X and Y module only works on py2!", "Ahhh device developer only provides example code for Labview and Matlab!", "Ahhh python isn't even supported for this device/application!"). Package manageme…

Actually I always complain about Python packaging when I'm only using Python. But the moment I start using it in other languages I dream about the comfort and professionalism of tools in Python.

Of course in scientific Py you need compiled C attachments, which makes it more complex. But in normal Py usage you only need pip. Easy Install is only needed when you don't have pip installed. Pip is a drop in replacement with additional features.

And at least from what I heard for everything with C compiled stuff inside ("binary packages") you use conda.

So not that hard actually.

Re: The Incredible Growth of Python

#107

Post by mark-r » Thu, Sep 07, 2017, 4:08 AM UTC

alcalde wrote: post #73

coldtea wrote: post #13

Earlier quoted context omitted.

> While this is an interesting statistic there is no additional analysis that it correlates to python's usage growth. You believe that Python would ever generate more questions over time on SO without getting more users/usage? I guess the mysterious dumbing down of a stable user base is an alternative explanation.

I get this same thing from the Delphi users forum, where the diehards strain to convince themselves that Delphi has "three million users" and "is about as popular as Python". They insist that there's no reason Stack Overflow questions should be correlated with real-world usage. One suggested, seriously, that perhaps Delphi is just so easy to use that users don't need to ask questions. This excuse has been adopted to…

Sounds like cognitive dissonance. I learned a lot about it by reading the Dilbert blog over the last couple of years. Here's an earlier example: http://blog.dilbert.com/post/102627908761/job-satisfaction

Re: The Incredible Growth of Python

#108

Post by StavrosK » Thu, Sep 07, 2017, 4:17 AM UTC

SimbaOnSteroids wrote: post #67

StavrosK wrote: post #35

Earlier quoted context omitted.

I agree (Django is life), but I find myself wanting the new optional typing and type checker to mature so I can add them to my set of linters. I'm tired of 1) not knowing whether I made a mistake and passed something of the wrong type and 2) not being able to see at a glance what types each function is supposed to accept and return.

How large, in your experience, does an app need to get before it outgrows django?

I'm not sure, I haven't managed to write an app that large yet. I'm also not sure how you can outgrow Django, since you can always split off parts of your codebase, or not use the parts of Django you don't need.

I've recently written a flask application too, and I found myself having to reinvent the wheel at every step, and I cursed a lot. Django's ecosystem, both in libraries and in sheer community documentation, is hard to replicate.

Re: The Incredible Growth of Python

#109

Post by yen223 » Thu, Sep 07, 2017, 4:24 AM UTC

brianwawok wrote: post #76

ufmace wrote: post #40

Earlier quoted context omitted.

I do mostly Ruby professionally and dabble in Python, and I agree with heydonovan. Pip works fine for installing things, but near as I can tell, Python has no equivalent of bundler - a tool to install specific versions of a bunch of libraries, generate a lockfile ensuring that your production server and all of the devs are all running it with the same version of everything, and letting you have as many versions of a…

pip install -r requirements.txt Pretty simple, no? Most any python project I have seen in the last 5-6 years uses it.

requirements.txt don't track transitive dependencies. Your project could break if a dependency decided to swap out its own dependencies. This isn't theoretical either - it happened to us in production.

We are using `pip-tools` to manage that: https://github.com/jazzband/pip-tools

Re: The Incredible Growth of Python

#110

Post by princeb » Thu, Sep 07, 2017, 4:27 AM UTC

photojosh wrote: post #54

nl wrote: post #50

Earlier quoted context omitted.

This is true. Even the Le Cunn group has switched to PyTorch I think. It's also because no one can work out how to use matplotlib properly, so you need to look at about 1000 StackOverflow questions per line of code.

To be fair, this was also true when I was using Matlab back before switching to Python (2006ish!), except you had to dig through documentation instead of just having everything immediately available on SO. :)

the matlab documentation, imo, is the best technical documentation ever written for anything. if your background was more math-heavy then the docs provided easy to understand translation between recognizable mathematical idioms into code (if matlab wasn't already very math-idiomatic).

and back in 2010 or so, python's numerical optimization libraries left a lot to be desired, and totally hopeless compared to matlab. (edit, i don't remember it being nearly as good as octave, which wasn't particularly good either back then).