>I've standardized on this version of Python because it has a new improved string formatting system that is easier to use than the previous 4 (or 3, I forget, there were many)
Wait, is this seriously the only advantage you see to Python 3, Zed?
Wait, is this seriously the only advantage you see to Python 3, Zed?
Strings are ubiquitous to programming. I'd argue that it's even more for first time programmers. Zed wanted something that would be easy to use.
(ASCII) Strings formatting is more important to beginners than unicode support, new style classes by default, iterators in range()/enumerate()/etc. , the new division operator, etc.
I haven't recommended his book to beginners because it was stuck in Python 2. But I have to agree that Python 2 had some stuff that was more "newbie-friendly" than Python 3
> But I have to agree that Python 2 had some stuff that was more "newbie-friendly" than Python 3
Also I suspect that a huge proportion of newcomer's got very confused as to why 3/2 == 1.
Of the top of my head come the range/enumerate/zip returns. They are really useful and needed to teach "pythonic Python". But it's hard to explain that it doesn't return a list. "It returns an iterator, that is lazy, and you need to call 'list()' on it to use it as a list..." You get my point.
You fall to a "just do like I told you. You'll get it later." that plagues a lot of other languages when being taught to newbies.
But I never said that Python 3 is less "newbie-friendly" than Python 2...
The explanation is easy, but it isn't simple.
With respect, "It always rounds down" is a terrible explanation. It explains the apparent behavior of the / operated in Python 2, but it does not really explain why. A better explanation is that the Python is both dynamically- and strongly-typed and that / does integer division on integers and "true" division on floats. For the newbie who understands these concepts, this is a far more useful explanation and metaphor; and for the newbie who doesn't, he has to learn somewhere, and frankly the / operator is not a bad example.
Floats don't really get true division either:
https://docs.python.org/3/tutorial/floatingpoint.html
And as it happens, I once explained a related problem with round() to Zed Shaw on Twitter:
(and from playing around with Perl 6, I love how decimal literals are of type Rat instead of Num; I wish Python decided to do something similar in Python 3)
Edit in response to Zed's question, in 3.6 I always just do:
print(f'{foo:.2f}')
For purposes of teaching the language to a beginner, he wants literals being rounded or divided to "just work" in a way that is unsurprising to those beginners, and there isn't any way to achieve that unless the default type of a number with a decimal point is Decimal rather than float (which isn't at all likely to happen).
The closest we are likely to get to that ideal is by introducing a Decimal literal like 0d2.125, riffing off the Hex and Octal literals (eg. 0xDEADB33F, 0o76510).
P.S., unless I am mistaken, you're just truncating the float, not actually rounding it
And I understand that it is hard for some to jump back to a newbie perspective. Some people look for performance in a programming language. Others for a thriving ecosystem. I look for usability and elegance. So I tend to look at programming languages that way.
>>> range(10)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> range(10)
range(0, 10)
I love iterators, but they're not an obvious concept at first.
print thing # Works in Python 2
print(thing) # the parenthesis are optional in Python 2
print(thing) # the parenthesis are required in Python 3
If you try to do something like "print(thing1, thing2)" in Python 2, you'll find that "(thing1, thing2)" is interpreted as a tuple, so Python prints it as a tuple (instead of printing thing1 and thing2 individually).
Unless any fork actually gains traction, Python 3 will be Python in 2020.
I've been writing Python for over a decade, I dragged my heels on Python 3 for a long time, and as soon as PEP 498 came out, I decided then and there that all new personal projects I start will use Python 3, and I'll try to use 3 if I can in new work projects.
Not only that, but I've fallen for f-strings so hard that all my newer personal projects specifically require 3.6.
Their unicode implementation is sub optimal at best, it doesn't need to be so complex. They need to go back to the simplicity of Python2's strings but modernize it. Make everything a bytestring and assume the encoding is UTF8. That's what everyone else is standardizing on.