Live data from Hacker News

Drawbacks of Python

quora.com

51–60 of 117 posts

Re: Drawbacks of Python

#51

Earlier quoted context omitted.

Obviously nobody cares what I think, so perhaps you would prefer the words of Armin Ronacher, the creator of Flask. http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/

I've been using python for years now, I don't know the last time I had to use `sys.stdin`. I (like most people) deal with `open`, and unicode-only file apis (or the very nice things like flask that mitsuhiko and others have built). For most people, this isn't a problem. I've migrated literally, 10s of thousands, of files from py2 to 3. I've yet to encounter an issue with surrogateescapes or sys.stdin. Unicode issues…

I certainly wouldn't trust Python to open the standard streams correctly, explicitly check the mode/encoding or reopen the descriptor.

Re: Drawbacks of Python

#52

Almost every discussion of programming languages falls into bike-shedding[1] and this is no exception. The only thing he mentions worth talking about is the GIL. Syntax and small API gotchas can be learned by a beginner programmer in a matter of days of using the language, and are fairly irrelevant to your overall experience. If whitespace and using the division operator are big problems for you, significant software…

> Syntax and small API gotchas can be learned by a beginner programmer in a matter of days of using the language, and are fairly irrelevant to your overall experience. I agree with the first part but not the second. One can only write arraylist.add(arraylist.size() - 1, arraylist.get(arraylist.size() - 1) + 1) before wondering if there’s a better way to do this.

Even if your language doesn't support a better syntax, it probably supports functions, so you don't have to write this over and over again. Just pull out into `appendLastIncremented(ArrayList a)` and call that.

You'll have forgotten the pain of writing that function within an hour. I'll never forget the pain of debugging a {bar: 1}.baz returning undefined (failing silently) and then going into a future inside a minified 0.0.2 versioned library that doesn't do any constraint checking before finally throwing an exception. Nor will I forgive JavaScript for this.

Re: Drawbacks of Python

#53
post #32

I like Python because of zen of python [1]. This fits my brain and had been very helpful. Indeed in 2004 I chose Django instead of Ruby On Rails just because explicit is better than implicit. Overall Python is productive and good. Yes it has some warts and corner case, but than its evident. Among programming language python has a humble community and very approachable. Also most programmer in Python will not hesitate…

I agree with a lot of these things, but actually disagree that Python is good at exemplifying some of them. For example, semantic whitespace is arguably implicit, hard to read, invites density (compared to an extra line for braces), and (again arguably) is ugly. Yes, some of these things are subjective, but it's hard for me to confidently recommend Python to someone with these values.

I can't even tell you how many hours I've lost due to someone committing an incorrectly indented line in python. This often happens during merge conflicts, for example.

Because logic in python is interpreted via indentation, it's very difficult for python to realize when a line is indented incorrectly. It just assumes that if a line is indented a certain way, it was intentional.

In programming languages like Ruby or Javascript, indentation is stylistic and has no effect on the logic. You can actually use the "auto-indent" feature of many editors, and you can use linting tools to ensure formatting. If you have an extra "end" or an extra ending bracket, your IDE can immediately warn you. Not so with python!

Re: Drawbacks of Python

#54

Earlier quoted context omitted.

JavaScript is the perfect example of give hackers a bit and they'll take a damned terabyte.

JavaScript is like Buckley's cold medicine - It's awful, but it works.

Unrelated to this comment, based on your earlier comment - check this out:

http://www.classicshell.net/

This transforms the start menu on Windows into any version of it you like.

Re: Drawbacks of Python

#55
post #32

Earlier quoted context omitted.

I agree with a lot of these things, but actually disagree that Python is good at exemplifying some of them. For example, semantic whitespace is arguably implicit, hard to read, invites density (compared to an extra line for braces), and (again arguably) is ugly. Yes, some of these things are subjective, but it's hard for me to confidently recommend Python to someone with these values.

I can't even tell you how many hours I've lost due to someone committing an incorrectly indented line in python. This often happens during merge conflicts, for example. Because logic in python is interpreted via indentation, it's very difficult for python to realize when a line is indented incorrectly. It just assumes that if a line is indented a certain way, it was intentional. In programming languages like Ruby or…

> very difficult for python to realize when a line is indented incorrectly. It just assumes that if a line is indented a certain way, it was intentional.

