> Currently you cannot run Python 2 inside the Python 3 virtual machine. Since I cannot, that means Python 3 is not Turing Complete and should not be used by anyone. I stopped there.
The Case Against Python 3
161–170 of 281 posts
Re: The Case Against Python 3
#162Earlier quoted context omitted.
Naw, `zip` is a builtin in py2. You might be thinking of `itertools.izip`? https://repl.it/E5v6/2
zip in py2 returns a tuple type (i.e tries to consumes the iterator through a StopIteration) in py3 it returns a iterator (consumes it on demand). Try this in py2: https://repl.it/E5vd/0
Re: The Case Against Python 3
#163This has to be the ne plus ultra of Python scaremongering. It describes some sort of bizzaro world of a doomed language which it populates with Machiavellian Python maintainers, brainwashed developers, and a small group of heroic holdouts who see resisting Python 3 as a moral imperative. Apparently having too many string formatting options is a moral issue (three, to be specific). As someone who writes a _lot_ of Pyt…
I feel like I'm the only one who learned Python from the official site's tutorial page: https://docs.python.org/3/tutorial/index.html I found it really helpful.
I'm only starting to realize, as I branch in to other things, that this might not be the norm.
Re: The Case Against Python 3
#164Anyone here remember "Rails is a Ghetto"? http://web.archive.org/web/20080103072111/http://www.zedshaw... Zed's Rails article did lead to some improvements in the Ruby community (eg: The 'pickaxe' had meta-programming added to the next version). Zed likes to stir things up, but rather than dismiss him completely over some nit picky issues, eat the meat and spit out the bones. To the "I stopped there" folks in this th…
Since those tools are in place, pretty much every major Python lib has Python3 support. Many minor libs as well, though it's easy to have one or two dependencies missing it if your project is big enough.
Application developers (overwhelming majority of Python users) had to wait for the libraries to get over to Python 3. This has basically happened, so a lot of application developers are now porting.
Python 3's rollout was awfully managed, but the community has learned its lesson, and is working hard to fix things.
----
Another issue with this article is that its recommendations simply won't work.
- If you try to make "text + bytes" work, you are letting people write code that will fail. You can't implicitly convert bytes to text. You have to know the encoding! Python 2's mechanism (system locale-implicit conversion) guarantees bugs in situations with multiple encodings floating about.
- Running Python 2 libs in Python 3 would mean that "text + bytes" style failures in the Python 2 code would bubble into Python 3, destroying all assurances you're supposed to have in Python 3.
Re: The Case Against Python 3
#165For example, you can write a program in the latest dialect of Free Pascal that includes a unit written in a 30 year old Turbo Pascal dialect and another unit written in a late-90s Delphi dialect. Even Javascript has `"use strict";` and PHP has `declare(strict_types=1);`. Python's solution was instead to say "Just go rewrite all the code you've ever written."
That said, claiming that the language isn't Turing complete because it doesn't include switches for compatibility is a bit of a stretch.
Re: The Case Against Python 3
#166Re: The Case Against Python 3
#167Earlier quoted context omitted.
A language must change, or it will be left behind, and become an esoteric toy. Even C has to deal with this. The only reason C is still popular is because of it's grandfathered status in so much of our infrastructure, and in many of the popular OS choices. A language that changes will alienate people, and lose people. Perl saw this. Python is seeing this. The way to guard against this is to keep backwards compatibili…
Even C has to deal with this. But is there any C11 compiler out there that will refuse to compile C99?
It is cheap to deal with the ambiguity in the compiler using compile options. You could go the Java way and have separate class path (e.g. In PyPy, as CPython 2.x is dead).
But this does not allow you to mix and match code for older version anyway. Java was designed from start to allow this and it is why it's so stagnant.
Re: The Case Against Python 3
#168The argument is bad but the headline has a point: the value of a language is the quality of its libraries and the community that maintains it. Python 3 seems like a mistake; it fractured the community and sent people away. (to golang, to scala, probably even to ruby). If I were a library maintainer on py2 I would have felt betrayed by py3. Suddenly print is a function? 'yield from' won't be available on the py2 branc…
> Let's hope python can be saved. Can you explain why Python would need to be saved? I mean every week on r/MachineLearning there is at least one new Python deep learning framework being launched[1], I wonder if you can mention any other language which is that healthy. [1] https://www.reddit.com/r/MachineLearning/search?sort=new&res...
Re: The Case Against Python 3
#169Earlier quoted context omitted.
> Let's hope python can be saved. Can you explain why Python would need to be saved? I mean every week on r/MachineLearning there is at least one new Python deep learning framework being launched[1], I wonder if you can mention any other language which is that healthy. [1] https://www.reddit.com/r/MachineLearning/search?sort=new&res...
All stable versions of the big ML frameworks are still 2.7.
About the only thing that is dead like that seems to be Enthought project for drawing and creating UI for graphs.
Re: The Case Against Python 3
#170Earlier quoted context omitted.
> Suddenly print is a function? from __future__ import print_function Now you've got print function in python2. > 'yield from' won't be available on the py2 branch? And 2.6 doesn't get set literals. And 2.5 doesn't get "with" statements. And ... There's got to be a cutoff somewhere. Or we'd just have an eternal 1.0 with all the features backported to it.
Well no. The problem is that py3 breaks backwards compatibility, without really a good reason. What's so much better about it? Why couldn't they sort py2 at least for module imports? Which is exactly opposite for c++11 - it doesn't break backwards compatibility, but I really want those new features. I think if it broke backwards compatibility, I'd still switch to the new c++. At work we use py2 and c++11...