
PyCon 2015: Are we still changing the world? - tedmiston
http://blog.lisnr.com/2015/05/11/pycon-2015-are-we-still-changing-the-world/
======
jaimebuelta
As a Python developer myself, I think that the community is very "pragmatic
engineering" oriented (explicit better than implicit, get things done,
simplicity, maintainability, etc)

The focus is on getting things done, today and tomorrow; not be trendy or be
on the first page of HN or disrupt the language space using a new paradigm.

Python is "silently?" used A LOT. Not only on web development (which has more
the spotlight on the Internet) but in areas like systems scripting, data
analysis or science research. I think that is a great language with a lot of
opportunities (including career opportunities) that is still growing.

Yes, it's not the new kid in town. I think of it more as an advantage, really.

~~~
tedmiston
Our pragmatism is one of the biggest factors that draws me to Python as a dev.

I agree about our significant use outside of web dev -- even though I know a
lot of it is "out there", I had a hard time gathering it with many major orgs
not being on CrunchBase, AngelList, or StackShare, (and some with a footprint
that doesn't represent their true size on GitHub). If there's a source for
this data out there, I'd love to find it.

------
ianbicking
Is Python changing the world, or Go, or Ruby, or Javascript? If you are asking
about "changing the world" that's a big thing to ask for. Simply being useful
doesn't make a technology world-changing. I feel very confident that Go will
not change the world. People may use Go to make things that change the world,
but Go won't change the world. If Python has changed the world – that is the
language itself has done so, not just the people using the language – then I'd
look mostly to its community, governance, and development process. For Ruby
I'd look to its culture, philosophy, and discourse. Javascript actually has a
technical claim to changing the world: it's created a programming platform
that requires no installation of software, and has brought sandboxed
development into the world in a broad and practical way. But if we look at
Node.js/IO.js, a Javascript platform with similar scope to Python, then I
personally see a generational reinvention: a platform that a new generation of
budding developers can call their own, and make their own decisions. Asking a
lot of questions that no one actively considers in these older platforms.

But there's lots of other things that can change the world besides programming
languages. Are programming languages really the best place to hang your hat?
Do you want to compare Python to Ruby or Node.js, or compare Python a web
application or wiki or the cloud; i.e., entirely different categories?

~~~
bsg75
"People may use $LANGUAGE to make things that change the world, but $LANGUAGE
won't change the world."

~~~
coldtea
Which makes total sense.

It's the things (end product) that matter, and unless they could
only/better/easier be implemented in $LANGUAGE, then it could have been many
other languages that could have been used as well.

Whereas something like C did change the world.

------
darkxanthos
Right now, a huge opportunity for Python seems to be data science. I didn't
notice it in the list of places where Python shows up. Also, in that space, it
more than just shows up, it brings unique capability to the space with its
libraries and the support major tool developers have for it.

~~~
baldfat
Python is still over shadowed by R in data science.

I stopped using Python for data science and use R and it really worked out
great for me. R has gained a lot of momentum and I think that Pandas with Wes
leaving isn't being developed as quickly. (Most of it is re-doing what R has
done). I am amazed at all the FUD I was told to not use R and just use Python
but after hitting so many walls I tired it and I am so glad I did. Your
millage may vary.

~~~
PaulHoule
R is an awful language with great libraries.

My main beef about R (and similar tools) is that I summarize my data I get
from Hadoop and find it is still too big for R to handle and I then have to
summarize it some more.

~~~
baldfat
R does not deserve to be called awful. It is a language that works for many
people, people make a living from it and is one of the fastest growing
languages.

[1] [https://blog.javascripting.com/2014/07/28/fastest-growing-
ne...](https://blog.javascripting.com/2014/07/28/fastest-growing-new-
languages-on-github-are-r-rust-and-typescript-and-swift/)

[2] [http://www.pcworld.com/article/2480920/r-programming-
languag...](http://www.pcworld.com/article/2480920/r-programming-language-
gaining-ground-on-traditional-statistics-packages.html)

[3] [http://redmonk.com/sogrady/2015/01/14/language-
rankings-1-15...](http://redmonk.com/sogrady/2015/01/14/language-
rankings-1-15/)

Yes I have read [R Inferno] [http://www.burns-
stat.com/pages/Tutor/R_inferno.pdf](http://www.burns-
stat.com/pages/Tutor/R_inferno.pdf)

