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

311–320 of 554 posts

Re: Reasons Python Sucks

#311

Post by com2kid »

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.

> Has the author never given a pointer as an argument to a function before?

Possibly not, many devs now-days have never used a real native language.

Re: Reasons Python Sucks

#312

Post by mixmastamyk »

mdemare wrote: post #305
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.

Probably a C extension that needs to be compiled against a new version. Unlikely it is an actual compatibility break.

Re: Reasons Python Sucks

#313

Post by xtracto »

cleandreams wrote: post #243

I'm a python hater. Yes it is easy, but in exactly the wrong way. Easy for simple code for middle schoolers. For grownups with large codebases to develop and maintain, it's not optimal. Of course I hate the whitespace trickery. I hate the auto formatting that sometimes doesn't work. Those are fairly minor. What I really, really hate is the lack of static typechecking. You often have to read lengthy swathes of code to…

I used to program in Python, and found Ruby as a language to give me everything Python provides but with a more Programmer friendly syntax.

I never understood why you would use a function like len() in an Object Oriented Language (instead of x.len ) or having to explicitly add self to every method...

Re: Reasons Python Sucks

#314

Post by xtracto »

silon42 wrote: post #86
superasn wrote: post #19

I too have tried it many times mainly because of all the great ML libs for python but each time I dreaded using it for Reason #3 (Syntax). Using indents for blocks just seemed unintuitive and error prone to me. But I dismissed it because all the programming languages I've worked with have had curly braces so maybe the reason for my discomfort was that it was unfamiliar.

You could use 'pass' to denote end of block... Someone just needs to write a validator.

At some point in my Uni I thought of writing a "curly braces to python" translator that will take code in "pseudo python" which allowed curly braces and would convert/indent it the correct way.

Re: Reasons Python Sucks

#316

Post by mixmastamyk »

chasedehan wrote: post #201
fernandotakai wrote: post #104

Earlier quoted context omitted.

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.

There is also formatted string literals from 3.5 to 3.6. 3.5 won't run if you included them in your 3.6 code

That's forward compatibility which few folks require. Backwards, yes most do.

Re: Reasons Python Sucks

#317

Post by jcranberry »

I don't often use python nor do I know it well but it's obvious to me that several of these points are stupid, misinformed or wrong. Numbers 3, 5 and 8 are just nonsense whining. Number 7 is terribly wrong.

I find it incredibly surprising that this person got a Computer Science PhD while confusing Python lists with arrays and not knowing that pass by reference semantics is by no means niche.

Re: Reasons Python Sucks

#318

Post by breatheoften »

Symmetry wrote: post #50

I agree with a number of these but I really don't understand #4. If you want to know what's in a module then 'import foo; help(foo)' in your interpreter will give you it. In C you can't just grep /usr/include because you might be importing form somewhere else. And in C everything goes directly into your main namespace, the equivalent of 'form foo import *'. And even with single letter renames you can just quickly che…

There's so much incidental design exposed to the user/library author because of python's import system ... Ultimately you have to step through a large list of questions in order to understand the actual import behavior -- its not easy and adds a large (pointless?) cognitive load for every library user/author ...

Are you import'ing a Module or a Package? If it is a package then maybe there's a magic file called __init__.py in a directory that might have an __all__ = [...] array or might just import some other modules but not contain an __all__ or it might import some names from some other modules. Or maybe there's a namespace package somewhere which has some behavior when there are directories that contain .py files but don't have an __init__.py (I honestly don't know the rules -- but I do know they can't be explained to me in a small number of words and that makes me insane!) ... And by the way -- every instance of 'import' used throughout your program is additionally beholden in its behavior to a global runtime magic state magic called the PYTHONPATH (that often has to get munged from the shell environment prior to invoking a python program ...) which is a list of path's that will be consulted/augmented differently depending on whether its a (module/package/namespace) import search to ultimately decide which set of files will be inspected ...

As a half-assed python developer (who is firmly in the 'I hate python camp') I honestly have very little idea how you are 'supposed' to use these mechanism when defining a package. I recently tried to figure out actual best practices so I could publish a small package -- I relied on lots of boilerplate copying from what seemed like knowledgable sources. I think I got something vaguely workable (https://github.com/breathe/NotebookScripter) but there's a lot of line noise all throughout the filesystem layout ... What is it about my Project name that python demands I should repeat it in the filesystem over and over and over again?

I believe this is actually the common pattern for laying out a small library ...:

Project/setup.py Project/Project/__init__.py Project/Project/SomethingToDoWithProject.py

Re: Reasons Python Sucks

#320

Post by icedchai »

honkycat wrote: post #85

I will stick up for this person. I agree with all of the points listed here. But especially: Python version management and installation sucks. A while ago I had a broken python ship with my Ubuntu desktop. Pip decided they were going to deprecate behaviour, and nobody updated or tested on Ubuntu. Also it is slow and ugly. Just write it in Golang or something.

Version management is pretty easy to solve: Just use virtualenv and you won't have a problem. If you start messing around with system level python package installs, you'll likely make a mess.

As for ugly, I disagree and find Python some of the easiest code to read. "Slow" depends on the application. For 90% of the apps out there, you're waiting on something else (network IO, DB, etc.) and it's fine.

Post reply on HN