Problems I Have with Python • Hacker News Board

Re: Problems I Have with Python

#131

Post by oblio » Wed, Jan 25, 2017, 6:08 PM UTC

jknoepfler wrote: post #112

I don't understand the desire to turn python into a high performance language. It's 2017, if you want performance just write some go/cpp/rust. If you want to leverage an old and very mature concurrency framework, use elixir/erlang. If you need a giant data integration framework, use java. If you want a stellar bash replacement, use python. Know your tools, don't bloat them with unnecessary crap. (The list was not int…

Is it nil or null or None?

Is it -eq or == or ===?

Can it be undefined?

Is it / or //?

Is is "".format() or "#{}" or "${}"?

And that's before we get to language idioms, common libraries, package managers, build tools, lint tools, compilers or VM configurations, etc.

There's a reason people try to use a language in as many areas as feasible.

Re: Problems I Have with Python

#132

Post by zerkten » Wed, Jan 25, 2017, 6:08 PM UTC

jack9 wrote: post #100

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

> I was taken back by this rather harsh treatment of Python. I am taken aback by the evangelical tone of Python enthusiasts, where is has warts intentionally maintained by the creator in the form of missing features. If you want speed you go to any other scripting language (other than Ruby). I agree Python is mostly sane and naiively productive. That being said, it's a result of the syntax. Transpiling it to another…

> If you want speed you go to any other scripting language (other than Ruby).

Ruby has historically had the same issues. Most Pythonistas I know aren't so evangelical. It's mostly a question of how to go about integrating C/C++ code.

Many people complaining about the GIL (and the like) have some naive microbenchmark, don't understand the trade-offs/limitations of their runtime etc. That doesn't mean critique isn't important and required, but it's going to be better when it's properly researched and improves on the body of work out there (https://www.youtube.com/watch?v=Obt-vMVdM8s).

> Transpiling it to another language like Google did, shows that the underlying technology is not worth much.

How is this any general indicator of the worth of the language?

It shows for some cases, that Google thought this was a worthwhile investment. Google has experimented for a long time with ways to improve how Python code can be run. They ran the Unladen Swallow project, but spent more time on LLVM issues at the time making it infeasible to continue the project.

They'll discontinue one path and try another. None of this is really a commentary from Google on CPython, the community, or the value that it has for most people. The people working on this stuff interact in a pretty friendly basis.

Re: Problems I Have with Python

#133

Post by codr4life » Wed, Jan 25, 2017, 6:11 PM UTC

I've spent soo much time struggling with Python over the years, traveled across Europe for PyCon and tried to tune into the community. I really wanted it to be the good enough Lisp that Norvig claims it is. But in the end I always come out of it swearing to never touch the inconsistent, arbitrary, pile of exceptions again. Conceptually, it's C++ in scripting language clothes.

Re: Problems I Have with Python

#134

Post by mixmastamyk » Wed, Jan 25, 2017, 6:11 PM UTC

protomok wrote: post #128

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…

There's probably not that much code that is so unique and difficult that it could not be reimplemented quickly from a spec. On the other hand, if the code happens to be part of a large system, it gets increasingly difficult to understand and use, from just a code dump without author support.

I submit that those two sets don't intersect much, and probably why this issue does not get much attention. Cython might be a solution.

Re: Problems I Have with Python

#135

Post by zerkten » Wed, Jan 25, 2017, 6:16 PM UTC

Pxtl wrote: post #121

jknoepfler wrote: post #112

I don't understand the desire to turn python into a high performance language. It's 2017, if you want performance just write some go/cpp/rust. If you want to leverage an old and very mature concurrency framework, use elixir/erlang. If you need a giant data integration framework, use java. If you want a stellar bash replacement, use python. Know your tools, don't bloat them with unnecessary crap. (The list was not int…

