Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3 can revive Python

medium.com

Post reply on HN
Print view View original

211–220 of 242 posts

Re: Python 3 can revive Python

#211

Post by pekk »

adamc wrote: post #163
sergiosgc wrote: post #155

Earlier quoted context omitted.

I thought I was alone. I also stopped trying to convert people to Python 3. It is a much better language. By this point, it should be obvious. After taking it for a test lap, and after cursing at forgetting parenthesis on print for the hundredth time, you get it. Anyone who uses python and, by this time, hasn't taken python 3 for a test run isn't worth my advocacy time.

I don't think it's a question of test runs. For most of us, it's a question of waiting for various libraries to be ported.

How do you know what "most of us" think?

Re: Python 3 can revive Python

#212

Post by keypusher »

pekk wrote: post #5

The idea that people move from Python specifically to Go is one of those chestnuts of conventional wisdom that never receives any kind of backing in actual data. If you think that Python and Go are made for the same tasks then you're really confused.

Here's one particular example of a real company moving a production application from Python to Go:

https://www.spacemonkey.com/blog/posts/go-space-monkey

Re: Python 3 can revive Python

#213

Post by stormbrew »

sergiosgc wrote: post #153
skriticos2 wrote: post #118

Earlier quoted context omitted.

I add that Python is excellent at data representation and transformation. You can easily write some test data and just include it in python, then transform it any way you feel you like to get intelligence out of it. With the standard library you can easily load a CSV file you exported form a data-set and then aggregate and evaluate it with only a few lines of code without much language overhead. Schema-less mixed con…

I don't get why is Go defined as a competitor to Python. Go documentation itself places Go in the systems programming language class. The same class as C or Rust. The language advantages are defined by comparison to C. Heck, it starts by stating it compiles quickly. I know Go is the language of the moment. Fashionable. I assume I take a cautious stance approaching fads, so I may tend to dismiss new stuff rather than…

> I don't get why is Go defined as a competitor to Python.

To me the area where Go excels the most, and where I feel most strongly compelled to use it, is in tooling apps that you expect your users to install on their machines and run from a command line. This has been an area where python and ruby have been pretty common, but they're both a complete pain in the ass to use that way (setting up virtualenv, setting up rvm, pip problems, gem/bundler problems, etc).

For eg. we use vagrant and fabric at my work for server management (vagrant+fabric for dev environments, fabric alone for production servers). One's written in ruby and the other is written in python, and we have to spend a non-trivial amount of time managing their dependencies so they continue to install correctly. If they were go apps we'd just build and install binaries.

This is the area where I think Go is taking up python users, personally.

Re: Python 3 can revive Python

#214

Post by acqq »

pekk wrote: post #209
acqq wrote: post #177

Earlier quoted context omitted.

Go was never a class of C and Rust. Maybe it becomes once, but at the moment I observe it as a kind of server-side Java replacement: by the current design it simply can't be as low level as C and Rust. The main difference with Java is that it compiles to he native code and not bytecode. Still it is dependent on its own special conventions, GC and libraries. The confusion comes from the announcements of the Go team wh…

> the only group who saw possible benefits were programmers that would otherwise use languages like Python but liked extra speed and convenience of a compiled language. To say "the only group" is far from true. Go has a lot of uptake among people who would otherwise use C++ or Java, for example. And yes, actually there is overlap in the audience of Go and the audiences for C or Rust. Go has its own advantages but rea…

I agree, "the only" is wrong wording. Luckily there are more sentences in my reply. And actually there are elements of Go that I like. However my impression of the responses of the compiled-language groups were: C: "oh, it's GC, runtime-lib and its calling conventions dependent," C++ "oh it can't make universal containers" and Java "oh it lacks exceptions." Only the Python people were "oh it's much faster than Python and not much harder." And no, I don't think Go needs exceptions.

Re: Python 3 can revive Python

#215

Post by wtbob »

pekk wrote: post #5

The idea that people move from Python specifically to Go is one of those chestnuts of conventional wisdom that never receives any kind of backing in actual data. If you think that Python and Go are made for the same tasks then you're really confused.

Our team is traditionally a Python team; it's a good fit for the kind of nimble projects we need to take on.

We've spent the last few months writing some of our tools in Go. For our purposes, it is slightly slower to develop in, but we have much more faith in its correctness, and deploying the code is a dream. Also, it's much faster than what we've been useful.

We'll still be doing some Python development, but were it up to me I'd be using Go for everything I ever used Python for.