------
vegabook
For me, the only place where Python truly excels versus the competition is
Numpy. The easy python scaffolding gets you to the heart of a problem in a
friendly and flexible way, and then you can interface easily to this big V8 of
a compute engine (especially if you combine it with the MKL libraries). The
ecosystem around Numpy is astronomically good.

I have fallen in love again with Python (2) for this reason. I tried 3 but I
don't need all it's accountant-like seriousness. It's less fun to code in.
When I need to design for servers or for performance I will do golang or
ocaml. When I need simple scaffolding for numerical work, and scripting for
prototyping integration of various systems, Python 2.7 is like an old,
unfussy, friend, helping me along my long and winding data wrangling road with
a minimum of cognitive tax. It just works. Long may it live.

In my view the Python powers should look at numerical / data science and throw
all of Python's weight behind that, and forget about the web, where they've
already lost.

~~~
alexhill
Can you articulate what you mean by Python 3's "accountant-like seriousness"?
Is there more to it than print-as-a-function?

I code in both every day and just don't see what the fuss is about. To me,
they're barely different dialects; more like different accents.

~~~
vegabook
First of all I don't think the print statement is a small issue. I bet 5% of
my code is print statements. I _love_ the print statement's unfussy "can do"
mentality. Hey, the whole reason I got into Python was because it was utterly
barebones. Print "hello world". that's it. You can almost feel the fun a young
GvM might have had making it.

Then all this u"xx" stuff on strings. What's that about? I don't care about
unicode. 256 ascii characters is fine for me. If I need Unicode I can do it,
but I don't need it by default.

Iterators instead of ranges. Fine. Why again? To save memory? I've got 32
billion bytes. I don't need it. It's complicating something to please the
computer scientists and it's messing with my mind which has far bigger
problems to solve, so it's unpragmatic. If I see htop moaning about memory, I
can easily change my code.

Generally, I just like the 2.0 attitude. It's carefree. It just works. Three
is trying too hard. Python is just a tool for me. My really hard problems are
my daily battles with nonconvex optimization of vast data sets.

~~~
tedmiston
> Then all this u"xx" stuff on strings. What's that about? I don't care about
> unicode. 256 ascii characters is fine for me. If I need Unicode I can do it,
> but I don't need it by default.

I felt this way before I started spending all of my time on web apps. It's
reading user input data from some random public source, like Twitter, that
forces it upon you. Then, so quickly it became the best practice to "unicode
all the things". I think of analogous to how we store timestamps in UTC
always.

~~~
jMyles
One difference, though, is that time enjoys a certain natural and intrinsic
consensus. For example, we all agree that observable time always flows forward
at the same rate.

OTOH: Which characters do and don't belong in unicode and in what order? I
don't fucking know. :-)

~~~
KMag
> OTOH: Which characters do and don't belong in unicode and in what order? I
> don't fucking know. :-)

Should we use decimalized time or time based on the Babylonian base 60/12
system? Both have clear advantages. I don't fucking know. :-)

The world has standardized on Unicode, which (as a collection of expanding
standards) defines the set of valid code points and their order. There's still
some debate as to UTF-8 vs. UTF-16LE (and perhaps UTF-16 w/BOM and UTF-32)
encodings, but Unicode has clearly won. It's not perfect, but it's silly to
pretend Unicode hasn't won.

Source: I used to work as an engineer on the content converter portion of
Google's indexing system, which took the world's web pages, PDFs, etc. and
converted them into a unified format (the text portion of which is encoded as
UTF-8) for the rest of the indexing system. Sure, we saw some percentage of
EUC-KR, GB2312, Big5, and Win CP1252 text, but Unicode has clearly won and
UTF-8 and UTF-16LE are steadily replacing all other encodings.

------
rwhitman
Is the Python 2 vs Python 3 thing ever going to be resolved?

If you look at Python adoption from the perspective of someone picking it up
for the first time, the very first issue they encounter is the "which version
of Python should I use" debate, which pretty much frames the experience from
that point onward.

The pragmatic attitude that's kept Python 2.X afloat is a key part of why
Python has had longevity but it also doesn't set a great tone for "changing
the world" or keeping up with the latest sexy fads

~~~
techdragon
Ubuntu 16.04 LTS is going to be Python 3 by default. I switched to Python 3
only a year ago. The war is over, Python 3 won, and now it's just the "too big
to fail" guys who still think Python 2 has a future. Google, Dropbox and a few
others who will probably give it another5 years before they make the switch
using 3.5's type hints to help automate the process of moving to Python 3.