Because other high-performance languages have been improving their readability and expressiveness. Personally, my tool of choice is C# right now. I find it quite readable, and every bit as expressive as python - even moreso, plus it has the performance advantages of being designed from square 1 as a compiled language instead of an interpreted one. It has async/await, it has functional features that Guido hates, it ha…

Python has async/await since Python 3.5. I recall Guido acknowledging C# in a Pycon keynote. I don't think Guido hates (or misunderstands) functional features, but rather prefers Python to be something different from what you want.

Re: Problems I Have with Python

#136

Post by jogjayr » Wed, Jan 25, 2017, 6:24 PM UTC

Serious question: is the whole deal with the Python GIL solvable if some BigCo decides to throw a ton of money and engineers at it? Like Google with V8, for instance. Or is it a truly hard problem that will take something special to solve?

Re: Problems I Have with Python

#137

Post by ThatGeoGuy » Wed, Jan 25, 2017, 6:26 PM UTC

numlocked wrote: post #79

For flatten, use: flattened = sum(list_of_lists, ())

This only flattens one level. Consider the following snippets:

    ; CHICKEN Scheme
    #;1> (flatten '((1 2 3) ((4 5) 6) (7 (8) (((((9))))))))
    (1 2 3 4 5 6 7 8 9)
    #;2> (apply append '((1 2 3) ((4 5) 6) (7 (8) (((((9))))))))
    (1 2 3 (4 5) 6 7 (8) (((((9))))))

vs.

    # Python 3
    >>> sum([[1,2,3], [[4,5],6], [7, [8], [[[[[9]]]]]]], [])
    [1, 2, 3, [4, 5], 6, 7, [8], [[[[[9]]]]]]

There's a big difference here. Flattening a list to just the elements inside isn't terribly hard, especially in a language like Scheme with tail-recursion, but flatten is definitely something that should be in the standard library. The "flatten" you propose is really just appending the elements of the first level of the list.

Re: Problems I Have with Python

#138

Post by ThatGeoGuy » Wed, Jan 25, 2017, 6:30 PM UTC

amyjess wrote: post #86

sametmax wrote: post #74

Earlier quoted context omitted.

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.

But this just highlights the case with JavaScript even more. In JavaScript nobody is tied to any framework, and they can easily leave for another browser at any time. Heck, with jQuery, it doesn't even matter if you're writing ECMAScript 3 or 6, everything still pretty much works the same out of the box.

At the end of the day there's a lot to be said about the transition from 2 to 3, but I think in general the Python community got off easy compared to some of the breaking changes in other language communities.

Re: Problems I Have with Python

#139

Post by za_creature » Wed, Jan 25, 2017, 6:36 PM UTC

sabauma wrote: post #111

pinjo wrote: post #96

Earlier quoted context omitted.

From a debugging viewpoint, this does not make sense, there is usually no interesting information in the in between frames. TCE can also make debugging easier, how useful is a stack trace of 1000 lines consisting of ... File "bla.py", line 4, in fib return fib(n - 1) + fib(n - 2) File "bla.py", line 4, in fib return fib(n - 1) + fib(n - 2) File "bla.py", line 4, in fib return fib(n - 1) + fib(n - 2) ... Not so much I…

The notion that not having proper tail calls aids debugging always seemed like a post-hoc justification. The stack trace of an iterative function will lack exactly the same intermediate evaluation frames as a tail-recursive implementation.

The thing is, tail calls aren't _just_ about emulating iteration via recursion:

  def foo():
      raise ValueError

  def bar():
      return foo()

  bar()

With TCO, the stack trace would contain `main` and `foo`, as `bar`'s frame would be overwritten by `foo`. This example is simple, but `bar` could be a 50 line long if-else chain of tail calls and when debugging you won't necessarily know which condition was evaluated.

Re: Problems I Have with Python

#140

Post by xkxx » Wed, Jan 25, 2017, 6:42 PM UTC

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

I believe you meant to write "str and list both have index, but list does not have find".