3 ms·

While I adore Python generally and use it all the time (including for two startups), here are a few things that I find unintuitive: 1. List comprehensions are

While I adore Python generally and use it all the time (including for two startups), here are a few things that I find unintuitive: 1. List comprehensions are hard to read and understand, especially for beginners. I tutor online in Python, and when I show a student a list comprehension, it is one of the most difficult parts of the language to explain. Do you read left to right, or inside to outside? Postfix if at the end makes things even more confusing. There are better alternatives in languages like Ruby and JavaScript. Which brings us to the next point: 2. No native map, filter, reduce, etc. methods. It is far easier to explain that you are just calling another method on a list/array than it is to get a beginner to trust the hocus-pocus apparent in Python's list comprehensions. Edit: Python has built-in functions for map and filter. See correction by ubercore below, and my response. 3. The way a class is accessed from an instance in Python is not nearly as elegant as Ruby's. Do I use "type(obj)" or make a direct call with "obj.__class__"? Neither is as clean or intuitive as "obj.class". 4. Speaking of classes, why are built-in classes like "str", "int", "float", etc. lowercase while in everything else they are conventionally CapitalizedClasses? 5. Remembering that "sorted(my-list)" returns a new sorted list while "my-list.sort()" does the sort in-place requires experience, which someone taking an Intro to Programming course will probably not accumulate over 8 or even 14 weeks. Note: I flirted with Ruby and Rails, but never built anything real with them. I vastly prefer Python to Ruby (and Django to Rails), but think Ruby got a lot of things right.

ubercore 9y ago
No native map or filter? Unless I don't understand what you mean by native, don't https://docs.python.org/3/library/functions.html#map https://docs.python.org/3/library/functions.html#map and https://docs.python.org/3/library/functions.html#filter https://docs.python.org/3/library/functions.html#filter and https://docs.python.org/3/library/functools.html#functools.reduce https://docs.python.org/3/library/functools.html#functools.r... count?
- ralmidani 9y ago
  Thank you for correcting me. I edited my post above to reflect that. But having to provide a lambda for the simple case makes them less useful. Also, nested function calls are less readable than chaining method calls on the same object.
mercer 9y ago
Without going into the specifics, I'd argue that, in general, teaching programming using a 'multi-paradigm' language (Python, Javascript, Ruby) is inherently more confusing than picking one that focuses more exclusively on one paradigm. I tried to do as much functional programming in Javascript as I could, and yet I feel I only really learned it when I started working with languages that are 'heavily' functional. Of course, I'm not saying that a 'multi-paradigm' language for teaching is bad, but personally I'm inclined to think that it might be better to start with something more pure. Ruby might actually not be a bad choice in this scenario. If you avoid the 'blocks, lamdbas and procs', it seems to me like a great introduction to OO programming. Despite this, for my day to day programming I would also choose Python over Ruby. But perhaps not for teaching.
empthought 9y ago
1. Try teaching your students the standard notation for set building -- that's where it comes from, and it's useful outside of Python. https://en.wikipedia.org/wiki/Set-builder_notation https://en.wikipedia.org/wiki/Set-builder_notation 2. They're all still there, but they're not as good as comprehension syntax. 3. Use type(self) unless you know why you'd want to use __class__ (Python 2 old-style classes). 4. That's legacy; probably if things were done from scratch today, they'd be Int, Str, Float. Back when the names were chosen there was a stricter line between builtins and unset-defined classes, and there was more consideration given to people migrating from C and C++. 5. Yes, luckily the .sort() method gives you at least some hint by not returning anything. It's a good application of command-query separation, but I forget it often myself.

ubercore 9y ago

No native map or filter? Unless I don't understand what you mean by native, don't https://docs.python.org/3/library/functions.html#map https://docs.python.org/3/library/functions.html#map and https://docs.python.org/3/library/functions.html#filter https://docs.python.org/3/library/functions.html#filter and https://docs.python.org/3/library/functools.html#functools.reduce https://docs.python.org/3/library/functools.html#functools.r... count?

ralmidani 9y ago
Thank you for correcting me. I edited my post above to reflect that. But having to provide a lambda for the simple case makes them less useful. Also, nested function calls are less readable than chaining method calls on the same object.

mercer 9y ago

Without going into the specifics, I'd argue that, in general, teaching programming using a 'multi-paradigm' language (Python, Javascript, Ruby) is inherently more confusing than picking one that focuses more exclusively on one paradigm. I tried to do as much functional programming in Javascript as I could, and yet I feel I only really learned it when I started working with languages that are 'heavily' functional. Of course, I'm not saying that a 'multi-paradigm' language for teaching is bad, but personally I'm inclined to think that it might be better to start with something more pure. Ruby might actually not be a bad choice in this scenario. If you avoid the 'blocks, lamdbas and procs', it seems to me like a great introduction to OO programming. Despite this, for my day to day programming I would also choose Python over Ruby. But perhaps not for teaching.

empthought 9y ago

1. Try teaching your students the standard notation for set building -- that's where it comes from, and it's useful outside of Python. https://en.wikipedia.org/wiki/Set-builder_notation https://en.wikipedia.org/wiki/Set-builder_notation 2. They're all still there, but they're not as good as comprehension syntax. 3. Use type(self) unless you know why you'd want to use __class__ (Python 2 old-style classes). 4. That's legacy; probably if things were done from scratch today, they'd be Int, Str, Float. Back when the names were chosen there was a stricter line between builtins and unset-defined classes, and there was more consideration given to people migrating from C and C++. 5. Yes, luckily the .sort() method gives you at least some hint by not returning anything. It's a good application of command-query separation, but I forget it often myself.