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()))
Homogenization of scientific computing – Python is eating other languages’ lunch
131–140 of 184 posts
Re: Homogenization of scientific computing – Python is eating other languages’ lunch
#132Re: Homogenization of scientific computing – Python is eating other languages’ lunch
#133Earlier 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!
Re: Homogenization of scientific computing – Python is eating other languages’ lunch
#134Earlier 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…
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
#135Earlier 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…
Re: Homogenization of scientific computing – Python is eating other languages’ lunch
#136For 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…
Re: Homogenization of scientific computing – Python is eating other languages’ lunch
#137Earlier 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.
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
#138For 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…
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
#139I 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?
Re: Homogenization of scientific computing – Python is eating other languages’ lunch
#140Earlier 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…