71–80 of 242 posts
Earlier quoted context omitted.
Out of curiosity: why?
I use map(print, list_of_tuples) quite a bit, but that possibly an artifact of my print-based debugging. I can only do this with print as a function rather than a statement, and the single line makes it easy to drop in or comment out as needed.
This isn't intended to be obstreperous, but I'm genuinely curious: How many Python developers are in a position to really care about 2 vs 3? The people I know who use Python, including myself, range from utter beginners to experienced programmers, but are using a relatively small subset of the available libraries, and are just using whichever version we started with. I could translate my code to version 3 in a heartb…
One pain point I've really felt recently with Python is in the deploy step. pip installing dependencies with a requirements.txt file seems to be the recommended way, but it's far from easy. Many dependencies (such as PyTables) don't install their own dependencies automatically, so you are left with a fragile one-by-one process for getting library code in place. It was all fine once I got it worked out but it would so…
You should avoid using normal requirements.txt files in production. If you want to use pip, it's better to "pip freeze" your test environment, and use that requirements file to specify the production environment. Otherwise you are just asking for nasty surprises when packages upgrade.
If you want to keep up to date with security and bug fixes (but aren't yet ready for the next big feature/backwards incompatible release), you can specify the lines as 'package>=1.1,`pip list --outdated` is helpful, too.
All the same, I'm continuously amazed at the arrogance of the people that maintain the language and set its direction. It's no wonder it's been a colossal failure. You know why I'm not running python 3? Because it doesn't solve a single problem I have. It doesn't solve anyone's problems. It solves imaginary problems, while creating real problems.
A few reasons Python is gaining ground in academia. Firstly, Python is _great_ for teaching undergraduate programming (see [0] for a good perspective), and many institutions are only now catching on and migrating from Matlab. Secondly it is a charitable language allowing scientists to concentrate on their research and not the CS implementation they are using. It is easy to learn, flexible, has lots of scientific libraries, interfaces to fortran/C libs. Julia is supposedly the future with speed being cited as the primary advantage[1], but it far from taking over. From a preliminary investigation into Julia it had less lib support, but most importantly, less inertia. The popularity and relative 'newness' of Python (compared to fortran/C) has meant that docs, blogs, forums, stackoverflow allow anyone to get involved and quickly overcome beginner hurdles and learn best practices. Finding which module interface for a C lib is easy. Comparatively, finding information on Julia's library support is much harder. As to why not use Fortran/C - well, if I need to suddenly share part of my data in JSON, make a plot in matplotlib, or generate a PDF/website for my data all the tools are easily accessible.
Python often gets a bad rap for speed, but this is rarely the problem it is made out to be. Python is best when used as a high level manager sitting on top of low level routines written in C/Cython. Following best practices means I do not a deep understanding of how compilers work to speed up my code, I just need to know how to pass off my data to an existing routine interfacing with LAPACK/BLAS or what have you where some really really smart CS people have already done all the optimisation.
Finally, it has a massive advantage over many other languages: Great documentation and a large community. This gives Python an inertia that the Go and Julia can't achieve yet. Julia, Go, and Closure all have dedicated communities (based on the number of mentions on HN), but the size of the community and their distribution biasing developer interests mean the barrier of entry is higher.
As these languages and their communities mature and grow, Python's advantage might diminish, but then we will just have more tools to choose from, and that would be great.
[0] http://lorenabarba.com/blog/why-i-push-for-python/ [1] http://julialang.org/benchmarks/
Earlier quoted context omitted.
You should avoid using normal requirements.txt files in production. If you want to use pip, it's better to "pip freeze" your test environment, and use that requirements file to specify the production environment. Otherwise you are just asking for nasty surprises when packages upgrade.
Or just specify versions in your requirements.txt file to begin with. If you want to keep up to date with security and bug fixes (but aren't yet ready for the next big feature/backwards incompatible release), you can specify the lines as 'package>=1.1, `pip list --outdated` is helpful, too.
I'd love official pip support for ~1.1 type declarations.
The idea that people move from Python specifically to Go is one of those chestnuts of conventional wisdom that never receives any kind of backing in actual data. If you think that Python and Go are made for the same tasks then you're really confused.
Right. Students in my Python classes (who typically come from static, compiled languages) are always asking me how quickly certain operations execute, or how much memory is used. I try to explain to them that obviously Python developers care about these things, and I show them some of the most common pitfalls. But this isn't the first, or even fifth, thing that you think about when you're coding in Python. The key th…
Why should I even bother with Python 3?
Earlier quoted context omitted.
I use map(print, list_of_tuples) quite a bit, but that possibly an artifact of my print-based debugging. I can only do this with print as a function rather than a statement, and the single line makes it easy to drop in or comment out as needed.
map(print, list_of_tuples) does not work on Python 3 unless you wrap it in list(). In any case it's a anti-idiom because it creates a useless list. Please don't do that.
Seeing how my transition to Py3 got hung up on sending bytes in and out of ZeroMQ sockets, I might stop that now.
Back to the for loop or join the strings as suggested below.