Live data from Hacker News

Homogenization of scientific computing – Python is eating other languages’ lunch

r-bloggers.com

131–140 of 184 posts

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#131
post #111

Earlier quoted context omitted.

Actually that's not 'highly proficient'. This is: def read_words(words_file): return [word for line in open(words_file, 'r') for word in line.split()] len(set(read_words('test.txt')))

len(set(open("test.txt").read().split()))

Oh, I like this one. Not quite what OP asked, but very clean.

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#132

Earlier quoted context omitted.

GP asked for counts, not uniques.

Oops, you're right. words = open("test.txt").read().split() [(k, len(list(g))) for k, g in groupby(words, lambda x: x)]

Doesn't that require an "import itertools"?

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#133
post #58

Earlier quoted context omitted.

+1 I'm a user of both, fan of both, but the lightness of Lua is a big plus. The main downside, IMO, is that the Lua user base is smaller so there's more need to roll your own solutions for things that Python already has several libraries for.

"roll your own solutions" - that's part of fun!

For a personal project, sure, but if it's a work project that has to get to the goal line along with ten other things, right NOW!, then it's nice to have some drop-in libraries that "just work".

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#134
post #128
post #95

Earlier quoted context omitted.

Deliberately-straightforward -- agreed. But "highly proficient" after writing one or two scripts? That's quite a stretch. For instance, one of the questions I give in phone screens is for the candidate to write a program to count the number of occurrences of unique words in a text file. The "after writing one or two Python scripts" approach is something like this: counts = {} f = open('test.txt') lines = f.read().spl…

My solution: lines = [line for line in open("bible.txt")] words = [word for line in lines for word in line.split()] counts = {word:0 for word in words} for word in words: counts[word] += 1 No imports needed. Linear time. A bit inefficient in the dictionary comprehension, but easy to read. The "lines=" and "words=" can be compressed into one line, but I figure this is a bit easier to read for people who aren't familia…

> A bit inefficient in the dictionary comprehension, but easy to read.

If you allow one import to sneak in, I think a `defaultdict` would do nicely. :-)

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#135
post #109

Earlier quoted context omitted.

Thanks for this reply. I thought the "bizarre blind spot" comment was some sort of (absurd) thought that numpy users were unaware that C was being used under the hood. > it eventually will catch up and surpass two-language systems for scientific computing. Assuming that, like hardware engineers, scientists have a fair bit of general-purpose scripting to do, Julia will itself be part of a different kind of two-languag…

In addition to what jamesjporter mentioned, Julia has IMHO a very nice, clean shell interaction paradigm for this very use case ("glue"): http://julialang.org/blog/2012/03/shelling-out-sucks/ One of the best examples of this is the package manager's concise wrapping of git CLI commands: https://github.com/JuliaLang/julia/blob/master/base/pkg/git.... (aside: there has been some discussing of moving to libgit2 for perf…

WRT shell integration, a follow up post details the safe (no code injection) and straightforward Julia implementation.

http://julialang.org/blog/2013/04/put-this-in-your-pipe/

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#136
post #16

For scientific computing with some R or Matlab/Octave background, I suggest the new language Julia: http://julialang.org/ Scientific computing Python community commonly use version 2.x there is the migration step to version 3.x ahead..

For me, Python has everything I need, among which there are many things that R or Matlab have not. If I should summarize what makes Python so suited for the things I do (and did when I was still doing research) it's the following: Python is an easy to use scripting language that can be integrated with number-crunching C/C++ code and for which a scientific standard library _with a vibrant community_ exists. Also, I ha…

C is directly callable from Julia.

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#137

Earlier quoted context omitted.

You've missed the point. NumPy and friends are a mass of C code with some Python bindings.

Which is completely irrelevant, since the users of it are writing python code.

>Which is completely irrelevant

Except for the reasons that the people who brought it up mentioned, which is why they brought it up.

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#138
post #16

For scientific computing with some R or Matlab/Octave background, I suggest the new language Julia: http://julialang.org/ Scientific computing Python community commonly use version 2.x there is the migration step to version 3.x ahead..

For me, Python has everything I need, among which there are many things that R or Matlab have not. If I should summarize what makes Python so suited for the things I do (and did when I was still doing research) it's the following: Python is an easy to use scripting language that can be integrated with number-crunching C/C++ code and for which a scientific standard library _with a vibrant community_ exists. Also, I ha…

>> Also, I haven't written a piece of 2.x code in half a year, which is of course only possible because scipy and matplotlib are 3.x ready.

Whoa. I didn't know people like you existed in the wild. Someone needs to contact the authorities and let them know that you exist.

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#139
post #43

I know that I use python because of how easy it is to code. I can focus wholly, totally on the logic of my code without ever worrying about if I misplaced a semi-colon or left out some weird punctuation. Python frees me to code and not worry about things that get in the way of coding. That's why it's eating other language's lunches, the freedom is almost intoxicating.

So you are enabled to focus wholly since you are used to its syntax?

I really do think Python's convenience is more than just familiarity. I found it very quick to learn and easy to remember compared to other languages.

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#140
post #91
post #50

Earlier quoted context omitted.

> Getting the indentation right should be the least of your worries if you have a good editor I never understood that. The whole problem for me is that the indentation being the only thing denoting blocks the editor can't know for sure how things should be indented, since it's not simply cosmetic. I haven't written a whole lot of Python but how do you even refactor python code? In C I can just copy paste a block of c…

Indeed that is a problem when you are copy-pasting huge blocks of code. In deeply nested code it can be difficult to determine whether the nesting should be say 28 or 32 spaces. In practice, most people shy away from writing such code because to many levels of nesting is hard to follow. People also prefer to write atomic 5-15 line functions in which keeping track of the nesting levels is trivial. Many C# and Java-hea…

If you're an Emacs user, have you tried Esc-/ (or M-/) for autocompletion? Note that this works in any mode, not just Python mode.
Post reply on HN