>>918457
>It still doesn't have proper unicode support, we still need ICU bindings. The limited unicode support it has works just as well in python 2.7.
Consistently using unicode strings for text without mixing it up with raw bytes is an improvement over Python 2.
>>type hinting syntax
>Have you tried using it? Try it before you say it's a feature. It's like C++'s template concepts. I don't expect anyone to ever seriously use it.
I do use it. It works great with mypy.
>>formatting string literals
>Backported to 2.7.
No. I'm talking about formatting literals, like f"{x}", not "{}".format(x).
>>dataclasses
>It's a pure python decorator and can be used on 2.7. Many projects, especially web frameworks, already had their own variant in 2.7.
Python 3.7 has it in the standard library, so it's reliably available from there on, and versions before 3.6 can't support a version as nice as that one. It lets you do something as simple as this:
@dataclass
class C:
x: int
y: str
z: bool = False
o = C(3, 'foo')
print(o)
C(x=3, y='foo', z=False)
It has simple syntax for simple uses and it's standard. That matters.
>>lazy operation of standard functions and methods where applicable
>3 remains slow as fuck.
It's not just about naive speed. Being able to do "x in d.values()" without instantiating an entire list matters a lot in case d is a large dict. In Python 2 you'd have to choose between doing it the simple clear way or the correct way, in Python 3 they're the same way.
>>sensible division semantics
>Their division semantics are madness. How does quietly switching types to turn an infinite precision integer into a limited precision float make any sense? Division was consistent in python 2.7 and they fucked it up.
>x=222222222222222222222222222222222222222
>x/2*2
>2.222222222222222e+38
>Try to justify that shit as more natural and sensible than python 2.7. Silent information loss converting between infinite and finite, oh yeah, that's so much better than when it used to just fucking work. And why if they have transparently infinite precision integers do they not use their transparently infinite precision floats? It's such a confused mess. You have to be a sycophant or a moron to say this is sensible.
It's sensible in a language with dynamic typing.
When you actually use division you usually have a clear idea of whether you want truncating division or true division, and the types involved are only known at runtime. So in Python 2 you either end up with subtle bugs that happen when you get an int where you were expecting a float or vice versa, or you have to put float or int conversions all over the place just to make sure it doesn't accidentally use the wrong kind of division sometimes. Python 3 is much better in most cases.
Your example loses information in Python 2 if it's an odd integer.
>>asynchronous functions
>There are numerous libraries for 2.7 that asyncio was based on that go back a decade. It's not a new feature.
Standardization and syntax matter.