Live data from Hacker News

Problems I Have with Python

darkf.github.io

41–50 of 239 posts

Re: Problems I Have with Python

#41
post #37
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.

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)

Re: Problems I Have with Python

#42
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…

> with decent solutions like AFAIK Jython. >>- solving some of the issues would exacerbate backwards compatibility. Such as what? Jython can't load native C extensions which should be GIL aware. Most programs, and the python interpreter itself, aren't thread safe so suddenly removing the GIL would break a lot of programs. I agree with you that the concurrency story for python sucks, but claiming solutions could exist…

Is Jython good though?

Last I used it is had issues keeping pace, i.e. demonstrable memory issue that took a long time to fix, lagged considerably behind python 2/3 versions.

It's also worth noting, that as an essentially transcompiled language, you need to have a good appreciation of Java machinery, in which case languages like Groovy provide good competition.

Re: Problems I Have with Python

#43
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…

> with decent solutions like AFAIK Jython. >>- solving some of the issues would exacerbate backwards compatibility. Such as what? Jython can't load native C extensions which should be GIL aware. Most programs, and the python interpreter itself, aren't thread safe so suddenly removing the GIL would break a lot of programs. I agree with you that the concurrency story for python sucks, but claiming solutions could exist…

FWIW, the folks working on TruffleRuby have done some amazing things on this front - essentially making an interpreter for Ruby C extensions that JITs to code that's more-or-less identical in performance to the original native version.

Re: Problems I Have with Python

#44
post #18

I like this list a lot. I also find myself raging at awful lambda and the lack of switch. No, it wouldn't make the language any less "pythonic" to make them useful.

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.

Re: Problems I Have with Python

#45
post #12

I love how so much person focus on the GIL and multithreading, when GIL is much more a solution to make un-threadsafe libs safe to use, and that most people don't see POSIX threads are an inherently broken abstraction. [1] http://www.daemonology.net/blog/2011-12-17-POSIX-close-is-br... In fact it pretty much boils down to signals being broken on unices [2] https://lwn.net/Articles/683118/ Which even though I have a h…

  > I love how so much person focus on the GIL
Do you really? I don't see much love in your comment.

Re: Problems I Have with Python

#46
post #6
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…

I was taken back by this rather harsh treatment of Python.

Is it really realistic to 'have it all'? I'm fully aware that I'd have to go to crazier languages if I want parallelism or speed. For what Python is, it offers me reasonable tradeoffs (mostly slanted towards productivity)..

Regarding the FP comments, since it lacks TCO, my take away has always been that Python can only ever become a quasi-functional language. Its hard to be more than that in its current state.

Anyways. These questions made me want to ask you - what languages do you think are better in comparison?

Re: Problems I Have with Python

#47
post #24
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? What if it cannot have a meaningful name? You don't give a name to every single value in your program, why would first-class functions be any different? Like, there's an idiom in python where you write a function named "wrapper" in a decorator and then return wrapper. Except you put @wraps on it, so the name of this function isn't even…

The name of the function when you read the code is still wrapper. The point of naming it is that it allows you to refer back to it, as well as provide the reader with a clue to what it does. This way, Python attempts to reduce nesting, which reduces ease of reading. You see this a lot in Javascript, with all the anonymous functions being passed around. Besides that it makes your stack trace hard to parse, it also makes it hard to follow if you're currently reading a named function, or an anonymous function that's being passed as a parameter inside another anonymous function, etc.

Re: Problems I Have with Python

#48
post #10
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…

> Very short-sightedly written. It sounds like the author just wants a language with a different philosophy Which is not a priori bad to want, especially if a language has a broken philosophy (or partially broken) to begin with.

The only way I see a philosophy as being a broken one if it is founded on false premises, or internally inconsistent (or do you see a different way?). Which is the case with Python and why?

Re: Problems I Have with Python

#49
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…

Another big issue to keep in mind when critiquing Python, as opposed to e.g. JavaScript or Ruby, is that Python is used for so much more besides webdev/etc. stuff. So making changes that improve life for webdevs could suddenly make life worse for people using Python in high energy physics, or in chemical engineering, or in AI research, or a large number of other fields that a webdev might not even know exists. Every supercomputer on the planet runs Python code, scientific Python usage is a really big field, with enough passionate users to hold multiple conferences every year; orders of magnitude more in casual users.

Re: Problems I Have with Python

#50
post #16

could someone explain to me why >>> ranges = [range(i) for i in range(5)] >>> [*item for item in ranges] [0, 0, 1, 0, 1, 2, 0, 1, 2, 3] would be better than: >>> ranges = [range(i) for i in range(5)] >>> [item for subrange in ranges for item in subrange] [0, 0, 1, 0, 1, 2, 0, 1, 2, 3]

Less verbose. Also, what happens if you have even more nested lists you want to flatten? Personally I think it should just be flatten(range(i) or i in range(5)) With flatten in the global namespace

Given that flatten is surprisingly tricky to get right, it really should be built-in. The naive recursive variant will crash python if you nest lists beyond the stack limit, which is very no bueno. A list that's nested 10,000 layers deep is not especially hard to create or store in memory, and a flatten implementation should be able to handle it without crashing the interpreter.

In fact, it's not a bad little programming exercise: making a flatten that performs well and never crashes because of stack overflow.

Post reply on HN