Live data from Hacker News

From Python to NumPy (2017)

labri.fr

61–70 of 78 posts

Re: From Python to NumPy (2017)

#61

I think the readability issue of vectorized numpy if often ignored (while readability is one of the main strength of python in my opinion). I could not resists to write the example of section 2.2 in Julia: using Random, BenchmarkTools seq = rand(0:2,10_000); sub = rand(0:2,4); # translation of the "readable" but slow python code function_1(seq, sub) = [i for i in 1:(length(seq)-length(sub)) if view(seq,i:i+length(sub…

Blame python for being off in the weeds adding syntax for software engineering (eg., walrus operator), and not for data analysis.

[deleted]

Re: From Python to NumPy (2017)

#62
post #33

Earlier quoted context omitted.

I'm not a Pythonista by any means, but these complaints are banal. Ternary operators? Plenty of new popular languages don't have a ternery operator (Go, Rust, Elixir, Kotlin, Nim). My list of python gripes are long, but language constructs are not on the list.

The point is about inconsistency. You can say "x = 1 if expr else 2", but you cannot say "x = 1 if expr". You do a two line if expr: x = 1 You cannot say "x = 1 if expr else return". [1] is a list with one item, 1. {1} is a set with one item, 1. (1) is a number, 1, with pointless parenthesis. Perhaps you mean (1,), a tuple containing only one value. Or how about mutable default values in function paramters? That make…

> You can say "x = 1 if expr else 2", but you cannot say "x = 1 if expr". You do a two line

This one liner works:

    if expr: x = 1
> Or how about mutable default values in function paramters? That makes a lot of sense...

This can be helpful under certain circumstances (e.g. memoization) [1]. The linked article also points out that it can be useful for rebinding global names in optimized code.

[0] https://stackoverflow.com/a/1145781

[1] https://web.archive.org/web/20200221224620id_/http://effbot....

Re: From Python to NumPy (2017)

#63

I feel like I never use directly numpy anymore. All my data is in Pandas, and I mostly import numpy for the odd `df.transform(np.somefunction)` I remember it being quite fun to build these vectorized numpy functions (in the crosswords and puzzles are fun, kind of way) Figuring out how to make a transformation in Pandas is always frustrating, when it isn't straightforward.

That's funny, I went the opposite direction. I only use pandas if I need to group by and aggregate, or to use in plotting functions. When doing array operations, I pretty much always use numpy, figuring out how to broadcast and vectorize operations is one of the most fun parts of my job in my opinion.

Re: From Python to NumPy (2017)

#64

I feel like I never use directly numpy anymore. All my data is in Pandas, and I mostly import numpy for the odd `df.transform(np.somefunction)` I remember it being quite fun to build these vectorized numpy functions (in the crosswords and puzzles are fun, kind of way) Figuring out how to make a transformation in Pandas is always frustrating, when it isn't straightforward.

That's funny, I went the opposite direction. I only use pandas if I need to group by and aggregate, or to use in plotting functions. When doing array operations, I pretty much always use numpy, figuring out how to broadcast and vectorize operations is one of the most fun parts of my job in my opinion.

I have had the same experience and instead of Pandas have been using numpy-groupies to handle aggregate/groupby operations. It's quite performant and feels a bit cleaner to use than importing pandas for a couple operations.

https://github.com/ml31415/numpy-groupies

Re: From Python to NumPy (2017)

#65

I think the readability issue of vectorized numpy if often ignored (while readability is one of the main strength of python in my opinion). I could not resists to write the example of section 2.2 in Julia: using Random, BenchmarkTools seq = rand(0:2,10_000); sub = rand(0:2,4); # translation of the "readable" but slow python code function_1(seq, sub) = [i for i in 1:(length(seq)-length(sub)) if view(seq,i:i+length(sub…

Blame python for being off in the weeds adding syntax for software engineering (eg., walrus operator), and not for data analysis.

I think it's helpful to keep in mind that Python is general purpose and used in many domains in addition to data analysis (no matter which side of the walrus operator you are on)

Re: From Python to NumPy (2017)

#66

I think the readability issue of vectorized numpy if often ignored (while readability is one of the main strength of python in my opinion). I could not resists to write the example of section 2.2 in Julia: using Random, BenchmarkTools seq = rand(0:2,10_000); sub = rand(0:2,4); # translation of the "readable" but slow python code function_1(seq, sub) = [i for i in 1:(length(seq)-length(sub)) if view(seq,i:i+length(sub…

[deleted]

Re: From Python to NumPy (2017)

#67
post #54
post #14

Earlier quoted context omitted.