~~~
xorcist
There was never a war, and Python 3 didn't win it.

We're still not seeing any mainstream Python 3 adoption (no, I don't count
your own project). PyPI downloads was still < 5% last I checked. The big web
frameworks are still better tested and better performant with 2. Scientific
computing is stuck with 2. Same with Ansible. And the big companies you
mention have no (public) intention to migrate.

The core developers decided long ago that 3 is what everyone should use, so I
have no doubt that will be the case. The open question is how much is left of
the ecosystem by then. It's commonly discussed at conferences but there is no
straightforward answer. At least we got the TLS stuff backported to 2 which
might be indicative of a coming thawing.

~~~
tedmiston
> We're still not seeing any mainstream Python 3 adoption

I think mainstream adoption is _increasing_ , but not as quickly as anyone
would like. The sentiment around adoption I felt echoed at PyCon this year
was: "we have dependencies that aren't ported to 3 yet [... and who will be
the ones to port them?!]".

~~~
vegabook
The Python 2 codebase is growing much faster than Python 3, because the Python
core developers have lost touch with the fact that its most dedicated users
are _not_ web people, but scientific computing users for who the overwhelming
choice is 2.7. Anaconda gives you a 3.x choice on its website almost as an
afterthought. Theano is half hearted on 3. Bloomberg doesn't even have a 3
access library (goodbye 3.0 for the _entire_ finance sector). Asyncio, one of
the so called killer features of 3, looks great but is 10 years too late and
is done much better in other languages (goroutines). Python is seriously
losing momentum: hey, even Hacker News quickly demoted this story to page 2
precisely because it attracted the usual flood of 2v3 comments causing the
comment number to dwarf the score. It's become a controversial and uncool
language thanks to this forced 3 story, and the fact that 6 years later in
this dog-years world, this issue is still on the table, makes 3 an utter
failure.

I predict that 2.7.9.x.y.z will continue well past 2020 and backport any truly
useful stuff from 3 because that's much easier than porting 2 code to 3. Or,
and the core developers should seriously think about this, they should build
2->3 right into the interpreter so you can run, _unmodified_ 2.7 code on a 3
interpreter (2.7 libraries included), and then pick and choose the 3 features
you want yourself.

------
PaulHoule
I think there is a certain kind of sloppiness in Python culture that holds it
back.

For instance, the split between Python 2 and Python 3 has kept from me getting
more into Python because I have to choose one or the other in terms of which
libraries I want to be compatible with (and the libraries are a big reason I'd
want to to use Python.)

If you look at Java or PHP or .NET there is a lot of concern about keeping
compatibility between versions, but going from 2 to 3 they changed a lot of
APIs that they didn't have to.

The most disturbing thing is that I have been shouted down for years on places
like proggit for bringing this issue up but it is only in the last year that I
have seen it talked about by pythonistas, and that's a general problem I see
with Python, that it ducks the hard questions which Java, in particular, faces
before anyone else. (i.e. having a memory model for threads which is mature)

On one hand, the GIL means that Python is not scalable in terms of threads.
Today 4 core machines are mainstream, even for phones, and with a language
that supports scalable threads, you can get a 4x speedup easily for many real
apps.

The other option is go to the Node route, which is balls-to-the-walls async
operations in a single process, but (i) the async people also have had a
culture of "kicking the can down the road", (ii) it is hard to get programmers
who are used to sync APIs to switch to async (this is one reason why the
"Modern" interface in Win 8 was DOA... Microsoft was pushing people to use
Javascript because rewriting Win32 apps to be async defeats the purpose of
using Win32 which is being able to use all the old stuff and not learning
anything new.)

~~~
msellout
There are many ways to get around the GIL. Use PyPy. Use processes. And are
you really doing that much computation? Threads on standard CPython are
perfectly fine for I/O.

~~~
actsasbuffoon
PyPy still has a GIL: [http://pypy.readthedocs.org/en/latest/faq.html#does-
pypy-hav...](http://pypy.readthedocs.org/en/latest/faq.html#does-pypy-have-a-
gil-why)

~~~
msellout
Doh. I should have said, "Use Jython."

------
copsarebastards
To be honest, I think the influence of the Ruby/Rails ecosystem is hurting
Python. In the last few years, it's become impossible to run many Python
projects without doing a pip install -r requirements.txt. That in itself would
not be a problem, except that many pip packages are buggy and poorly
maintained. Few people take the time to vet such libraries because the effort
involved in a pip install is so low. The result is that we often spend hours
configuring a buggy library instead of writing code that would do a better job
solving our problems. "Convention over configuration" is no less important
than it always was, but it's certainly less fashionable.

