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

141–150 of 239 posts

Re: Problems I Have with Python

#141

Post by stcredzero »

xapata wrote: post #76
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.

Python has made some trade-offs that you dislike. You complain about the negative consequences without comparing those against the benefits. One of the major factors in speed is efficient memory layout. Contrast a Python list with a NumPy array. To achieve speedier loops and vectorized arithmetic [0], the array gives up dynamic typing and dynamic sizing. In most applications, I would gladly give up some compute speed…

One of the major factors in speed is efficient memory layout.

In most applications, I would gladly give up some compute speed to gain some programming productivity.

By Smalltalk standards, Python is pretty profligate. (By 90's C programmer standards, Smalltalk is pretty profligate.) However, Smalltalk still has many of the high productivity features as Python. (In fact, the debugging story is far superior.) I suspect, though, that Python is still a far superior environment for the things you use it for.

Re: Problems I Have with Python

#142

Post by stcredzero »

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.

Re: Problems I Have with Python

#143

Post by Pxtl »

dagenleg wrote: post #130
Pxtl wrote: post #121

Earlier quoted context omitted.

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…

It's nice that you like C#, but I don't see how that's related to the parent comment. You certainly cannot argue that C# does a better job at all mentioned tasks than the languages the parent listed.

I was using C# as an example of a language that now, as it has developed more features, lets you have your cake and eat it too. Many such languages exist.

Python seems overspecialized and stagnant to me. It prioritizes readability and simplicity, but that often results in weird workarounds that are even less legible and simple than a more expressive language would have.

Re: Problems I Have with Python

#144

Post by stcredzero »

sametmax wrote: post #52

> The standard interpreter bring rather slow; I'm tired about this one. In the last 13 years, 97% if the projects I worked on didn't need Python to be any faster, it was not the bottleneck. The remaining ones could leverage some solution to bypass the problem. Python speed is indeed an issue to a few people, but it's not the red flag I can read about here and there. I've been hearing this argument for ever. PHP is sl…

Python is an interpretted and very dynamic language. It's tough to speed up.

It was designed in a way that makes it particularly hard to speed up. It shares some of these flaws with Ruby.

Re: Problems I Have with Python

#145

Post by kazinator »

amyjess wrote: post #80
darkf wrote: post #21

Earlier quoted context omitted.

>lambda is fine, if you're writing in functional style you're using expressions for everything anyway. No, I /really would/ like to be able to write: foo.on_click(lambda: x += 1) The language not supporting this (when most others do) is just silly.

> foo.on_click(lambda: x += 1) Mutation in lambdas is not compatible with your complaint about "inadequate support for high-level functional programming", as it goes against the principles of FP. You can't do that in Haskell either, and any FP purist would blanch at a statement like that.

Are you saying that a non-mutating variant of the above works? For instance:

   foo.on_click(lambda:x func(x, whatever))

Re: Problems I Have with Python

#146

Post by paulmd »

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?

Sure. There's already variants like Jython that have removed the GIL.

The larger problem is the existing codebase, which is based around the assumption of non-concurrency. You also have a lot of libraries that use C extensions for performance, and a lot of those are going to break horribly if you suddenly throw them into a concurrent environment where the Python state is mutating underneath them.

Again though, "rewriting code for concurrency" is not a fundamentally unsolvable problem, it just takes a lot of engineer time to change everything over. Moving global/static state into instances, adding locks, marking atomic/critical segments, that kind of thing. There's just a lot of things built with Python that would need to be gone over.

I really think you could do a switchover on the fly by adding a Java-style "synchronized" attribute. Before you can enter a synchronized method, you set a flag and all other threads must yield at their next return, function call, loop iteration, the end of their atomic segment, or at safe points marked by a "yield" statement (pick some combination of reasonable behavior). While a synchronized method is on the call stack, no other thread may execute. All existing code is marked synchronized - perhaps any code in a .py file is assumed unsafe by default, while any code in a .jy file is assumed safe. Boom, start converting code.

The thing that really gets me is that Python 3 is already pushing breaking changes that necessitate a complete overhaul anyway. The failure to thread the interpreter/remove the GIL at the same time is a stunningly idiotic decision. How about since we are making everyone review their code anyway, we have them look at thread safety too?

Which leads to the other problem - Python is GVR's baby, and at the end of the day the reason Python 3 has a GIL is because he says so. By all means, Google could go ahead and rewrite everything, but he'd never let them call it Python. It's hard to build momentum for a serious fork like that. And you don't want to spend a bunch of engineer time and end up with an unsupported "toy" that nobody uses.

It's a shame, Python hits real close to the mark but concurrency is its Achilles' Heel. I love the language but I am gunshy about using it because you never know if your project will go from "toy" to "real product that may need to adapt/scale" and you need concurrency.

Re: Problems I Have with Python

#147

Post by __david__ »

y7 wrote: post #9

Very short-sightedly written. It sounds like the author just wants a language with a different philosophy, and instead of realizing this goes on to call the differences "obvious flaws in design" that aren't improved because of "Incompetence? Politics? Who knows." This is especially bad given that Python (in my opinion) has a very well thought-out and transparent change process, with PEPs that usually consider most al…

> Why is it such a problem to move your closure to its own line and give it a name?

That's actually one of my bigger beefs with Python: it forces a large naming burden on the programmer. When writing python code I find myself struggling to name intermediate results or stupid functions that should just be lambdas. Very very often those results don't warrant a name, or are unnameable. Also, naming something implies it will be useful in another context, which one-off lambdas rarely are.

Re: Problems I Have with Python

#148

Post by loganekz »

Loic wrote: post #28
orf wrote: post #15

Earlier quoted context omitted.

from asyncio import wait, gather, get_event_loop from aiohttp import web async my_handler(request): handle1 = call_webservice_1(args) handle2 = call_webservice_2(args) handle3 = call_webservice_3(args) await wait(gather(handle1, handle2, handle3), 500) return web.Response({'finished': True}) app = web.Application() app.router.add_route('GET', '/test/', my_handler) loop = asyncio.get_event_loop() server = loop.create_…

I am using flask because you know, long string of development with flask over the years, your application is growing and then you hit some walls. I do not want to rewrite everything just for a couple of views within my application. Flask with gunicorn has its own even loop and asyncio io another one and at the end it is hard to be sure if something is working because I am lucky or because it is the way to do things.…

If you haven't already, check out sanic [1] which is powered by uvloop [2] which itself is pretty amazing.

[1] https://github.com/channelcat/sanic

[2] https://github.com/MagicStack/uvloop

Re: Problems I Have with Python

#149

Post by khedoros1 »

OskarS wrote: post #44
fleetfox wrote: post #25

Earlier quoted context omitted.

IMHO switch is horrible construct i'd rather see ML style pattern matching

Switch makes sense in really low level languages like C where it becomes a branch table (and allows things like Duff's device), but it has no place in higher-level languages. Fallthrough, while very occasionally useful, is bug prone and weird (breaks the "principle of least surprise" in a major way). Python made the right call not including it.

So do it like "match" in Rust. Fallthrough certainly seems un-Pythonic. It seems worthwhile to ditch it in favor of pattern matching.

It also seems un-Pythonic to have to implement something in a less-obvious way. Choosing an action based on a one item from a set of possible inputs means either a dict that maps to lambdas or function variables or a big chain of if-else. Neither of those options are optimal.

Re: Problems I Have with Python

#150

Post by takeda »

darkf wrote: post #6
koliber wrote: post #4

Some of the author's points are valid. However, many are subjective preferences, and some are gripes without solutions, and others make it difficult to understand the author's underlying philosophy. My main critique is that the author added this statement that puts a negative, entitled, and naive tone on the whole article: >>> to which no real improvements are being made for some reason. (Incompetence? Politics? Both…

>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 it is hard to remove it. It already was removed in the past. The problem is that when GIL is replaced with smaller locks, the python becomes much slower, because of some features and behavior that people got used to.

One could make python faster by changing behavior, but then it would break existing code and C extensions.

There's no easy way to do this without sacrificing something else. Larry Hastings work on removing GIL and has interesting talk about it[1]

[1] https://www.youtube.com/watch?v=fgWUwQVoLHo

Post reply on HN