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

Problems I Have with Python

darkf.github.io

Post reply on HN
Print view View original

161–170 of 239 posts

Re: Problems I Have with Python

#161

Post by paulmd »

stcredzero wrote: post #142
jogjayr wrote: post #136

Serious question: is the whole deal with the Python GIL solvable if some BigCo decides to throw a ton of money and engineers at it? Like Google with V8, for instance. Or is it a truly hard problem that will take something special to solve?

For awhile, Python was one of the 4 approved languages at Google. The answer is "probably no." If it were easily solvable, Google would already have thrown money and engineers at it.

See my sibling comment to yours - but care to explain your thoughts more?

Jython already fixed the GIL problem. The problem is the legacy codebase built on assumptions of non-concurrency, which is just a matter of engineer time i.e. throwing money at it, plus getting GVR to sign off on it.

Re: Problems I Have with Python

#162

Post by ehsankia »

takeda wrote: post #150
darkf wrote: post #6

Earlier quoted context omitted.

>However, many are subjective preferences Certainly, it is titled "Problems I Have" for a reason. :-) I do not expect everyone to agree with me, but it is what I feel I personally lack when using it quite a lot. > I imagine this statement could offend some of the smart and hard-working people who are working on improving the python language. That was certainly not my intention -- as stated, I do love the language and…

>>- the solutions to a problem (I'm thinking GIL) come with a lot of consequences which are not readily acceptable > I did not propose a solution because there are many, as you note; there are, however, implementations with decent solutions like AFAIK Jython. >>- solving some of the issues would exacerbate backwards compatibility. > Such as what? Let's use the GIL for example. The reason that is still present is not…

That talk was a great overview of the issue.

Most people who are ignorant about the subject always assume the GIL is stupid and useless, but the GIL allows Python to be extremely fast in single threaded scenarios, and any attempt to remove it introduces at least 20% slow downs.

And C extension support is also a huge factor as you mention. All of Python's scientific modules would be lost if they broke that.

The author assumes these are simple problems that can be solved but aren't because of politics or incompetence, but some of the smartest mind have attempted and failed.

I'd like the author to try and come up to solutions or at least draft ideas for how each of his points can be fixed. A lot of those are easy to state but difficult to solve without breaking more stuff.

Re: Problems I Have with Python

#163

Post by ascotan »

>Parallelism is very bad on CPython and PyPy;

GIL was added because the early python libraries were not written to be threadsafe. This was a terrible oversight and frankly should have been corrected at some point. The underlying implementations use pthreads. It's actually worse, because as multi-core devices came out the "lock-thrashing" behavior of the GIL got worse. Rather than fixing the problem we have 'multiprocessing'. I still don't understand why this hasn't been tacked.

> Quite a few legacy projects are written in Python 2, and it can take some work to port them. This is particularly a pain for libraries where I expect to pip install them and have them "Just Work".

Python 3 was DOA. I don't want to be overly critical here, but there was no compelling reason to switch because python 3 didn't have anything fundamentally more interesting than python 2. It didn't really fix any of the serious language issues (like the GIL). It was almost like like the python version of windows vista or ipv6. People want you to switch, but meh.

>The BDFL himself, Guido van Rossum, has infamously declared that he does not like functional programming

And now you've come to the heart of the matter. There have been some amazing tweaks of python (stackless, pypy, twisted greenlets) some of which have been attempted to be merged into the greater python. Most of which were rejected. At some point people give up and walk away. For better or worse Python is Guido's language. Take it or leave it. No switch statement for you buddy.

I think Python is a fantastic language. It has become ubiquitous. For all it's warts, it's lack of change has probably helped it's adoption. Literally EVERYONE writes python code. Network guys, sysadmins, even your manager (or your manager's manager) probably has some python code stashed away somewhere.

However, I don't feel that Python is not doing enough to catch up. Print as a function does nothing for me. There are so many, many, many, many warts (which i won't get into) and yet python seems to be polishing the chrome rather than fundamentally fixing it's core problems.

I want to use and love python but it's become "the devil you know" so to speak. I've lost hope that python will adapt to the future and have put my bets elsewhere.

Re: Problems I Have with Python

#164

Post by ehsankia »

Pxtl wrote: post #121
jknoepfler wrote: post #112

I don't understand the desire to turn python into a high performance language. It's 2017, if you want performance just write some go/cpp/rust. If you want to leverage an old and very mature concurrency framework, use elixir/erlang. If you need a giant data integration framework, use java. If you want a stellar bash replacement, use python. Know your tools, don't bloat them with unnecessary crap. (The list was not int…

