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

81–90 of 239 posts

Re: Problems I Have with Python

#81

Post by vegabook »

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.

this is the essence of the problem for Python's long term future. They've been so burned by the 2-to-3 mess that nobody will ever dare touch the fundamentals again. As you say, some of this stuff (performance, multicore) should have been slotted into 3 since it was breaking-change already, even if delaying it by a few years. Then everybody would have moved, pronto. Now, even if 3 finally snuffs 2 out, we'll be stuck with the fairly unsatisfactory 3 underlying architecture essentially forever.

Re: Problems I Have with Python

#82

Post by OskarS »

toyg wrote: post #67
OskarS wrote: post #50

Earlier quoted context omitted.

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 program…

I've not tried, but you can probably get that by recursively mixing standard constructs and functools.chain.from_iterable().

You should try. It's harder than it seems.

(I mean, it's not the most challenging problem ever, but most programmers look at it and go "that's trivial, just do X!", and it's a bit trickier than that).

Re: Problems I Have with Python

#83

Post by SFJulie »

dkersten wrote: post #54
SFJulie wrote: 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…

The GIL doesn't magically make un-thread safe code thread safe. It makes Pythons reference counting implementation thread safe.

The core dev having worked on new GIL (py3.2) explained this to me.

I never said it was magic.

But he said GIL is a tool to achieve thread-safety in python when calling non 'thread safe' code.

I am not him, I will not take on any argument of how it works.

But since ruby GIL is inspired by python GIL let's hear ruby coders: http://www.rubyinside.com/does-the-gil-make-your-ruby-code-t...

Oh, yes, it seems some people are seeing it my way and that it is a controversial point that can be argued. So I agree to disagree.

Btw, I don't multithread and share states, I multiprocess with 0MQ and communication patterns such as PUB/SUB PUSH/PULL for the obvious reasons that I really think multi-threading is an over-valued and wrong abstraction.

Re: Problems I Have with Python

#84

Post by nhumrich »

Grue3 wrote: post #24
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? 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…

Then give it a stupid name. "helper_func", "inline()", or even "_a". If you think the name isn't important, then don't waste your time on it.

Re: Problems I Have with Python

#85

Post by yxhuvud »

coldtea wrote: post #10
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…

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

Well, perhaps that means the right solution is not to complain about the language but to switch to Ruby (or Crystal) instead.. :P

Re: Problems I Have with Python

#86

Post by amyjess »

sametmax wrote: post #74
olau wrote: post #70

Earlier quoted context omitted.

"No. Python 3 arrived quickly after many warnings. Then tools, tutorials and a looooooooooooot of time have been provided. This is nowhere Python's fault. It's the best damn migration story I've ever witnessed in my life. My only grudge on Python 3 is that it didn't break ENOUGH. I wished for stuff to have changed more." I think you wrote a good comment, thanks!, but regarding 2 to 3, I think you got this wrong. I th…

The problem I have with this theory is that the JS community and Ruby community had big breaking changes, dev told them to fuck off. The community adapted quickly. Python took care of the community, giving time, tools and doc. And nobody moved. But they surely complained a lot. What does that say ?

In the case of Ruby, it's because the vast majority of the Ruby community is tied to a single framework. Ruby developers go where Rails goes.

Re: Problems I Have with Python

#87

Post by metaphorm »

my perspective on this is that that is a remarkably short list of complaints for a programming language, all things considered.

Python is certainly not perfect, but a similar list of pet peeves and grievances for, say PHP or Java would easily be 10 times longer even under the most charitable interpretations.

Re: Problems I Have with Python

#88

Post by KingMob »

xapata wrote: post #72
dev360 wrote: post #46

Earlier quoted context omitted.

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

The lack of tail-call optimization to make the CPython interpreter simpler and debugging easier by preserving the call stack. It was a choice, not an oversight.

Why not just make it a dev/production flag, then?

Re: Problems I Have with Python

#89

Post by gigatexal »

I agree on lamdas and the gist that things must look pythonic to be accepted as that holds the language back from iterating or evolving. The rest of his points read like scope creep in that he seems to want the language to be something it's not.
Post reply on HN