How is this different from some language not realising that a statement should be inside of the curly brackets instead of outside?

Re: Drawbacks of Python

#56

Earlier quoted context omitted.

> Syntax and small API gotchas can be learned by a beginner programmer in a matter of days of using the language, and are fairly irrelevant to your overall experience. I agree with the first part but not the second. One can only write arraylist.add(arraylist.size() - 1, arraylist.get(arraylist.size() - 1) + 1) before wondering if there’s a better way to do this.

Even if your language doesn't support a better syntax, it probably supports functions, so you don't have to write this over and over again. Just pull out into `appendLastIncremented(ArrayList a)` and call that. You'll have forgotten the pain of writing that function within an hour. I'll never forget the pain of debugging a {bar: 1}.baz returning undefined (failing silently) and then going into a future inside a minif…

I don’t want to write a random free function for one line of code. I want nice syntax:

  list[-1] += 1
  array.last += 1
  *(vector.end() - 1)++;
Having reasonable syntax and a strong type system are not mutually exclusive.

Re: Drawbacks of Python

#57
post #55

Earlier quoted context omitted.

I can't even tell you how many hours I've lost due to someone committing an incorrectly indented line in python. This often happens during merge conflicts, for example. Because logic in python is interpreted via indentation, it's very difficult for python to realize when a line is indented incorrectly. It just assumes that if a line is indented a certain way, it was intentional. In programming languages like Ruby or…

> very difficult for python to realize when a line is indented incorrectly. It just assumes that if a line is indented a certain way, it was intentional. How is this different from some language not realising that a statement should be inside of the curly brackets instead of outside?

No compiler can read your mind. But in a language with brackets, the compiler can at least determine scope even when things are poorly-indented. In Python it can't in a lot of cases.

It's like static type checking: The class of errors the compiler can catch is larger when it's present. Likewise, with visible scoping characters, the class of errors the compiler can catch is larger than when they are invisible.

Re: Drawbacks of Python

#58

Earlier quoted context omitted.

Even if your language doesn't support a better syntax, it probably supports functions, so you don't have to write this over and over again. Just pull out into `appendLastIncremented(ArrayList a)` and call that. You'll have forgotten the pain of writing that function within an hour. I'll never forget the pain of debugging a {bar: 1}.baz returning undefined (failing silently) and then going into a future inside a minif…

I don’t want to write a random free function for one line of code. I want nice syntax: list[-1] += 1 array.last += 1 *(vector.end() - 1)++; Having reasonable syntax and a strong type system are not mutually exclusive.

> I don’t want to write a random free function for one line of code. I want nice syntax

shrug Sure, me too, everybody wants nice syntax.

What I'm saying is that syntax is never the most important problem with a language. People talk about problems with syntax because they're easy to understand, and the more important problems with a language are much harder to understand and talk about.

If a genie told me I could wish for three problems with Python to be instantly fixed, none of them would be syntax. I can't think of a language I've used where syntax would be on the list.

Re: Drawbacks of Python

#59
post #41

These are minor annoyances to me. The major annoyance I have with Python is that most Python code makes such heavy use of classes, even when it only needs lists, tuples, and dicts. Why do I really need a class, when: - Instance fields can be added and removed at runtime - Private fields and methods are not actually private ("we're all consenting adults here") - No pattern matching on types and `if isinstance(foo, Bar…

My solution to this is http://attrs.org or dataclasses. They make a huge difference in readability and type safety.

Re: Drawbacks of Python

#60
post #49

Earlier quoted context omitted.

I find any one block of code more enjoyable and succient to read in Python, but with very large implementations I can't figure out a good methodology to maintain it all. How do you deal with arbitrary objects being passed around and not know what's potentially coming from where? With something like C# without having to know the whole solution I can easily figure out what's coming into a function and manipulate that t…

> How do you deal with arbitrary objects being passed around and not know what's potentially coming from where? Honestly, by trusting that those objects conform to what things are documented to expect and using operations that will naturally raise an error for unexpected cases. Basically, you don't depend on compile-time or IDE-time checks, you depend more heavily on tests. It allows for much more of a direct approac…

Ah, OK, so you build the "checking" in via process and practice. It requires more discipline, but you end up evolving to kind of a similar place, but with more flexibility.

Thanks!

Post reply on HN