391–400 of 463 posts
Reminds me of the (old I guess?) ShedSkin project to automatically translate Python to C++. I suppose the easy concurrency and ability to inter-operate with Go libraries is really the driver for Go over that.
Earlier quoted context omitted.
So is it just a time issue, or are there compatibility reasons for why not all of you code is Python 3? I ask because I started to learn to code with Python 2 because that's what was preloaded on my system. Is one over the other a big enough deal at a beginner level that I should switch to 3 now? How much of a learning curve am I in for?
what system is that? a mac? If so , the sadly you do have to get py3 yourself. If a Linux distro, then you likely already have python 3 preinstalled. `/usr/bin/python` won't point to python3 in anytime in the near future.
- Amusingly, it runs Python 2.7, even though this project started long after Python 3.x came out. - It's a hard-code compiler, not an interpreter written in Go. That implies some restrictions, but the documentation doesn't say much about what they are. PyPy jumps through hoops to make all of Python's self modification at run-time features work, complicating PyPy enormously. Nobody uses that stuff in production code,…
It's written to run Python 2.7 because these problems are largely solved in Python 3, and needs solved for people on Python 2.x versions. "Upgrade to Python3" is the usual defense to that, but it's not really practical for large companies with software such as YouTube completely written in Python 2.x.
I can't help but see this balkanization of Python as a sign that the core language is falling apart. How many interpreters are there now? And how many of them have even close to 100% compatibility with Python 2.7 or 3.N? Guido has lost control of the language, but has he's still officially the BDFL there's no real standardization body. His stubborn view on functional mechanisms have held the language back syntactical…
GVR, the PSF and the core dev team overestimated their influence. They still truly believe the majority will come around to Python3. I agree with your sentiments and balkanization is the right word. Guido won't even read these comments. He thinks it's all some unjust slander and nonsense that will be forgotten in 3 years. :) It is a good time to jump off the Python train in general, and I say that as someone invested…
Earlier quoted context omitted.
> As if individual developers are the reason behind the bulk of the downloads. I wonder how many downloads Travis alone counts for? Travis runs/tests user projects, so there's nothing about it that's especially partial to Python 2 over Python 3. > Your hate of Python 3 in every discussion about it is frankly baffling. Or, you know, my pragmatic assessment of its popularity. That you'd even use the word "hate" (when i…
> even if its mostly tame updates over what 2.7 offers > The situation is not unlike the perennial "next year is when Linux dominates the desktop", which has been every year since 1999. Your bias is showing, as it does in every comment section on this site regarding Python 3, as you make comment after comment about how inferior Python 3 is and how nobody is using it at all because your sample of 2 companies shows thi…
>as you make comment after comment about how inferior Python 3 is
Actually I've never made any such comment. In fact, tame updates" means that IT IS an update over 2.x, only not that much as it could be. Which most people I've read agree, or at least agreed until the async stuff.
>and how nobody is using it at all because your sample of 2 companies shows this and how it personally hurt your family or whatever.
Notice how I never said that, but actually gave concrete numbers that place those using it in much less (up to 1/8 less) of those who use 2.x?
So why the lie? Less is not the same as "nobody at all", and doesn't fix by itself just because you really really wish more people used 3.
>You don't stop.
Yeah, I continue expressing my opinion and my argumentation. I should stop because you happen not to like it?
Please don't bring "the feelz" into technical and community discussions. It cheapens the argumentation. If anything, it's you who are biased: 80% of your submissions on HN are for Python stories.
One can acknowledge that D is way less popular than Golang or that Perl 6 failed to gain traction over 5, without hating Perl 6. Ditto for Python.
Earlier quoted context omitted.
Uh, what? Claiming that your [1] is in any way a specification for the language is utterly absurd. It's far too vague. (Compare to even an IETF RFC, and you'll see what I mean. If you want to compare to a real language spec, compare to ISO C++.)
CPython is the spec (or really more the CPython test suite). Just like the Ruby MRI. It's a simple, plain interpreter without many frills, and to add or remove a feature you have to submit a PEP which goes through a specification process. Python started as a one-man-band project and of course didn't have a specification.
C started as a one-man-band project and of course does have a specification.
JavaScript started as a one-man-band project and of course does have a specification.
The main reason I moved from coding in Python to Go as my main language many years back is because concurrency was such a pain in standard Python (the other was compile time error checking). It's interesting to see the same pain has now made caused the runtime itself to be implemented in Go. It's a pity C extensions (often used in scientific computing) are not supported but Go does have support via CGO, so maybe some…
I "grew up" on Python, then wrote a whole bunch of Go for my job. Then this past Autumn re-visited Python to implement a networked terminal based game[1]. With what I learned about Go and concurrency, I would say that currently in Python, writing concurrent code is not very hard, and is as close to Go as you can get without actually just writing Go. Now, you may be saying "but Python has the GIL, how can concurrency…
I wonder why the Grumpy Fibonacci is so much slower than CPython for 1 thread. Seems weird given Grumpy is compiled.
Guido insists that single threaded performance of Python has the highest priority - http://www.artima.com/weblogs/viewpost.jsp?thread=214235 I am not sure, any implementation of Python will beat the single threaded performance of Cpython..
Earlier quoted context omitted.
Their python is weird if it doesn't use eval?
or getattr/setattr, or dynamically building classes with type(), or probably more features I can't remember now.
> getattr/setattr, or dynamically building classes with type()
Earlier quoted context omitted.
The GIL is not just for GC; it does coordinate access across threads, albeit at a very low level -- if two threads execute "mylist.append(v)" at the same time, it is the GIL that makes sure it actually works as expected, and from comments above it seems grumpy uses per-object locks for that.
That's not a good characterization of the GIL. It doesn't prevent races or make multithreaded mylist.append safe. It makes sure that mylist.append doesn't cause a segfault as the bytes in RAM are in an inconsistent state during an update. Beyond that, it doesn't really protect you from your bad threaded code.