Live data from Hacker News

Problems I Have with Python

darkf.github.io

11–20 of 239 posts

Re: Problems I Have with Python

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

  > 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 without breaking back-compat is just not right.

Re: Problems I Have with Python

#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 hatred for systemd, systemd is trying to fix by leaving the status quo. However, POSIX signals are still a problem to systemd [3] https://github.com/systemd/systemd/issues/1615

Having played with signal in python+C, I have the experience of python having some holes around the signals: no mask can bet set. I thought initially python sucked because of the most common denominator problem of system languages (having to make you support only small subsets of features). But, I am now thinking POSIX signal are just a broken OS level software interrupt implementation.

So going down the rabbit hole, after reading Stevens on unix/POSIX programming (a must read). I am pretty much thinking questioning fred brooks (hence K&R&T) biggest failure: OS360 followed by unices.

What if our quest for a multitasking portable OS that does not care about the HW is doomed?

It makes a darn good job for 99.999% of the case. The .001% remaining being the signals.

Look at it, what is a process meant to be?

A container running code.

A thread? Cooperative code sharing data. But how do you cooperate? You send signals.

The problem, it is in case of high use of signals the OS get "signal bound" in a way we cannot measure.

signals are like a huge software bus that is not easily measurable and at the opposite of a lot of primitive cannot be HW bound. It is basically a software bus that tries to convey the concept of HW interrupts that are normally handled with micro chips. Look at the MC2828 brochure and you can recognize the feature signals are trying to provide [4] https://upload.wikimedia.org/wikipedia/commons/3/31/Motorola...

So to wrap up, we may have a problem of HW architecture that results in a buggy implementation of a common API. Like trying to emulate MMU on a MMU less CPU.

And I would say that it is thanks to my experiments in python that I discovered that signals was an unreliable 1bit message delivery protocol. Python made it easy to experiment.

Python has problems. (mostly a weired mix of conservatism and progress on concerns I don't share and politics). But overall it is a good system language that deals with problem. And poor support of signals, threading are not a bug from python.

A good system language does not try to fix system glitches, he let them stay obvious. All the hate against GIL/threading/signals/weired async IO may be better directed at the quest for a portable multitasking generic OS.

Threads (and implicitly signals) on the other hand are convenient fantasies that we would like to exist but are actually just fantasies. And to solve the problem, we invented the containers... based .... on cooperative multitasking system ... based ... on threads and signals.

Re: Problems I Have with Python

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

If you claim it's "incompetence" (it's not) then publish the patches that don't break anything but significantly speed up it, for example. Because you complain "it' slow."

It's not what you think it is. It's Python, not a toy language used by nobody. Just first try yourself to "fix" Python and keep its existing users happy by not breaking anything for them, then write about it.

Re: Problems I Have with Python

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

>but claiming solutions could exist without breaking back-compat is just not right.

I mean, you have a good point on C extensions but code relying on them (without a really portable API) is almost never going to be forward compatible anyway. (There are still quite a few C extensions not up to CPython 3 yet.)

Re: Problems I Have with Python

#15
post #3

The one problem I have with Python and would like to solve, is to be able, from within a request rendering function/method of my web application (think Flask) to run something like: handle1 = call_webservice_1(args) handle2 = call_webservice_2(args) handle3 = call_webservice_3(args) (realres1, realres2, realres3) = wait_until_timeout(500, handle1, handle2, handle3) # here, I have my results in realresX or None if tim…

    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_server(app.make_handler())
    loop.run_until_complete(server)
Done. Not flask, but if you need to make lots of parallel network calls during a web request why the hell are you using flask?

Re: Problems I Have with Python

#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]

Re: Problems I Have with Python

#17
post #13
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…

If you claim it's "incompetence" (it's not) then publish the patches that don't break anything but significantly speed up it, for example. Because you complain "it' slow." It's not what you think it is. It's Python, not a toy language used by nobody. Just first try yourself to "fix" Python and keep its existing users happy by not breaking anything for them, then write about it.

Cool, I think you completely dodged the point. I never said it was slow because they were incompetent.

Re: Problems I Have with Python

#19
Python's semantics are unlikely to ever be fast and most Python users have already worked around its speed issues.

asyncio is new; python3 porting is happening. It seems unfair to complain that no real improvements are being made and also complain that these new things are immature.

reduce being pushed behind an import is stupid, but it's only one import.

lambda is fine, if you're writing in functional style you're using expressions for everything anyway. And you will probably be more persuasive if you can make your points less offensively.

For "bag of data" classes look at attrs.

(All that said, having found Scala I don't miss Python at all. (Except when writing a desktop GUI - PyQt was really nice))

Re: Problems I Have with Python

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

> "- solving some of the issues would exacerbate backwards compatibility."

That boat sailed a long time ago with the introduction of Python 3.

(Ok, Ok my comment is slightly tongue-in-cheek. I agree that backwards compatibility is usually a good idea and should not be broken without a great deal of thought.)

Post reply on HN