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

Reasons Python Sucks

hackerfactor.com

Post reply on HN
Print view View original

261–270 of 554 posts

Re: Reasons Python Sucks

#261

Post by pfranz »

sam0x17 wrote: post #211
notacoward wrote: post #70

Most of the points in this article fall on a continuum between irrelevant to dead wrong. 1 (versions) and 2 (installation) have to do with the ecosystem, not the language. Unsigned packages are a real problem, but hating on community-maintained software is just weird. Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time. 3 (synt…

> 1 (versions) and 2 (installation) have to do with the ecosystem, not the language. Unsigned packages are a real problem, but hating on community-maintained software is just weird. Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time. Regarding 1: I'm sick of people saying that the ecosystem != the language. No one is going to…

I think the frustration with that argument is, who is it directed at? How would you fix it?

venv has been included with Python since 3.3 (2012) and was a separate package before that. If you're having troubles with the ecosystem playing well with Python 2.6 (2008) what do you expect anyone to do? I really think OS package managers have been really negligent about multiple versions and project-level dependencies--maybe it's outside of their scope (that also wouldn't help you on Windows)? People have been griping about software specific package managers for over a decade and OS package managers have only added the most minimal support, but never addressed the reason for them.

I've argued for years, if something is critical to your business then decouple it from the OS. Of course a new version might screw up your OS and you may need it to address a specific business concern...that's just one of the problems of any interpreted language. I wish things were better out of the box, but it's not unreasonable to address yourself.

Re: Reasons Python Sucks

#262

Post by civility »

szatkus wrote: post #255
civility wrote: post #241

Earlier quoted context omitted.

Java primitives (short, float, double, etc...) are copied to the calling function, but arrays and objects are passed by reference. This is easier to explain in a language like C++, which can do either: // Java always does these: void f(Object& o) { ... } // passes objects by reference void g(double x) { ... } // primitives are copied // Java can not do these: void p(Object o) { ... } // copy of the object void q(doub…

My C++ is a bit rusty, but AFAIR `void f(Object& o) { ... }` would allow you to replace the whole object in passed variable (`o = o2`). You can't do this in Java, you can only modify its fields. It's more like `void f(Object* o) { ... }`

You're right, it is more like a pointer. In C++, that would call the assignment operator which can do anything it wants, but the address of the Object would not be replaced. Java would change the value of the pointer in the callee.

These cross-language comparisons have too many nuances for me to try and make simple examples. Really, my original point is that CPython does not have "primitive types" as in Java. Everything is passed by pointer to the PyObject.

Re: Reasons Python Sucks

#263

Post by [deleted] »

compiler-guy wrote: post #239
drewrv wrote: post #227

Earlier quoted context omitted.

These kind of problems can be solved or avoided altogether by a decent editor.

I don't see how. An editor can help you get indentations that are syntactically valid, but can't possibly know if the programmer intends the program below to print plain "foo" or both "foo" and "bar". print("foo") # x is false for the problem if x: do_something() print("bar") And to the parent who has written a lot of code but never had this problem, well, some people do.

[deleted]

Re: Reasons Python Sucks

#264

Post by baddox »

civility wrote: post #241
szatkus wrote: post #199

Earlier quoted context omitted.

I may be missing something, but I can't find any example in my mind which indicates difference between passing in Java and Python. And it's pass-by-value for all types, because for objects an address is the value.

Java primitives (short, float, double, etc...) are copied to the calling function, but arrays and objects are passed by reference. This is easier to explain in a language like C++, which can do either: // Java always does these: void f(Object& o) { ... } // passes objects by reference void g(double x) { ... } // primitives are copied // Java can not do these: void p(Object o) { ... } // copy of the object void q(doub…

> Java primitives (short, float, double, etc...) are copied to the calling function, but arrays and objects are passed by reference.

Not really. "Pass by reference" is a specific term for a much different technique which is very rarely encountered these days. It means that if you pass a variable "foo" to a function, that function can assign "foo" to some other value and the value of "foo" will also be changed outside of that function.

The confusion, I think, is that true pass by reference is almost never encountered in modern programming languages and courses, and some people mistakenly use the term "pass by reference" when explaining the difference between e.g. primitive types and objects in Java.

Java passes everything by value. The value of a variable assigned to an object is indeed a "reference" to that object in memory, but that's a coincidental use of the term "reference."

Re: Reasons Python Sucks

#265

Post by pfranz »

riskable wrote: post #210
jaxtellerSoA wrote: post #194

Earlier quoted context omitted.

>3 (syntax) seems to be about not supporting the author's own highly idiosyncratic habits Yeah, I don't get the author at all. Using indentation is so, so, so, so, much cleaner and easier to understand, even with lots of nesting than trying to figure out if you closed all the stupid curly braces, curly braces be damned.

I asked a "C all the things!" developer a while back why he hated Python's enforced indentation and in a whole lot of words he basically said that it makes it difficult to visually track scope when you have long chains of conditionals. The standard Python developer response to that is, "Aha! You like braces because they enable your bad programming practices !" However, I found the best way to illustrate that point is…

Isn't deep nesting (hence deep indentation) a sign of code smell? Yeah, you might end up shuffling the logic into a new file or a function that makes the file much longer, but I've noticed when doing that kind of refactoring it forces you to clean up the scoping quite a bit so there's less state to keep track of.

Re: Reasons Python Sucks

#266

Post by [deleted] »

Too wrote: post #232
nicolashahn wrote: post #166

Earlier quoted context omitted.

I think it makes more sense in a language where you have to write callbacks all the time. I consider it a feature in Python, because by using `def` you're forced to imbue the function with meaning by providing it a name. Otherwise, it's just reading through a potentially complicated function without any context of what it's supposed to be doing.

All languages, including python, where you do a lot of asynchronous io require callbacks all the time. It's only recently python got await-support to deal with this. Single line lambdas is a real PITA when your not using asyncio and python maintainers have said they don't plan to change it :(

[deleted]

Re: Reasons Python Sucks

#267

Post by kakwa_ »

notacoward wrote: post #70

Most of the points in this article fall on a continuum between irrelevant to dead wrong. 1 (versions) and 2 (installation) have to do with the ecosystem, not the language. Unsigned packages are a real problem, but hating on community-maintained software is just weird. Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time. 3 (synt…

> Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time.

There is one big difference between Pypi and a distribution repository:

With Pypi, every contributors are truly individuals, they upload their packages alone, they maintain them alone, they basically do whatever they want. The maintainer here can likely be a single point of failure.

With distribution even if most packages are maintained by a single person, the repository content is the responsibility of the distribution as a whole. These distributions have formalized their processes and policies a long time ago. For example, if a critical security issue is found, unless something goes wrong, the package will not be left unpatched, even if the package maintainer is not reacting.

Also, Distributions put huge efforts into providing stable versions, if you are using packages from a distribution, you have some guaranties about stable APIs, and that these packages with stable APIs will actually be maintained for a few years. Even if it's not always perfect, with non-critical bugs not always fixed, it's a far cry from Pypi where the only true possibility is to hard pin every single version of your dependency tree inside requirements.txt.

Re: Reasons Python Sucks

#268

Post by mixmastamyk »

compiler-guy wrote: post #179
Hello71 wrote: post #101

Earlier quoted context omitted.

> And I pity anyone who miscounts spaces and accidentally puts in three spaces instead of four somewhere -- this can take hours to debug and track down. this is so hilariously wrong that it is clear that the author has never actually tried any of the things he complains about. Python 3.7.1 (default, Oct 22 2018, 10:41:28) [GCC 8.2.1 20180831] on linux Type "help", "copyright", "credits" or "license" for more informat…

I think the problem he is describing--somewhat poorly--is when the "third space" just happens to match some other scope above, and therefore is syntactically valid, but not nested the way one initially thought. Those kinds of problems can be hard to track down.

A third space can never align with another line since it will be an odd number of characters while indents are always even (or vice versa). If you are two chars off, well at some point you need to be responsible for your broken blocks.

I agree with the other person that says this doesn't really happen in the real world with a baseline developer and editor.

Re: Reasons Python Sucks

#269

Post by MR4D »

NoGravitas wrote: post #258
sam0x17 wrote: post #220

Earlier quoted context omitted.

This begs the question though why can't the python ecosystem simply evolve? Is that too much to ask? You say these languages have learned so much from Python. If there is so much to learn in terms of do's and dont's, why doesn't Python simply follow this advice?

To a significant extent, it has. The article assumes you will use distro packages for the language, and pip for installing libraries. And that used to be standard practice. Today, if you are interested in a reproducible build environment, you will use pyenv to locally install an interpreter and stdlib, and pipenv to locally (to your project) install libraries and dependencies.

In my mind, creating a Python 4 that would be a consolidation of all of these things under one release umbrella (or at least a major release), so that things could be synchronized would be a good way to handle this. Right now, things are all over the place, and things that used to work 5 years ago still kindof work, rather than either working or failing. And it's that "partial working" that really gets developers ticked off.

Rust is doing some interesting things with Rust 2018 Edition, where there is a complete system harmonization point. If it takes off there, I'd expect other languages to pick it up.

My question though is a bit different: Can Python catch up?

I know - strange question, but momentum is like that. It's often hard to see something going faster than you until it passes you. Perl is probably the best example, where it was way out front, and the PHP, which was way behind, but going mach 10, passed it quickly in the web space. Perl never caught up, and has lost significant relevance compared to the stature it used to command.

Re: Reasons Python Sucks

#270

Post by pfranz »

acdha wrote: post #181
colanderman wrote: post #113

Earlier quoted context omitted.

OK, fair point. I misremembered the list interface. `set` is a better example: `set.union`, for example, returns a new set, while `set.add` updates in place. (To be fair, this is with Python 2.7, maybe Python 3+ is more uniform?)

What would you expect it to do differently in those cases? That seems like the API is following how most people would think about those operations as you'd expect in a language which isn't trying to be immutable.

I thought it was interesting that Ruby, by convention, used an exclamation mark to convey that a function would mutate. I haven't used Ruby all that much to see how well that works at scale.
Post reply on HN