Because other high-performance languages have been improving their readability and expressiveness. Personally, my tool of choice is C# right now. I find it quite readable, and every bit as expressive as python - even moreso, plus it has the performance advantages of being designed from square 1 as a compiled language instead of an interpreted one. It has async/await, it has functional features that Guido hates, it ha…

But then, if you want to write a script to convert a bunch of files from one format to another, will you start a whole C# project?

If you want to quickly to a mathematical calculation with matrices, then plot and visualize it, will you use C#?

"Tool of choice" is misleading. Maybe you are a webdev. Maybe you write GUI applications for a living. I don't think there's clear "Tool of choice" for all jobs.

The job dictates the tool of choice.

Re: Problems I Have with Python

#165

Post by nomel »

acqq wrote: post #78
darkf wrote: post #17

Earlier quoted context omitted.

Cool, I think you completely dodged the point. I never said it was slow because they were incompetent.

> I never said it was slow because they were incompetent Your own article appears to have exactly that claim: > These are obvious flaws in design, in my opinion, that warrant re-looking at, but to which no real improvements are being made for some reason. ( Incompetence? Politics? Both? Who knows. ) > Without further ado: The standard interpreter bring rather slow; PyPy is nice, but its Python 3 support is very immat…

Oh don't be silly, he's applying multiple possible reasons to the set of frustrations. You're applying all of them to a single frustration. What you've done isn't logical.

Re: Problems I Have with Python

#166

Post by sabauma »

za_creature wrote: post #139
sabauma wrote: post #111

Earlier quoted context omitted.

The notion that not having proper tail calls aids debugging always seemed like a post-hoc justification. The stack trace of an iterative function will lack exactly the same intermediate evaluation frames as a tail-recursive implementation.

The thing is, tail calls aren't _just_ about emulating iteration via recursion: def foo(): raise ValueError def bar(): return foo() bar() With TCO, the stack trace would contain `main` and `foo`, as `bar`'s frame would be overwritten by `foo`. This example is simple, but `bar` could be a 50 line long if-else chain of tail calls and when debugging you won't necessarily know which condition was evaluated.

> The thing is, tail calls aren't _just_ about emulating iteration via recursion:

I completely agree, but there is also no need to perform TCO to make code like this safely runnable. TCO only becomes necessary/useful when implementing an iterative process where we can't statically know that the call stack won't be exhausted. That said, TCO is usually an all or nothing transformation, and it would be difficult to accurately avoid eliminating trivial tail calls like in your example.

A reasonable compromise might be for the Python VM to implement a TAIL_CALL bytecode op and require the programmer to decorate functions which rely on TCO. This wouldn't be any more onerous than manually trampolining large portions of code, which is the current method of getting around the lack of TCO.

Re: Problems I Have with Python

#167

Post by jgalt212 »

thomasvarney723 wrote: post #105

Though I likely haven't completely understood each of the authors gripes, each problem to me seems to have a notable solution provided by Clojure (with the exception of tail-call optimization). Clojure: is compiled to JVM byte-code and is fast. has a good parallelism story (parallel map, parallel fold, channels) is almost completely backwards compatible. has a sequence abstraction that leverages the same operations o…

All of the above is good except for transducers. They are a necessary hack in Clojure because the data is immutable running a large number of functions across changing data is rife with overhead in Clojure. So the hack is mutate the code many times, so you only have mutate the data once.

Re: Problems I Have with Python

#168

Post by jgalt212 »

nneonneo wrote: post #158
protomok wrote: post #128

One of the biggest Python issues I see is the inability to hide or protect Python source code. 'Compiling' into byte code is easily reversible using pip packages like uncompyle2. Various pip packages offer code obfuscation but from my tests cause problems when running the code. Encrypted bytecode seems to always be decryptable due to the very nature of having an interpreter. Moving Python code into modules implemente…

Naively compiled C/C++ is fairly easy to reverse engineer (I say this from a lot of experience!). If you want to "protect your source code" you need to apply obfuscation techniques to slow down a reverse engineer - but keep in mind that everything ultimately can be reversed and understood given enough time. Plus, many obfuscation techniques can be made applicable to Python code too (e.g. encrypting, obfuscating or ma…

> Naively compiled C/C++ is fairly easy to reverse engineer (I say this from a lot of experience!).

So I assume your position on reverse engineering Python bytecode is that it's trivial.

Post reply on HN