There are exceptions. Django rest framework, for example, is an extremely
mature, well-made library. But these are becoming less of a percentage of the
whole and are harder to find in the chaff.

And there are a few projects still carrying the torch--but typically these are
old projects that have been around for a long time, still maintained by older
developers who were writing Python when Python was young. We still have at
least a decade before these old masters start retiring, so I don't think
Python will die any time soon. But it has become more important than ever to
be careful what you let into your dependencies.

~~~
tedmiston
This one resonates with me.

Though I haven't used either myself yet, I've noticed the trend in automated
code quality tooling becoming more popular in Python. Specifically, the ones
that come to mind are: Codacy, Code Climate (both free for open source); and
Landscape.

Personally I'm still using strong classics like coverage and pylint, but plan
to explore the new gen stuff soon.

------
streamline92
The Python GIL problem could been solved in Python3 by just moving all global
interpreter instance variables into a single struct and changing the C API to
take a pointer to this interpreter struct as the first argument in all C API
functions. No thread local variable hacks need be used and all interpreter
instances could have been completely independent of each other, allowing for
seamless and efficient share-nothing multi-threading. Python3 was not intended
to be 100% compatible with Python2 anyway, so it was a perfect opportunity to
fix this long standing design bug. But this opportunity was lost.

Strangely, the Google V8 team repeated Python's API design error and also
relies on global interpreter variables and thread-local variables to swap
interpreter contexts, or "isolates" in V8-speak. Although my understanding is
that the V8 team recognizes the problem and are (slowly) addressing it and
changing their APIs accordingly with each successive release.

------
rkuykendall-com
Python is changing the world more than ever before, by becoming the new
default.

I know undergrad CS students, masters CS students, non-CS professionals well
into their career, and non-CS hobbyists. And they are all writing Python. Five
years ago when I was doing my undergrad, that would have been Java, or C++.

It's not exactly an exciting change from a HackerNews viewpoint, but it's
pretty amazing for programming as a whole. The people I know are so much more
excited to be learning. There is frustration, but much less than when I knew
people learning on C++. Obviously that's still a fantastic language, but I'm
happy Python is the new default.

~~~
tedmiston
I was excited when MIT switched to Python for setting the trend for other
schools to follow that it's okay to teaching computing from the top down.

------
woah
Python is a very nice language, but a big stumbling block is the poor package
management. Contrasting this with node, which makes it as easy as possible to
build modular software, python's packages are a big step backwards.

~~~
mpdehaan2
I'm not following this. Can you give examples of features in node?

Given, the quality of things in any community repo, and the namespacing, are
often terrible, but this hasn't ever kept me from using good things out of it.

I'm also not sure how it can be a step backwards, as Python is quite a bit
older :)

One thing I don't like about npm is folks are starting to store non-npm things
in it, which I think may because of the weird situation of npm getting
funding. I don't understand that just as much as I wouldn't understand PyPi or
CPAN getting funding :)

~~~
carrja99
The key difference between pypi and npm is that if you pull a package down and
it depends on something==1.0.2 and you depend directly on the incompatible
something==0.8.9 both version live together in peace because only request will
use 1.0.2. With pypi (and most other dependency management systems) you'll
have to make a choice on which one you want to use and in this example you'll
have to choose an older version of the library depending on something==1.0.2.

~~~
abstractbeliefs
This has been largely solved with virtualenvs where those collisions happen on
the system level, but I concede it's harder when the mutually incompatible
requirements are in the same project.

~~~
tedmiston
If I'm understanding the question correctly, I agree virtualenv +
virtualenvwrapper solves it _mostly_. For what I consider a decent treatment
of some of the shortcomings in pip vs. npm, I found this post helpful:

"Things I wish Pip learned from Npm" [https://medium.com/@alonisser/things-i-
wish-pip-learned-from...](https://medium.com/@alonisser/things-i-wish-pip-
learned-from-npm-f712fa26f5bc)

------
EToS
Im currently migrating a large FTSE100 web application stack from
Java/SpringMVC over to Python/Django.. Its been a long journey (4 years!) to
unhinge Java as the given option, but Pythons proven time and time again to
save millions per project, and often with better results because developers
can concentration on product rather than framework problems.

