Live data from Hacker News

Reasons Python Sucks

hackerfactor.com

191–200 of 554 posts

Re: Reasons Python Sucks

#191

> 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…

afaik the only thing on python 3.7 that is backwards incompatible to 3.5 is: > async and await are now reserved keywords. so unless the author is using async/await as variable names (and i wonder why they would), 3.5 code is going to run as expected.

> and i wonder why they would It's easy, actually:

    import asyncio

    @asyncio.async  # SyntaxError in 3.7
    def my_coroutine(...): ...
And since asyncio is one of the strongest reason to migrate to python 3.x, I bet far less than 99.99% of code written for 3.4/3.5 can be run on 3.7 with no changes.

Luckly, 99% of changes were trivial. Other 1% is a nightmare.

Re: Reasons Python Sucks

#192

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…

> 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…

Do you mean using spaces or using the space bar? 4 spaces is standard but the editor should take care of that with tab that results in 4 spaces. An actual tab is just plain wrong. It is allowed of course, but those developers are wrong for doing so.

Re: Reasons Python Sucks

#193

> 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…

I figured that was a typo for 2.7. But even then there are relatively few areas that need some touchup from 2.7 -> 3.5, and most of those are mechanical changes like having parens around print statements.

Re: Reasons Python Sucks

#194

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 (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.

Re: Reasons Python Sucks

#195

> 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…

afaik the only thing on python 3.7 that is backwards incompatible to 3.5 is: > async and await are now reserved keywords. so unless the author is using async/await as variable names (and i wonder why they would), 3.5 code is going to run as expected.

I wouldn't be surprised, I've seen a developer use type as a function name and it was imported everywhere...it caused a lot of problems. Not to mention the function literally did nothing, it essentially returned none under 99 percent of circumstances. If the person that wrote that was still at the company, that should have been a fire able offense.

Re: Reasons Python Sucks

#196

Earlier quoted context omitted.

> Python variables aren't names for storage locations to begin with; they're namespace bindings. Can you explain the difference? What is a "namespace binding"? When accessing a variable's value, the interpreter's code sure looks like it treats the variable name as the name of a storage location. > Passing a variable to a function means passing a particular namespace binding "Passing a variable to a function" is not a…

Every value in Python is a reference to an object. All function parameters are such values that are passed as they are. You get the same references to objects that the caller passed. We could call this "passing references to objects by value."

Over the years, I have found this article to be useful: http://effbot.org/zone/call-by-object.htm

Re: Reasons Python Sucks

#197

> 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…

afaik the only thing on python 3.7 that is backwards incompatible to 3.5 is: > async and await are now reserved keywords. so unless the author is using async/await as variable names (and i wonder why they would), 3.5 code is going to run as expected.

The ‘deprecated’ warning on invalid escape strings turned into a hard error, also.

Re: Reasons Python Sucks

#198
post #103
post #93

Earlier quoted context omitted.

Does no one have auto indentation in their editors? Every so often I just select the block of code I'm editing and auto indent it, which matches indentation with semantics without me having to think about it. Annoyingly impossible to do this with python since indentation is semantics. It also results in copy pasting of code being 100 times harder in python than other languages.

That doesn't help with the problem you're replying to – in fact it would contribute to it. More generally, yes, many people use auto-indenting and it works in Python in most editors. It's possible that you're using one where it doesn't work correctly but that doesn't mean that's true for everyone else.

It does help with the problem I replied to, which was code written in C. Auto indenting that code block would indent the `someotherstatement;` line correctly and I would notice that mistake. Anyway, single line if statement is a flaw in C's design.

What I said was that in Python's case, if I indent some code block wrong, I can't just fix the indentation using auto indenting in python, because the indentation is the semantics. There would be "nothing" to fix and the code would just run wrong. This problem comes up always when I copy paste python code. Of course I should notice that it's indented wrongly but that doesn't always happen. (And please don't advise me to never copy paste code. Life doesn't work that way.)

Re: Reasons Python Sucks

#199

Earlier quoted context omitted.

7 Isn't Python actually pass-by-value / pass-pointer-to-object-by-value like Java is? Many confuse pass-pointer-to-object-by-value with pass-by-reference, but they are different things. Pass-by-reference allows to write a procedure that swaps two external values.

You're right that you can't perform swaps with a Python function, but it's never pass-by-value like Java primitive types. It feels like pass-by-value because int, long, float, complex, and string are basically immutable.

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.

Re: Reasons Python Sucks

#200
post #59

Earlier quoted context omitted.

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.

It is usually the "first language" of choice these days, when teaching programming.

This has more to do with who has what teaching resources pre-made to sell than something any thought about the merits of a programming language.
Post reply on HN