Live data from Hacker News

Problems I Have with Python

darkf.github.io

151–160 of 239 posts

Re: Problems I Have with Python

#151
post #83

Earlier quoted context omitted.

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

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

Re: Problems I Have with Python

#152
post #115

Earlier quoted context omitted.

Your post quite strongly alludes to it being either due to incompetence, or politics, or both. So I think grandparent has a very valid point, and you might want to change the tone of your post a bit; then it'll produce fewer knee-jerk reactions, and might be taken more seriously.

Nah, just people connecting that sentiment with other statements. It should be cleared up since it's causing some mass confusion. It's funny because I preface it by saying "Remember that it's a matter of opinion" (and, well, the title alone) and people come out of the woodwork completely disregarding this, or outright misinterpreting sections of it. I maintain that a large reader base here does not actually... read.

Makes me think of something I read about cultural divides. Some cultures think that a speaker can say whatever they feel like, and it's the listener's obligation to figure out how to understand it. Others think that it's the speaker's obligation to structure and phrase things in a way that make it clear to the listener what they meant.

Not looking to make value judgements of whether one is generally better, but I think it's clear that when writing on the internet for general audiences, the second way is more effective in spreading your point.

Re: Problems I Have with Python

#153
post #117
post #76

Earlier quoted context omitted.

Python has made some trade-offs that you dislike. You complain about the negative consequences without comparing those against the benefits. One of the major factors in speed is efficient memory layout. Contrast a Python list with a NumPy array. To achieve speedier loops and vectorized arithmetic [0], the array gives up dynamic typing and dynamic sizing. In most applications, I would gladly give up some compute speed…

>Contrast a Python list with a NumPy array. To achieve speedier loops and vectorized arithmetic [0], the array gives up dynamic typing and dynamic sizing. In most applications, I would gladly give up some compute speed to gain some programming productivity. Except numpy arrays have a much richer interface and can still store dynamic objects (dtype=object). So what's your point? >I love duck-typing So do I. Where does…

Have you ever tried appending to a NumPy array in a loop? It's a total disaster! And dtype=object arrays are mostly useless; they gain almost none of the benefits of regular NumPy (you may as well run np functions on plain lists) and play poorly with other types. NumPy is great for numerics and structured data - lists are general purpose structures for data manipulation. They are different, have different goals and trade offs, and I don't think it's appropriate to claim that one size should fit all.

Re: Problems I Have with Python

#154
> Quite to the point, lambdas (anonymous closures) in Python are gimped. They are single-expression functions, which means no statements, even global/nonlocal qualifiers.

I remember once on rosettacode I wanted to write a Runge-Kutta function in Python with a lambda. I was stopped by the lack of variable assignment, until I remembered that they can be emulated by nesting function calls:

    def RK4(f):
	return lambda t, y, dt: (
		lambda dy1: (
		lambda dy2: (
		lambda dy3: (
		lambda dy4: (dy1 + 2*dy2 + 2*dy3 + dy4)/6
		)( dt * f( t + dt  , y + dy3   ) )
		)( dt * f( t + dt/2, y + dy2/2 ) )
		)( dt * f( t + dt/2, y + dy1/2 ) )
		)( dt * f( t       , y         ) )
https://rosettacode.org/wiki/Runge-Kutta_method#using_lambda

Re: Problems I Have with Python

#155
post #115

Earlier quoted context omitted.

Your post quite strongly alludes to it being either due to incompetence, or politics, or both. So I think grandparent has a very valid point, and you might want to change the tone of your post a bit; then it'll produce fewer knee-jerk reactions, and might be taken more seriously.

Nah, just people connecting that sentiment with other statements. It should be cleared up since it's causing some mass confusion. It's funny because I preface it by saying "Remember that it's a matter of opinion" (and, well, the title alone) and people come out of the woodwork completely disregarding this, or outright misinterpreting sections of it. I maintain that a large reader base here does not actually... read.

I've read your piece, and unfortunately the overall tone sounds like a rant. I'm sure it wasn't your intent, but tone is hard to convey in a purely textual medium sometimes. I fall victim to this often, and have been actively working to try to avoid excessively negative tone (even if I feel that way).

The ranty tone of the piece obscures the rest of the points you were trying to make - many are good, but a strong tone will immediately put people on the defensive rather than trying to open up and understand what's being said.

Re: Problems I Have with Python

#156
post #61

This is a tired, trolling post. Most of these issues have long been addressed as non-problems or personal preferences; when the author says "Incompetence? Politics?" what I hear is "people don't listen to me, probably because I don't know what I'm talking about". The attitude is confirmed by his/her conflating of stdlib gripes and language gripes - two very different sets of problems - and mixing requests for speed w…

you seem confused. Please explain how lambda and performance are "notoriously" unlikely to go hand-in-hand. They're orthogonal, yes. "Notorious"..what does that actually mean?

Also I will disagree that stdlib and core are "very different problems". Exhibit A: Go delivers stdlib and core language together, hand-and-glove style, with out-of-the-box huge functionality. It's one reason why it's killing Python. Stdlib is a key part of language functionality and is intricately linked to uptake. Just ask Ocaml.

Re: Problems I Have with Python

#157

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

No! Never do this in Python.

You are making the flattened list by continually concatenating the smaller lists. Each concatenation creates the new bigger list from scratch; the flattened list does not grow dynamically. This is quadratic-performance bad.

Use `list(itertools.chain.from_iterable(...))` instead.

Re: Problems I Have with Python

#158

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…

Naively compiled C/C++ is fairly easy to reverse engineer (I say this from a lot of experience!).

If you want to "protect your source code" you need to apply obfuscation techniques to slow down a reverse engineer - but keep in mind that everything ultimately can be reversed and understood given enough time. Plus, many obfuscation techniques can be made applicable to Python code too (e.g. encrypting, obfuscating or mangling Python bytecodes).

The real question is: what are you protecting that is so secret? If it's details about a protocol (network messages, file format or external API calls) those are fairly easy to dissect externally. If it's a proprietary algorithm, someone could blackbox the relevant parts of your code to use in their own application, without even reversing it. If it's proprietary data, client-held keys, etc. there are ways to get at it. Assume that everything you hand a client is no longer secure or private - if you really need to keep secret sauce close to home, make it server-side.

Re: Problems I Have with Python

#159
post #100
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)

Which one? PHP? Perl? Bash? Scheme? VBScript? Windows PowerShell?

Python is in fact of the fastest scripting languages that exist, especially JIT'ed.

The notable exception is JS, and oh, that has a GIL too :P

Re: Problems I Have with Python

#160
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? That's actually one of my bigger beefs with Python: it forces a large naming burden on the programmer. When writing python code I find myself struggling to name intermediate results or stupid functions that should just be lambdas. Very very often those results don't warrant a name, or are unnameable. Also, naming something implies it…

> Also, naming something implies it will be useful in another context, which one-off lambdas rarely are.

Not necessarily. I find it helps readability to do this:

  def prunde_indices(indices, cutoff):
    def match_old_index(index):
      return index.timestamp 
as opposed to using an anonymous lambda. That doesn't mean I have to reuse it outside of this function.
Post reply on HN