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

181–190 of 239 posts

Re: Problems I Have with Python

#181

Post by xapata »

__david__ wrote: post #147
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…

Whenever I have difficulty thinking of a good name for an intermediate step, I start to worry that my algorithm is unnecessarily complicated.

Re: Problems I Have with Python

#182

Post by xapata »

jononor wrote: post #41
lmm wrote: post #37

Earlier quoted context omitted.

That seems like an exceedingly error-prone thing to write. "x +=1" isn't a value and the unmanaged mutation will be surprising when it happens. On a Python implementation with parallelism (e.g. Jython) you could very easily end up losing updates - on CPython the GIL will probably mean your code accidentally doesn't exhibit that problem, but that doesn't seem a very desirable way to code.

What is the proposed alternative? (using a named function or method just seems to be semantically the same, just more characters)

    foo.on_click(partial(q.append, foo))
The nice thing about ``append`` is it's atomic (for builtins).

Re: Problems I Have with Python

#183

Post by diek »

ProblemFactory wrote: post #57
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…

> I did not propose a solution because there are many, as you note; there are, however, implementations with decent solutions like AFAIK Jython. There are no solutions that satisfy everyone that I am aware of yet. Guido has said in the past that he'd be happy to get rid of the GIL, and would merge a patch that solves it, as long as: * It does not reduce the performance of single-threaded Python code. * It stays compa…

> It is not an issue for apps which spend most of the time doing I/O.

This is a common misconception that doesn't seem to be backed up by any data.

Dave Beazley did a number of performance tests with profiling, looking at GIL contention in a multi-core scenario: http://www.dabeaz.com/python/GIL.pdf

The results were that even IO-bound workloads still suffered because of the poor implementation of the GIL (details on slide 35 or so). This was an issue up until Python 3.2 (!) when a new GIL implementation was added, which he also profiled: http://www.dabeaz.com/python/NewGIL.pdf

Re: Problems I Have with Python

#184

Post by njharman »

Pxtl wrote: post #62

I honestly don't get why they made the big compatibility-breaking move to Python 3 without using that opportunity to change things for better performance and no GIL.

1) it was looked at and took too much effort.

2) Performance and GIL are things people who don't actually use Python complain about. In practice they are non-issues or have workable solutions.

Re: Problems I Have with Python

#185

Post by dragonwriter »

__david__ wrote: post #147
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…

> Also, naming something implies it will be useful in another context, which one-off lambdas rarely are.

Naming something in a local scope doesn't imply that it will be useful other than at least one place on that local scope. In fact, it's a pretty clear indication that you don't expect to need it anywhere outside of that scope.

Re: Problems I Have with Python

#186

Post by dragonwriter »

kazinator wrote: post #145
amyjess wrote: post #80

Earlier quoted context omitted.

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

yeah, except that the syntax is

  lambda x: func(x, whatever)
In fact, if x is an object that stores a mutable numeric cell, you could even do a mutating:

  lambda x: x.add(1)
Mutation isn't prohibited in Python lambdas, statements (including assignments, which are statements rather than expressions in Python), however, are.

Re: Problems I Have with Python

#187

Post by acqq »

nomel wrote: post #165
acqq wrote: post #78

Earlier quoted context omitted.

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

When he claimed that the properties P or Q are of each of the set of A, B, C, D, E, you claim that I can't conclude that he said that P or Q are the properties of A?

I used A has property P, substitute A has property Q, it's still wrong claim of him, for the very same reasons:

Python has a huge user base, if he can improve it in any of his points (I just selected one) and keep it working for the user base, please. I know he won't be able, his talk is of ignorance and provocation.

And these who develop aren't stupid or doing politics, they keep the Python working for their base, improving it as much as they can.

See https://news.ycombinator.com/item?id=13485784

Re: Problems I Have with Python

#188

Post by takeda »

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?

The biggest challenge of removing GIL is to do it without breaking existing code.

There's work on that. Here's a technical talk about why is it difficult[1].

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

Re: Problems I Have with Python

#190

Post by stcredzero »

paulmd wrote: post #161
stcredzero wrote: post #142

Earlier quoted context omitted.

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.

Jython already fixed the GIL problem. The problem is the legacy codebase built on assumptions of non-concurrency

Which is to say that Jython didn't completely fix the GIL problem, from the POV of a lot of people.

Post reply on HN