Re: Python 3 can revive Python

#216

Post by sitkack »

mkesper wrote: post #117
sitkack wrote: post #96

Earlier quoted context omitted.

I don't know why people are leaving Python for Go when they could be using PyPy or Shedskin. There are plenty of ways to be fast using Python.

Visibility probably. Every whiner blogs "I'm leaving Python for Go" but that was the first time I saw https://code.google.com/p/shedskin/ mentioned.

I think Christian derived people have a tendency to seek solutions as an externality. Rather than focus on the root cause of something and transcend it, we destroy and recreate using a different raw material. Hence leaving Python for X and not realizing that the pattern, leaving for , will continually have one in a cycle of stagnating reconstruction.

If Python is slow, we are using it wrong.

Re: Python 3 can revive Python

#217

Post by sitkack »

irahul wrote: post #141
SoftwareMaven wrote: post #57

Earlier quoted context omitted.

other than proper functional programming, maybe, which isn't about to happen in Python If we could just have tail call optimization, I think we could make the rest work (well, maybe better lambdas, too).

> If we could just have tail call optimization, I think we could make the rest work Manually thunk/trampoline it? class trampoline(object): def __init__(self, fn): self.fn = fn def __call__(self, *args, **kwargs): ret = self.fn(*args, **kwargs) while isinstance(ret, thunk): ret = ret() return ret class thunk(object): def __init__(self, fn, *args, **kwargs): self.__dict__.update(fn=fn, args=args, kwargs=kwargs) def __…

Tail calls have already been implemented in Python using a similar technique, http://code.activestate.com/recipes/496691/

Re: Python 3 can revive Python

#218

Post by eevee »

laichzeit0 wrote: post #126
eevee wrote: post #112

Earlier quoted context omitted.

You're either misunderstanding Python 3 or misunderstanding Perl 6. Python 3 was a few breaking changes made to Python 2. Perl 6 was a completely new language, designed from scratch, with little in common with Perl 5 aside from bits of syntax. It still doesn't have a "complete" release, in 14 years. In half that time, we've had a Python 3.0 and four more point releases.

Potato, tomato. It broke backwards compatibility.

Barely. The subset of code that works in both Python 2.6+ and 3.3+ is orders of magnitude greater than the subset of code that works in both Perl 5 and 6.

Re: Python 3 can revive Python

#219

Post by eevee »

VeejayRampay wrote: post #132
eevee wrote: post #115

"Nowadays stuff like proper closures, immutability, a good async story, etc, is considered a necessity by discerning hackers." Python has proper closures; I would hope discerning hackers know the difference between a closure and an anonymous function. asyncio is fantastic. "Remove the GIL." Do you think no one's thought of that before? Remove it how? "Make it speedy." As you note, that's what PyPy is doing, but this…

Regarding speed, my thoughts exactly. I'm a Ruby programmer and I see this being thrown as a weak point of Python/Ruby all the time. I remember the days where Javascript and PHP were supposed to be slow. Now that Facebook/Google/Apple/Mozilla have thrown dozens of millions of dollars in across the board optimizations, they aren't so slow anymore. Not C-fast mind you, but (especially for Javascript), definitely not la…

Yeah, we need to put our money where our mouth is. Frankly I'm amazed how far PyPy has gotten with the few resources it has. Even their toolchain is amazing; other people are starting to use it to build JITs for other languages.

Re: Python 3 can revive Python

#220

Post by sitkack »

chromatic wrote: post #206
jerf wrote: post #159

Earlier quoted context omitted.

It's easy to lose track of this in the torrent of "PyPy Benchmarks Show It Sped Up 2x!!!!" and "Latest Javascript Engine 50% Faster Than The Last One!!!! OMG!! Node!!!!", but in absolute terms, the dynamic language JITs are still quite slow. It's an urban legend that they are anywhere near compiled performance. Except LuaJIT. "Faster Python" is still slow . Unless you're in a tight loop adding numbers together, but I…

Personally, barring any major JIT advances, I'm considering the book closed on the topic of whether JITs can take a dynamic language and make it as fast as C or C++. It's possible to close more of the speed gap, but these JITs have to be able to: * identify and use native primitives (avoid overflow and so forth) * prefer stack allocation over heap (improved escape analysis) * inline memory allocation and freeing and…

JITs are/can be faster than static code. They can make dynamic and data dependent optimizations not possible any other way.
Post reply on HN