3 ms·
No, it's not super common, IMHO. Python doesn't really even lend itself to altering syntax in significant ways (though some of the libraries he mentioned have
by SwellJoe 9y ago
No, it's not super common, IMHO.
Python doesn't really even lend itself to altering syntax in significant ways (though some of the libraries he mentioned have low-level C implementations that can/do alter Python syntax). If you're doing scientific computing you're going to see some new things that don't entirely look like Python. Things like matrix math and the like have new types and (mildly new) syntax. But, I don't think it's surprising for people who know Python.
I guess there may be some cognitive dissonance that comes from using projects that paper over Fortran and C++ libraries with light Python wrappers (a lot of scientific computing libraries, again...so, not often new syntax, but not very Pythonic, either).
The specific example mentioned of matplotlib (and SciPy and Numeric, etc.), probably comes from the origins of the library...it was intended to make it easy for people coming from Matlab to switch to Python for the same sorts of tasks, so it's conceptually a mashup of the two.
But, maybe the argument should just be "walk before you run", rather than singling out any particular library. Particularly if those libraries might be the sole reason the person is learning Python. Sounds like the person he was helping out with her matplotlib problem really wanted to be working with matplotlib and the scientific computing ecosystem Python offers. You've gotta learn them eventually if that's the kind of work you want to do with Python. They might be a little weird, but they're not a whole new language.
- paultopia 9y agoDefinitely in the data science stack though. For example: how pandas behaves with slicing, and copy vs view semantics are totally different from vanilla python, and are confusing enough coming from vanilla python. God help you if you learn pandas and python at the same time.
- vram22 9y ago>how pandas behaves with slicing, and copy vs view semantics are totally different from vanilla python, and are confusing enough coming from vanilla python Can you give a few examples of this?
- paultopia 9y agoSure thing. For slicing, see Jake VanderPlas's book: https://jakevdp.github.io/PythonDataScienceHandbook/03.02-data-indexing-and-selection.html https://jakevdp.github.io/PythonDataScienceHandbook/03.02-da...) that describes the complexities -- some kinds of pandas slicing include the last index, some kinds don't. View vs copy is even worse. There are some situations where indexing on a DataFrame yields a view, some situations where it yields a copy, and they are effectively indeterminate in a lot of situations. From the Pandas documentation https://pandas.pydata.org/pandas-docs/stable/indexing.html#indexing-view-versus-copy https://pandas.pydata.org/pandas-docs/stable/indexing.html#i...: See that __getitem__ in there? Outside of simple cases, it’s very hard to predict whether it will return a view or a copy (it depends on the memory layout of the array, about which pandas makes no guarantees), and therefore whether the __setitem__ will modify dfmi or a temporary object that gets thrown out immediately afterward. By contrast, the vanilla python rules are much simpler: slicing always leaves off the last index, and the rules for view vs copy of mutable data structures like lists are at least determinate...
- vram22 9y agoThanks for the reply. I can see how it can be confusing, and more so for that indeterminate part.