Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Python to NumPy (2017)

labri.fr

Post reply on HN
Print view View original

71–78 of 78 posts

Re: From Python to NumPy (2017)

#71

Post by eesmith »

z9znz wrote: post #67
eesmith wrote: post #54

Earlier quoted context omitted.

> 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…

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

No, I am not.

As you must surely know, "simple" is not a well-defined concept. Forth is a simpler language than Python. Yet I am certainly not saying it's as good a language for beginners.

I'm saying that languages can be treated as a user interface, and improved based on feedback with the target audience. Python - unlike most other languages - incorporated insights from developing the ABC language as a teaching language for non-programmers.

Your "We want a beginner language" description is too broad as it also describes ABC, without including discussion of why Python succeeded where ABC did not.

> Ruby is superior in the simple beginner case

If you are basing things on your intuition and personal experience, then my intuition and experience says otherwise.

That's why these arguments are rather pointless.

> One small but significant feature Ruby provides

Yes, I get it - you like Ruby. But shrug some people like Fords while others prefer a Chevy.

And still my point is that Python explicitly incorporates design elements based on experience from teaching non-programmers to program. If it's part of Ruby, it's much less of an emphasis.

That's nothing at all to do with a language feature, which was your focus earlier.

Re: From Python to NumPy (2017)

#72

Post by z9znz »

nickles wrote: post #62
z9znz wrote: 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…

> 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.…

> if expr: x = 1

But PEP8 and now the all-too-popular Black formatter disallow this. I think it's fine.

The momoization/optimization point is exactly the opposite of what should be a default use case for a beginner friendly language. And I highly doubt this mutable default design was intentional for these purposes. They are footguns.

Re: From Python to NumPy (2017)

#73

Post by z9znz »

coderenegade wrote: post #38
z9znz wrote: post #21

Earlier quoted context omitted.

Use any language you like to build a proof of concept. But one you need to take that POC and build a real product which needs to be supported, extended, and maintained, then you must choose tools which fit that long term need. Many of use first experienced school in kindergarten. Kindergarten was an important step in our education and socialization. But we didn't refuse to move on to the next level, no matter how muc…

The issue with a lot of the gripes with Python is that there's no other language that combines mature linear algebra libraries, scientific computing libraries, and industry standard computer vision libraries with easy to use basic tools like csv reading, dataframes, json parsing, etc., while also providing easy syntax and fast iteration time. I work in C++ and Python, and things that are completely trivial in Python…

I would not advocate for rewriting everything in non-Python. It is what it is, and it excels at tasks related to the important libraries discussed in this topic.

Just as Python wraps the libraries which do the heavy lifting in C, I would try to keep the Python wrapper as minimal as possible and stick some interface in front of that. Instead what happens often is people choose to either build more and more around this important stuff, staying with Python, or they say, "We're better off just supporting one language in-house, and Python is required already; so we are a Python shop."

Re: From Python to NumPy (2017)

#74

Post by ramblingsnake »

The problem is deeper in that, because NumPy is bloated too (see https://numpy.org/doc/stable/reference/generated/numpy.mean.... versus https://numpy.org/doc/stable/reference/generated/numpy.nanme...).

Perhaps even further, the shift now is for "Python" to be written in neither vanilla Python nor NumPy directly, but at times in PyTorch or TensorFlow where each library provides its own workarounds.

Re: From Python to NumPy (2017)

#75

Post by ChrisRackauckas »

workingon wrote: post #56
ChrisRackauckas wrote: post #53

Earlier quoted context omitted.

Please post a concrete example of one that you have ran into.

Previous discussion on hn: https://news.ycombinator.com/item?id=27960865

Can you share one explicit example that is still there today? IIRC the things from that thread were all solved.

Re: From Python to NumPy (2017)

#76

Post by p1esk »

mjburgess wrote: post #70
deshpand wrote: post #65

Earlier quoted context omitted.

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

Yes. I'm not even sure what is Python used for these days, other than ML/Data Science.

Re: From Python to NumPy (2017)

#77

Post by dragonwriter »

p1esk wrote: post #76
mjburgess wrote: post #70

Earlier quoted context omitted.

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

Yes. I'm not even sure what is Python used for these days, other than ML/Data Science.

> Yes. I'm not even sure what is Python used for these days, other than ML/Data Science.

Well, if you look at the thing it has actively maintained libraries for with active communities, it's a lot besides ML/DS.

Re: From Python to NumPy (2017)

#78

Post by dragonwriter »

DigiDigiorno wrote: post #3

I'm totally a fan of educational work aimed at a subset of programmers. And I myself went from Python to NumPy. This would have been great if it was around when I was working with SciPy stuff. That said, I think a NumPy to Python, or really any big package or framework to Python (e.g. Django to Python) is the normal progression these days. People seem to learn the language through a package and end up with some misle…

> That said, I think a NumPy to Python, or really any big package or framework to Python (e.g. Django to Python) is the normal progression these days.

It always has been common from the time Python had popular domain-focussed libraries that could be used without deep knowledge of the rest of the language, but once you get there you also tend to move out to other specialized packages.

Post reply on HN