You are right! Any language has its disadvantages. Btw, I'm very interested in which programing language you're using mainly? Would you like to share with us? Thanks in advance ^_^
Reasons Python Sucks
511–520 of 554 posts
Re: Reasons Python Sucks
#512if you could only chose one language for server side "web apps", would you choose python or javascript?
Re: Reasons Python Sucks
#513Earlier quoted context omitted.
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.
Many libraries don't use it. Another convention uses it for methods that might raise an exception.
Re: Reasons Python Sucks
#514Most 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…
It's funny how far off the author was, because there are genuine things to complain about with python, though they may not be exclusive to python. I regularly wish python required some sort type indication for function parameters, because dealing with libraries that take complex objects as function parameters can be an absolute nightmare. I wish python had some equivalent to the switch statement that didn't involve w…
> and safe.
Oh no! You were so close!
Re: Reasons Python Sucks
#515Most 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…
Yea I was pretty surprised; Python really does suck, but I don't think I found a single one of the reasons listed in the article compelling.
Re: Reasons Python Sucks
#516Earlier quoted context omitted.
Came to a similar conclusion. I use Python a lot, and it certainly has its problems. However, the article's analysis doesn't even begin to scratch the surface of this topic in an informed manner. Instead, we're presented with paragraphs written by someone who can't read a stack trace: In [7]: def foo(): ...: print('foo') ...: print('bar') File " ", line 3 print('bar') ^ IndentationError: unexpected indent
Isn't that a strawman? Wouldn't a more apt example be: def foo(): nums = [...] sum = 0 for x in nums: print(x) sum += x I don't know python well, but it seems like there could be subtle issues with indentation that wouldn't cause a compiler error, but would cause the wrong output.
Consider C, where {} are optional for single-statement bodies:
void foo() {
...
for( ... )
printf(..)
sum += x
}
Re: Reasons Python Sucks
#517Earlier quoted context omitted.
> the function's arguments when it is called are a set of values for variables taken from the caller's namespace Again, this is very obviously false, since a call need not involve any variables at all: foo(1, 2, "three") The function's arguments when it is called are a set of values taken from the caller, yes. And those values are obtained from evaluating expressions that may involve variables. But they might not. Sa…
> this is very obviously false, since a call need not involve any variables at all True, in which case the values would just be constants. But they will still get bound to names in the function's local namespace. > You are mistaken No, I left out a case which, it seemed to me, did not affect the main point I was making. If you want to make clear that that's a possible case, fine, you've done so. But you haven't refut…
> But you haven't refuted (or even engaged with) my main point at all.
OK. Your main point (now that you have shifted the goalposts) seems to be that argument passing induces a binding of the parameter name to the argument value, yes?
In the abstract, this point is meaningless since it applies equally to every other programming language. In this C function:
void foo(int x, float y, char *z) { ... }
In the concrete, the point is also meaningless since those bindings do not involve dictionaries as you seem to think. For positional functional arguments, loooong before the call takes place, the bytecode compiler resolves names to stack indices, and the variables are accessed through those. Just like C can access arguments passed on the stack using constant offsets from the stack pointer.
Here is the code for the normal call fast path: https://github.com/python/cpython/blob/62be74290aca26d16f3f5...
f = _PyFrame_New_NoTrack(tstate, co, globals, NULL);
if (f == NULL) {
return NULL;
}
fastlocals = f->f_localsplus;
for (i = 0; i Access to these arguments inside the callee is via the LOAD_FAST bytecode instruction: https://github.com/python/cpython/blob/master/Python/ceval.c...
case TARGET(LOAD_FAST): {
PyObject *value = GETLOCAL(oparg);
...
#define GETLOCAL(i) (fastlocals[i])
I'm done with this thread now.
Re: Reasons Python Sucks
#518Earlier quoted context omitted.
I hate meaningfull identation because the tools I end up using suck at maintaining it. I end up bugfixing on customer systems, sometimes on systems used by coworkers. There is no editor with consitent tab vs. spaces or tab width settings. I had editors clear two indents at once, fail to correctly line up new indents more often than not. I will accept whitespace as sane block scoping method the moment every text edito…
>There is no editor with consitent tab vs. spaces or tab width settings. This is just plain false. PyCharm does, and I am sure there are others.
While I have PyCharm on my dev. system the chance that I can use it while I am debugging or extending a script on a customers system is zero, sometimes there is kwrite, sometimes it is gedit and if it is headless I may get vim. So consistency is guaranteed to be non existent.
Re: Reasons Python Sucks
#519Earlier quoted context omitted.
> This was not by accident - Guido and others have always had the utmost care for good developer experience out of the box. How many languages pack an editor ready to go? Or a way to install modules with a single command? Not even Java, with all its commercial might, ever achieved that - it barely got a REPL last year, which Python has had for what, 20 years now? The Java module experience is miles ahead of the Pytho…
> and that's it, you're done You are seriously comparing Maven, a huge and over-complicated xml-based system that is not even installed by default and that people hate so much that there are umpteen alternatives (gradle etc), with `pip install -r requirements.txt` that works out of the box? I just can't even... > Python still doesn't have anything [like Maven] And I thank the Gods for that.
> a huge and over-complicated xml-based system
It's not complicated. It's verbose, that's the nature of XML, but the behaviour is very direct.
> is not even installed by default
Which is the better approach because it means it's not coupled to specific versions of the language itself. You can use a single maven install to manage multiple versions of Java (or vice versa); if you need to rely on a new maven feature in a project that's stuck on an old version of Java, it's no problem.
> people hate so much that there are umpteen alternatives (gradle etc)
There will always be refuseniks (particularly for pioneers; most of the things people hated maven for are the same things people love cargo et al for) but the Java ecosystem has done a very good job of keeping everything interoperable; it doesn't matter if one of the libraries I call builds with gradle, because there's a common packaging/dependency/repository standard, so everything will just work exactly as it should.
> with `pip install -r requirements.txt` that works out of the box?
Until you come to upgrade, or until you run it the wrong way (e.g. forgetting to start your virtualenv first) and mess up your system install.
Re: Reasons Python Sucks
#520Earlier quoted context omitted.
> This was not by accident - Guido and others have always had the utmost care for good developer experience out of the box. How many languages pack an editor ready to go? Or a way to install modules with a single command? Not even Java, with all its commercial might, ever achieved that - it barely got a REPL last year, which Python has had for what, 20 years now? The Java module experience is miles ahead of the Pytho…
> transient dependency resolution is deterministic, so you don't have to worry about pinning/unpinning or anything like that Is that true? I see a lot of pom.xml files specifying version ranges for dependencies. If I have a project specify a dependency that has its own dependencies with version ranges specified, then there doesn't seem to be an easy way for me to pin all the subdependency versions. (Yarn and npm both…
> I see a lot of pom.xml files specifying version ranges for dependencies. If I have a project specify a dependency that has its own dependencies with version ranges specified, then there doesn't seem to be an easy way for me to pin all the subdependency versions.
Version ranges are indeed nondeterministic, that's why they're discouraged by the community (and IME very rare).
Pinning specific ones is easy enough (I tend to just look at the dependency tree in eclipse and right click -> lock transitive dependency version); I can't find a way to do that for all transitive dependencies though (I've never had more than a handful of transitive dependencies that used ranges, so it's not been a problem I've had tbh).