I use Python all day every day. It's horrible compared to many other languages I have used. There are many versions of hype promoted for Python. Coal powered steam locomotives were great in their day, before there were better alternatives. But we don't irrationally hold the mentality that there is nothing better and why would you need anything else anyway? Tell me any library which can only be built for Python? Tell…

> Tell me any library which can only be built for Python? Are you really making the "every programming language is Turing-computable" argument? All your talk of features is missing an important point - Python is one of the few languages designed with insight from how to develop a programming language for non-programmers. In Python's case, experience drawn from ABC. These are people for whom "public class java { publi…

You are just arguing that a simple language is good for beginners, and I agree with that.

We want a beginner language which has easy (and consistent) syntax, no requirement to specify datatypes (implicit), and can be interpreted (no compiling required).

In its most basic use, namely just writing procedural code with basic built-in data structures, Python is pretty ok. But it has some warts and gotchas, not the least of which is mutable default parameters in functions.

Now maybe the ultimate beginner doesn't use defaults for parameters, so it's not a problem (yet) for them. Same goes for the OO features. While the beginner may not write OO Python, using modules written by other people probably will require them to step into the Python version of OO. Now it gets messier.

Ruby is superior in the simple beginner case and the complex (OOP) case. It is superior and more consistent for functional cases as well, despite it not being designed as a functional language (it still has mutability risks all over the place as does Python, except for that default parameter razorblade).

The only beginner-unfriendly thing I can think of for Ruby is the optional parenthesis on function calls. I still think optional parens is a bad design choice, and I encourage people to always use them. It's usually a style choice (but not always, because sometimes it matters for how code is parsed), and I think it's better to know as a reader that foo.bar() is a function being called. foo.bar is unclear.

One small but significant feature Ruby provides is the ability to write more expressive function names with ? and !. A common pattern is to use foo? to indicate that the function will return a boolean. The alternative, without ?, is is_foo(). Likewise, ! usually (at least for standard libraries) indicates mutation.

Back to the point though, Python used simply in isolation is not terrible for a beginner. But inevitably outside modules will get used, and the misfeatures of Python will appear more frequently. And then a further eventuality is that this new programmer will now be a "python programmer", choosing Python for future bigger work because that's what they know. Why not start with a language that is also beginner friendly but also better for large, long-lived projects?

Re: From Python to NumPy (2017)

#68
post #42
post #33

Earlier quoted context omitted.

The point is about inconsistency. You can say "x = 1 if expr else 2", but you cannot say "x = 1 if expr". You do a two line if expr: x = 1 You cannot say "x = 1 if expr else return". [1] is a list with one item, 1. {1} is a set with one item, 1. (1) is a number, 1, with pointless parenthesis. Perhaps you mean (1,), a tuple containing only one value. Or how about mutable default values in function paramters? That make…

These are pointless nitpicks. Every language has things like this. In 4 years of using Python in anger I’ve never written a line of code that could be improved by the features you list.

> These are pointless nitpicks. Every language has things like this. In 4 years of using Python in anger I’ve never written a line of code that could be improved by the features you list.

This is exactly the kind of response one often hears from the Python community. Translated it means, "I'm ok with it this way, so who cares if it could be better?"

Re: From Python to NumPy (2017)

#69
post #46
post #18

Earlier quoted context omitted.

The “luck” Python ran into was that some people came together to write NumPy. The alternatives at the time were Matlab and R. Matlab is not a great general programming language and is expensive. R has esoteric syntax and also isn’t a great general purpose language. This shift didn’t happen so long ago that it can’t be remembered. It certainly didn’t happen because it was installed by default by some Linux distros. Fo…

Yes, it was some luck ... and a lot of hard work. But it wasn't only NumPy that helped. I was around in the 1990s when Python started making waves in the scientific computing and research community. Python wasn't installed by default (we mostly used IRIX back then). Python was excellent for "steering" low-level computations, to use the buzzword at the time. That is, if you had a large body of existing C, Fortran, wha…

This is the only reasonable comment in this whole thread. Python's was growth was basically organic, NumPy/SciPy/etc. are later extensions of that organic adoption.

Re: From Python to NumPy (2017)

#70

Earlier quoted context omitted.

Blame python for being off in the weeds adding syntax for software engineering (eg., walrus operator), and not for data analysis.

I think it's helpful to keep in mind that Python is general purpose and used in many domains in addition to data analysis (no matter which side of the walrus operator you are on)

I think it was. It isnt now. It should develop its syntax in response to its actual users, not now, merely the subset it has been serving for 20yr
Post reply on HN