Live data from Hacker News

Problems I Have with Python

darkf.github.io

191–200 of 239 posts

Re: Problems I Have with Python

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

The standard library in general encourages use of higher-order functions and concepts borrowed primarily from FPLs (see: comprehensions, map/reduce, sort, etc.) I could not imagine seeing them backtracking on this -- it only helps them to go further in that direction.

I don't think the standard library really 'encourages' this in a way that's different from most languages that support first class (rather than 'higher order') functions. If you consider python's evolution, its support for many common programming paradigms was somewhat haphazard and weak and developed over time, mostly pragmatically. OO has become stronger, the 80% use case of common functional idioms is covered by comprehensions, etc. Ill thought out features (e.g. terrible lambdas) have become de-emphasised. The choices are extensively document, even if not everyone cup of tea so it seems both glib and inaccurate to say (re: FP) 'it only helps them to go further in that direction'. How does it help them?

Re: Problems I Have with Python

#192

One of the biggest Python issues I see is the inability to hide or protect Python source code. 'Compiling' into byte code is easily reversible using pip packages like uncompyle2. Various pip packages offer code obfuscation but from my tests cause problems when running the code. Encrypted bytecode seems to always be decryptable due to the very nature of having an interpreter. Moving Python code into modules implemente…

>>I would be curious to know how other folks hide/protect Python code?

With lawyers.

Most of the commercial products that are written in python come in with a EULA that says "don't touch".

Re: Problems I Have with Python

#193

> The standard interpreter bring rather slow; I'm tired about this one. In the last 13 years, 97% if the projects I worked on didn't need Python to be any faster, it was not the bottleneck. The remaining ones could leverage some solution to bypass the problem. Python speed is indeed an issue to a few people, but it's not the red flag I can read about here and there. I've been hearing this argument for ever. PHP is sl…

I think the point many are making here is, if you're going to break compatibility as was done with Python 3, then fix the underlying issues with the implementation.

- Python 2 calls out to C code alot? Ok, rebuild the interpreter in such as way that allows for a JIT. Prevent callouts to C or severely limit them. JITs are mature technologies now, many dynamic languages have it.

- Remove the GIL, make it fan out for multicore.

- Add a Generational Garbage collector, remove the reference counted one with timely finalization.

- Add back all the missing features for FP that people are asking for.

If you're going to break compatibility, don't take half-measures, go all the way.

Re: Problems I Have with Python

#194

One of the biggest Python issues I see is the inability to hide or protect Python source code. 'Compiling' into byte code is easily reversible using pip packages like uncompyle2. Various pip packages offer code obfuscation but from my tests cause problems when running the code. Encrypted bytecode seems to always be decryptable due to the very nature of having an interpreter. Moving Python code into modules implemente…

> One of the biggest Python issues I see is the inability to hide or protect Python source code.

As with other code (source or object), it is protected by means of law.

If you want to hide it, run a service on a computer you control and sell access to the service.

Re: Problems I Have with Python

#195

> The standard interpreter bring rather slow; I'm tired about this one. In the last 13 years, 97% if the projects I worked on didn't need Python to be any faster, it was not the bottleneck. The remaining ones could leverage some solution to bypass the problem. Python speed is indeed an issue to a few people, but it's not the red flag I can read about here and there. I've been hearing this argument for ever. PHP is sl…

now count back from 10 slowly.

Re: Problems I Have with Python

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

>most people don't see POSIX threads are an inherently broken abstraction.

o.O

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

O.o

> Threads (and implicitly signals) on the other hand are convenient fantasies that we would like to exist but are actually just fantasies.

O.O

I'm not sure how this relates to python but it was entertaining at least.

Re: Problems I Have with Python

#197

Earlier quoted context omitted.

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

When talking about JVM languages suitable for building systems, Jython isn't generally mentioned for the reasons you give, nor is Apache Groovy. Those two are good for scripting, e.g. testing Java classes, build scripts, glue code. Besides Java, languages like Clojure, Scala, and Kotlin are usually considered as systems languages on the JVM.

Re: Problems I Have with Python

#198
post #104
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.

>You can't do that in Haskell either, and any FP purist would blanch at a statement like that. Obviously you've never met State and/or lens then. Yes, you can do it -- and no, I never said it should follow pure FP principles.

But if you write a State equivalent of "x += 1" in Python then you can use it in a lambda too.

Re: Problems I Have with Python

#199
post #182
post #41

Earlier quoted context omitted.

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

Where does the update of `x` go in this example? By observing a Queue or Stream `q`?

Re: Problems I Have with Python

#200

> The standard interpreter bring rather slow; I'm tired about this one. In the last 13 years, 97% if the projects I worked on didn't need Python to be any faster, it was not the bottleneck. The remaining ones could leverage some solution to bypass the problem. Python speed is indeed an issue to a few people, but it's not the red flag I can read about here and there. I've been hearing this argument for ever. PHP is sl…

Great answer!

I also wished to be paid to dev in Python :p

Post reply on HN