Pyston — a new Python 2.7 implementation
At a high level, Pyston takes parsed Python code and transforms it to the LLVM intermediate representation (IR). The IR is then run through the LLVM optimizer and passed off to the LLVM JIT engine, resulting in executable machine code. LLVM contains a large number of optimization passes and mechanisms for easily adding more, which can lead to very fast code. The problem, though, is that LLVM can’t reason about Python code, because all the low-level behavior is hidden behind the type dispatching you have to do in any dynamic language. To handle this, Pyston employs type speculation: it is typically impossible to prove that a variable will have a specific type, but Pyston can often predict with some certainty what the type of an object can be. Once a prediction is made, Pyston will verify the prediction at runtime, branching between a fast path where the prediction holds, and a slow path where it doesn’t." The code is said to be in an early state at this point. Note that Python creator Guido van Rossum works at Dropbox, though it's not clear whether he is working on this project.
Posted Apr 4, 2014 12:08 UTC (Fri)
by HelloWorld (guest, #56129)
[Link] (15 responses)
Posted Apr 4, 2014 12:46 UTC (Fri)
by cglass (guest, #52152)
[Link] (14 responses)
I can't say I see what is "lame" here, except knee-jerk reactions about it not being python 3.
Posted Apr 4, 2014 15:13 UTC (Fri)
by david.a.wheeler (subscriber, #72896)
[Link] (13 responses)
The entire Python 3 transition was badly botched. What *SHOULD* have happened was that a *SINGLE* implementation should have supported both Python 2 and 3, as has always been true before. As it is, Python 3 requires a flag day transition, which has ALWAYS been a tremendously difficult and high-risk approach to transition. I like Python 3, but Python 3 just doesn't have enough advantages to justify the pain.
Maybe someday most Python programs will be written in Python 3. Today is not that day.
Posted Apr 4, 2014 16:32 UTC (Fri)
by stonebig (guest, #96410)
[Link] (6 responses)
In education, there is no question the python3 is the way to go, if we want to use our not-always-english spelling in our programs.
I even know at least one american (technical) leader that is in favor of python3 transition now :
Posted Apr 4, 2014 17:19 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Posted Apr 4, 2014 22:15 UTC (Fri)
by juliank (guest, #45896)
[Link] (4 responses)
You cannot use them in your code without a special encoding header.
Automatic unicode <-> str conversion uses ascii by default, forcing you to do crazy stuff.
and more.
Posted Apr 4, 2014 22:20 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
How would Python guess that when I write: "Ýòî òåñòîâûé èäåíòèôèêàòîð" I actually mean: "Это тестовый идентификатор"?
Posted Apr 5, 2014 0:51 UTC (Sat)
by bluss (guest, #47454)
[Link]
Also you said /identifiers/. Py 3 allows unicode identifiers: meaning variable names! For example α = 1; β = 2; is accepted.
Posted Apr 4, 2014 22:23 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
It's not clear to me that that's a problem per se. Especially if it's a header that can be conveniently embedded in one's new-file boilerplate.
Posted Apr 6, 2014 9:20 UTC (Sun)
by job (guest, #670)
[Link]
While the new Unicode handling may look good on paper it completely breaks down in practice. Read what Armin Ronacher wrote on the subject in his blog if you haven't already, he understands the issues involved much better than I do.
Posted Apr 4, 2014 17:22 UTC (Fri)
by bluss (guest, #47454)
[Link] (5 responses)
Posted Apr 4, 2014 17:33 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
Posted Apr 5, 2014 11:44 UTC (Sat)
by pboddie (guest, #50784)
[Link] (2 responses)
Or as someone who doesn't necessarily regard themselves as a Python expert put it recently, "Why did they have to make Python 3 incompatible with Python 2?" I guess we're still waiting for the answer to that question.
Posted Apr 5, 2014 21:25 UTC (Sat)
by bluss (guest, #47454)
[Link] (1 responses)
Posted Apr 5, 2014 23:54 UTC (Sat)
by pboddie (guest, #50784)
[Link]
Closer to the topic, the other positive thing that seems to have come out of Dropbox recently, although I don't recall any editorial mention of it here, was that Python 2.7 will get some continued security attention in the form of backported "enhancements", with Guido van Rossum actually berating someone who suggested that porting to Python 3 was the only proper way of deploying systems adhering to contemporary security standards and practices, noting that Dropbox certainly can't afford to take that path.
Posted Apr 10, 2014 3:56 UTC (Thu)
by david.a.wheeler (subscriber, #72896)
[Link]
You're ignoring what most people are ACTUALLY doing, which is option 3: Ignore Python 3, and keep using Python 2. After all, that's where all the existing code and libraries are.
Hey, I actually *like* Python3. The problem isn't the destination, it's the overly-difficult transition path to get there. If you could load Python3 and Python2 programs in a single process - and there is *NO* technical reason this cannot be done - then you could transition gradually instead of having a flag day. As it is, you have to convert all libraries and every file simultaneously. That's just rediculous. It is *possible* to do it, but many of us need to actually accomplish things instead.
Posted Apr 4, 2014 14:45 UTC (Fri)
by josh (subscriber, #17465)
[Link]
Posted Apr 4, 2014 15:14 UTC (Fri)
by torquay (guest, #92428)
[Link]
Obviously Pyston is not the same as the often-used PyPy JIT compiler for Python, so a relevant question would be: why should the LLVM-based approach produce code that is comparable to, say, writing inner loops directly in C++ ? Speed mainly matters for heavy number crunching, and we already have nice C++ abstraction libraries such as Armadillo for that (which has Python wrappers).
Posted Apr 4, 2014 18:39 UTC (Fri)
by allesfresser (guest, #216)
[Link]
Posted Apr 4, 2014 21:45 UTC (Fri)
by anatolik (guest, #73797)
[Link] (10 responses)
The situation around Python3 transition is ridiculous. If Python3 is a wrong way, can the upstream say "Sorry, python3 was an Fool's day joke and we are going to close this branch"?
Posted Apr 4, 2014 22:12 UTC (Fri)
by khim (subscriber, #9252)
[Link] (9 responses)
It's the same story as with any other “flag day” upgrades—be it Perl6, PHP6, Python3 or Itanic. If people can not do a peacemeal transition then they usually only switch when they could not continue (e.g. when old thing is no longer available for one reason or another). The more popular the platform is the harder is it to switch—and apparently python is popular enough that transition takes years and may even fail completely. Upstream absolutely believes that python3 is the way of the future, but people… people have different opinions. I've tried to write python2/3 scripts for some time but it was too hard and benefits were unclear thus I've switched back to python2… I'm pretty sure I'm not the only one.
Posted Apr 5, 2014 4:56 UTC (Sat)
by niner (subscriber, #26151)
[Link] (3 responses)
Posted Apr 5, 2014 7:53 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (1 responses)
Posted Apr 5, 2014 9:14 UTC (Sat)
by niner (subscriber, #26151)
[Link]
Posted Apr 5, 2014 18:02 UTC (Sat)
by flussence (guest, #85566)
[Link]
Anything written in Perl 5.18 today will continue to work in 5.20, 5.70 or eventually 6.0, with minimal or no changes. The rug isn't going to be pulled out from under anyone, and it's acceptable (even officially blessed) to totally ignore Perl 6 in preference of 5.
Posted Apr 5, 2014 7:52 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (4 responses)
I never had any problem writing *small* scripts in Python2+3.
Can you elaborate?
Posted Apr 5, 2014 9:38 UTC (Sat)
by khim (subscriber, #9252)
[Link] (3 responses)
It's just tedious. There are many small and subtle differences. For example you can create something (presumably some kind of byte sequence) both in Python2 and Python3 by invoking You must always keep both Python2 and Python3 behavior when you are doing such things. If you are checking with python3 first then your code if often does some weird things in Python3 (Python3 is more logical of the two) and if you are checking with Python2 first then your code often just explodes in python3 and must be fixed. That's slightly easier but why bother? If that's my own script then I can grab and install Python2 interprerer whereever I need it and if it's shared scripts then I need to regularly grab and check all the scripts in the project to make sure they still work with Python3. At some point I've just decided not to care. I could use Python3 for my own scripts and Python2 for shared scripts but why bother? Python2 works fine for both.
Posted Apr 6, 2014 9:33 UTC (Sun)
by job (guest, #670)
[Link]
Is there some utility that helps?
It would be great to be able to include a library that bombs the program if a line of code would not execute with identical result under Python 3, for example.
Posted Apr 6, 2014 17:11 UTC (Sun)
by bluss (guest, #47454)
[Link] (1 responses)
Posted Apr 6, 2014 18:19 UTC (Sun)
by khim (subscriber, #9252)
[Link]
Posted Apr 7, 2014 12:30 UTC (Mon)
by viiru (subscriber, #53129)
[Link]
The point being?
The point being?
Python 2 is Python. Python 3 is not.
Python 2 is Python. Python 3 is not.
I agree It's a little strange that the python3000 was less then kind for the transition user, but python3.3 and + are now ok, and a real pleasure for not-only-english writing people.
https://twitter.com/ellisonbg/status/444863447319080961
Python 2 is Python. Python 3 is not.
Python 2 is Python. Python 3 is not.
Python 2 is Python. Python 3 is not.
Python 2 is Python. Python 3 is not.
Python 2 is Python. Python 3 is not.
You cannot use them in your code without a special encoding header.
Python 2 is Python. Python 3 is not.
Python 2 is Python. Python 3 is not.
Actually, you have no option but to let the community sit around and sulk if they want to, since you have no means of compulsion. You can, of course, take whatever strategy you please (within reason) to persuade them to do otherwise.
Python 2 is Python. Python 3 is not.
Python 2 is Python. Python 3 is not.
Python 2 is Python. Python 3 is not.
Python 2 is Python. Python 3 is not.
Python 2 is Python. Python 3 is not.
Pyston — a new Python 2.7 implementation
Pyston — a new Python 2.7 implementation
Pyston — a new Python 2.7 implementation
Pyston — a new Python 2.7 implementation
Pyston — a new Python 2.7 implementation
Pyston — a new Python 2.7 implementation
Pyston — a new Python 2.7 implementation
> Work is on the way...
Pyston — a new Python 2.7 implementation
Pyston — a new Python 2.7 implementation
Pyston — a new Python 2.7 implementation
Pyston — a new Python 2.7 implementation
bytes([1,2,3]), but then for some strange reason bytes([1,2,3])[2] > 3 in True in Python2 but False in Python3 (guess why?).Pyston — a new Python 2.7 implementation
Pyston — a new Python 2.7 implementation
Unfortunatelly Pyston — a new Python 2.7 implementation
bytearray is mutable which means that you can not use it as key. You can do something like bytes(bytearray([1,2,3])) which works but is ugly and means that programming starts to look more like puzzle solving and less like programming. I basically feel like I'm writing a Polyglot which is extremely irritating. I feel similarly when I need to write some header which must be compileable by C and C++ compilers—but there it's limited to headers, I can decide if I want to compile any file as C or C++ and can change the decision at any time. With python 2+3 you are forced to do that for the whole program. Thanks, but no, thanks.
Pyston — a new Python 2.7 implementation