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

301–310 of 554 posts

Re: Reasons Python Sucks

#301

Post by pbalau »

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…

Isn't pep440 actually dealing with versioning? In my mind, if there is a pep, then is the language.

Re: Reasons Python Sucks

#302

Post by mixmastamyk »

qntty wrote: post #59
colanderman wrote: post #35

A better reason to hate Python: the internal model is way overcomplicated for what it's meant to be: a beginner-friendly scripting language. "Everything-is-an-object", duck typing, decorators, bizarre scoping rules, etc., all make it difficult for experienced programmers to understand, let along beginners. I've always thought there's a much simpler language struggling to get out of Python, and I wish it would and wou…

Is python really meant to be a beginner-friendly language? I tend to think of it as lisp-without-parens, and lisp is not very beginner friendly.

Simple things are easy, complicated things are possible, though may be awkward. Better situation than many/most languages.

Re: Reasons Python Sucks

#303

Post by pstch »

pdonis wrote: post #111
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…

With regard to "pass by reference", it's not even clear to me that that's a correct way to describe how Python passes variables to functions. Python variables aren't names for storage locations to begin with; they're namespace bindings. Passing a variable to a function means passing a particular namespace binding from the caller's namespace to the function's local namespace. I don't think the author of this article u…

> Passing a variable to a function means passing a particular namespace binding from the caller's namespace to the function's local namespace.

I don't think that's true, as the function will never be able to change the binding, and only gets a reference to the value of the binding. If the function was passed a particular namespace binding, it would be able to change this binding's value, and that's not possible.

I agree that "pass by reference" is a misleading way to describe Python functions.

Re: Reasons Python Sucks

#304

Post by brudgers »

civility wrote: post #252
brudgers wrote: post #224

Earlier quoted context omitted.

In no particular order + Java doesn't promise "everything is an object." It has Base Types. + Python doesn't make a semantic promise that "everything is an object." Code for (3).fizzbuzz => "fizz" probably needs written in C because built-in types are closed and object literals use the built-in types. "3" cannot be forced to use a subclass of Integer. At the bottom, '3' is defined in terms of Types (i.e. "Built-in Ty…

I'm not sure if you think you're correcting me, but it sounds like you think you've got it all figured out. Java calls them "primitive types", btw.

I was clarifying the difference between "everything is an object" as technically true and "everything is an object" as a commitment to semantic consistency. Probably because I'm still figuring out these ideas.

Re: Reasons Python Sucks

#305

Post by mdemare »

mherrmann wrote: post #92

> My code for Python 3.5 won't work with the Python 3.7 installation unless I intentionally port it to 3.7. This statement is plain wrong at best and intentionally misleading at worst. 99.99% of Python 3.5 code runs unmodified on 3.7. > At the official Python web site, their documentation is actively maintained and available for Python 2.7, 3.5, 3.6, and 3.7 -- because they can't decide to give up on the old code. No…

Tensorflow doesn’t run on 3.7, only 3.6 (and 2.7). That’s a pretty major library.

Re: Reasons Python Sucks

#306

Post by empthought »

sebastos wrote: post #248
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…

3: Yes. Mandatory indenting is a godsend to readability. Author is wrong. 4: Yes. Imports >> Includes in every conceivable way. However, what is actually available to import _is_ confusing. This is really a symptom of a different problem though... 5: Yes 6: Yes - picking on the quotes thing with Bash is just one of a million syntax "quirks" that make Bash a horrible no good language. ( as an operator is my vote for m…

Application distribution is actually the easy use case; just use PyInstaller: https://www.pyinstaller.org

It's often tricky to specify abstract dependencies such that people can use pip to install libraries without having trouble with other packages in their environments, and also quite tricky to provide builds with native code or links to native libraries for different architectures.

Re: Reasons Python Sucks

#307

Post by bakery2k »

earenndil wrote: post #275
closed wrote: post #116

Earlier quoted context omitted.

> I regularly wish python required some sort type indication for function parameters You can use type annotations, either via the builtin lib or 3rd party libs! https://docs.python.org/3/library/typing.html > do_x() if a.y() I feel this. You can use `a.y() and do_x()`, but I'm not sure how people would react :o

Type annotations don't seem to actually have any effect, though? Consider: >>> def add(a: int, b: int): ... return a+b ... >>> add("a", "b") 'ab' This should be an error, even if it's a runtime error.

There doesn't seem to be any interest in checking type annotations at run-time. Unfortunately, without doing so, type annotations look authoritative but are essentially just comments.

I believe Julia is an example of a dynamically-typed language which does perform such checks at run-time - including as part of its support for multiple dispatch.

Re: Reasons Python Sucks

#308

Post by viraptor »

fhood wrote: post #155
bakery2k wrote: post #132

Earlier quoted context omitted.

> `a.y() and do_x()` If you're happy to write it that way round, why not just use `if a.y(): do_x()`?

Against pep-8 standards. I do end up using that sytax quite a bit anyway though.

> PEP8: This document gives coding conventions for the Python code comprising the standard library in the main Python distribution.

It's fine not to follow PEP8 for your own software. It's a useful guide, not a law.

Re: Reasons Python Sucks

#309

Post by golergka »

> In contrast, many Python modules include initialization functions that run during the import.

I just thought it's a natural consequence of a dynamic languge. Defining a class IS running code - you can even decide to define or not to define something based on a runtime random roll.

Re: Reasons Python Sucks

#310

Post by triMichael »

srfilipek wrote: post #274
com2kid wrote: post #164

Earlier quoted context omitted.

#7 is so very wrong in so many ways. Even languages that are pure "pass by value" cheat pass the value of a reference for objects. Very few languages support doing a deep copy when passing an object. I'm trying to think of a single one, and I know that none of the major ones do. C will pass an entire struct, and so long as the struct doesn't have any pointers, sure... But even in C passing a struct by value is highly…

That one dumbfounded me as well. Has the author never given a pointer as an argument to a function before? Do they make copies of their strings and structs every time they want to pass it around? I just... I just don't understand how they could think that.

I think I can answer this one because it is one of my gripes of Python. The problem isn't that it doesn't copy, rather it is that the = assignment operator specifically doesn't copy.

If you create a list "list1", set "list2 = list1", and change list1, both of the lists change. When I learned Python, this was a major source of confusion for me. Eventually I learned that in Python, instead of nothing being a pointer as it first appears, it is actually that everything is a pointer. On the other hand, while the same things occur in C++, the assignment operator does a shallow copy and anytime you are doing a pointer copy it is explicit.

Post reply on HN