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

231–239 of 239 posts

Re: Problems I Have with Python

#231

Post by xapata »

diek wrote: post #183
ProblemFactory wrote: post #57

Earlier quoted context omitted.

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

Not backed up by data? Maybe because it's so easy to document that no one bothers to write about it?

Multithreaded IO-bound tasks don't care about the GIL.

Yeah the old implementations of the language were not as good as the latest. It doesn't seem right to criticize the language for problems that have already been fixed.

Re: Problems I Have with Python

#232

Post by smaudet »

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…

I think the hate is directed at GIL because everbody else has figured out reasonably safe ways to thread and share data. Java doesn't have this problem, and I think all the other languages have a solution.

So what, maybe some C implementation of threads has problems, that doesnt mean people haven't figured out models that work.

Whats worse, the distrust of functional style programming means that, if threads are really doomed, python has no way of being a system level language, since the other option is using functional islands that signal or queue to each other (which is directly representable by hardware). In this case, python becomes little more than DSL relegated mostly to imperative programming for tiny scripts, not a system level language.

I for one hope and believe that won't happen, with options like PyPy, Twisted, and Jython. Ironically, the only way Python will survive is for it to become unpythonic, something that has already happened as the orginal maintainers of the language insist on their own pig-headed agendas that most don't care for. I think CPython will ultimately fail, and will be practically replaced by the community with something...less toxic.

Re: Problems I Have with Python

#233

Post by d0mine »

I've seen most the points discussed several times already on python-ideas, python-dev lists -- that is at the very least some of the points have merit and if the author has anything new to add then these lists might be also the place to do it.

> Even weirder, str and list both have find, but list does not have index (a related method).

It is in reverse: both str and list has index() methods. str has find(). To find out whether an item is in the list in Python:

  if item in your_list:
      ...
> class FooNode

There is attrs package [1], to avoid boilerplate for a mutable analog of collections.namedtuple ("case classes" [2]):

  @attr.s
  class C(object):
      x = attr.ib(default=42)
      y = attr.ib(default=attr.Factory(list))
> Lack of switch

It is hard to discuss it without a specific code example from an existing popular codebase that shows the advantages of "switch" statement (to compare the current code and how it looks like with a suggested "switch" syntax). To justify a new syntax you should be able to find dozens of applicable examples easily.

[1] https://pypi.python.org/pypi/attrs [2] http://www.codecommit.com/blog/scala/case-classes-are-cool

Re: Problems I Have with Python

#234

Post by vegabook »

BuckRogers wrote: post #224
vegabook wrote: post #81

Earlier quoted context omitted.

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…

Please don't encourage them. I'm fairly certain the CPython core dev team will take almost any suggestion like this as a challenge and break everyone's code again in Python4. They see it as stabbing back at those corporate freeloaders. Or at least that's the public front. I'd just like them to take lessons from Go and actually get unicode right. I'm far more interested in Grumpy. Python2 and Grumpy seems like more of…

Well said. Google hired Guido, and from being a big Python shop was so disenchanted with Unladen Swallow's abject failure that they invented a whole new language to replace it, and Guido became surplus to requirements. And the last vestiges of Python are now to be piped through Grumpy. Not a single mention of 3.x and Google in the same breath. Py27+Grumpy looks great.

Re: Problems I Have with Python

#235

Post by dragonwriter »

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.

As disruptive as it was, Py3 had fairly minor backwards compatibility breakage. Dropping the GIL would be many times more disruptive (specifically for C extensions, presumably it could be done with no effect on Python-code compatibility.)

Aside from keeping the GIL, performance improvements have beenade throughout the 3.x line, AFAIK, and should be expected to continue.

Re: Problems I Have with Python

#236

Post by dragonwriter »

njharman wrote: post #184
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.

Google was a major user of Python, and their solution to those issues was "build a whole new language". While I agree that on those points Python is good enough for many uses, it's inaccurate to say that all criticism of Python on those points is from people who haven't spent considerable time with Python on production.

Re: Problems I Have with Python

#237

Post by dkersten »

BuckRogers wrote: post #225
__david__ wrote: post #151

Earlier quoted context omitted.

> I really think multi-threading is an over-valued and wrong abstraction. That's as wrong-headed as thinking it's the only good abstraction. Each style has its place—it really depends on what the code needs to do.

I'd tend to agree with the parent that multi-pthreading is a poor abstraction but I'd add an important note: only systems programmers should be explicitly spinning up pthreads. Explicit pthreading is a poor abstraction for everyone else. Application programmers are probably operating at the 'wrong' level and greenthreads make more sense.

Real threads are great for implementing things like clojure's core.async or task systems like Intel's Threading Building Blocks. Both of these are super useful and don't work as well with processes instead of threads. I definitely agree that most programmers shouldn't be using threads directly, but they should be available as a building block for higher level abstractions.

Re: Problems I Have with Python

#238

Post by asrp »

darkf wrote: post #7
asrp wrote: post #2

A lot of the author's complaints, especially near the end, are personal preferences which explains by these "improvements" were never added. Not everyone would prefer a move to a significantly more functional style. Arguably this difference is what caused Coconut to be made in the first place. There's ample discussion on these topics to simply brush existing decisions off as "Incompetence? Politics? Both? Who knows."…

>Arguably this difference is what caused Coconut to be made in the first place. Sure, that and it's far easier to write a new language and transpile than it is to fork and modify existing implementations. >There's ample discussion on these topics to simply brush existing decisions off as "Incompetence? Politics? Both? Who knows." If you would like to link to such discussions I would not hesitate to add them as footno…

Oops, I didn't expect this to blow up, thanks for responding.

Here's a discussion about switch case (I was also looking for one the other day, but in my case, it was purely for optimization).

https://www.python.org/dev/peps/pep-3103/

And the wiki, for example, talks about the GIL

https://wiki.python.org/moin/GlobalInterpreterLock

I remember reading articles from here about that a few times, but can't find them now. If you are still interested, I can try to dig it up.

Re: Problems I Have with Python

#239

Post by diek »

xapata wrote: post #231
diek wrote: post #183

Earlier quoted context omitted.

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

Not backed up by data? Maybe because it's so easy to document that no one bothers to write about it? Multithreaded IO-bound tasks don't care about the GIL. Yeah the old implementations of the language were not as good as the latest. It doesn't seem right to criticize the language for problems that have already been fixed.

"IO-bound multithreading is fine" has been the Python mantra for the last 20 years. Lo and behold, someone actually gathers some data and comes to find out that is absolutely wrong. For the last few years they've had a revamped version of the GIL, but that still has a burden of proof that can only be validated by profiling real-world applications.

A community can't make flat-out invalid claims for two decades and then expect everyone to take them at their word that everything is fine now.

Post reply on HN