91–100 of 341 posts
Earlier quoted context omitted.
Since Python 3.5 (3 years ago) type hints are part of the core syntax. Don't need to put them in comments. https://www.python.org/dev/peps/pep-0484/#type-definition-sy...
> a_list = [] # type: List[T] How do you do that with out a comment?
a_list: List[T] = []
Visit https://docs.python.org/3/library/typing.html for more information.
Earlier quoted context omitted.
The double standard when it comes to Python is mindblowing. No other language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time.
Wasn't there a big brouhaha over the change from VB6 to VB.Net? The big difference there is that if it's ordained from your corporate overlords, you have little choice, whereas you feel like you've got a bigger right to complain when it's "just" coming from the BDFL.
Earlier quoted context omitted.
Quite the opposite. Python had deep problems that could simply not be fixed without BC breaks. The decision was made, and in hindsight it was the correct decision by Guido and other core devs. Look at PHP, and look what a total cluster of madness the language has become.
I think Python 3 was not brave enough, to be honest, to future proof Python: * an optional type system without hacks was not introduced (types in comments, really?) * the GIL was not removed or at least a solid parallelism story was not included, one that would allow Python to use all cores on a system while sharing, if needed, memory * no true performance improving changes were made; by this I mean stuff that improv…
From what I saw, Python3 doesn't have type hints but it at least warns when you try to do stuff which involves magic, such as trying to increment a float.
Perl6 doesn't warn in those cases. If you use type inferrence it just happily goes ahead and uses the equivalent of perl5 BigNum which makes the code run 50x slower, instead of upgrading to BigNum when int overflows like Ruby does. If you use ugly C-style loops instead of nicer native for loops, your loop will run 2x faster. Too much magic or the wrong sort of magic can be really annoying sometimes.
Earlier quoted context omitted.
I think Python 3 was not brave enough, to be honest, to future proof Python: * an optional type system without hacks was not introduced (types in comments, really?) * the GIL was not removed or at least a solid parallelism story was not included, one that would allow Python to use all cores on a system while sharing, if needed, memory * no true performance improving changes were made; by this I mean stuff that improv…
Since Python 3.5 (3 years ago) type hints are part of the core syntax. Don't need to put them in comments. https://www.python.org/dev/peps/pep-0484/#type-definition-sy...
vec = [] # type: Vector[float]
vec = [] # type: Iterable[Tuple[float, float]]
a = MyClass() # type: MyClass[int]
x = Foo() # type: Foo[int]
This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years ago.
I often see this but I think it's a perception from the Internet/web world.
I work for CGI, all (I'm not kidding) our softwares (we have many) are 2.7. You will never see them used "on the web/Internet/forum/network" place but the day-to-day job of millions of peoples in the industry is 2.7.
And we are a tiny focused industry. So I'm sure there is many other industries like us which are 2.7 that you will never heard of.
That's why "most popular" mean nothing once you take how Python is use as a whole. We don't use any of this web/Internet/network "popular" packages.
I'm not saying Python shouldn't move on. I'm just trying to argue against this "most popular packages" while millions of us, even if you don't know it, us none of those.
This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years ago.
Earlier quoted context omitted.
The double standard when it comes to Python is mindblowing. No other language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time.
Wasn't there a big brouhaha over the change from VB6 to VB.Net? The big difference there is that if it's ordained from your corporate overlords, you have little choice, whereas you feel like you've got a bigger right to complain when it's "just" coming from the BDFL.
This is good: - Python 2 support officially ends somewhere in 2020 - most popular packages are now compatible with Python 3 - Python 3.7 performs about as well as 2.7 with future release expected to be better Although it still took way too long, if you consider Python 3.0 was released about 10 years ago.
Somehow, it was the plan[0]. I feel like I wrote about that extensively already way too many times[1].
[0]: (2016) https://news.ycombinator.com/item?id=11502844
[1]: (2012) https://news.ycombinator.com/item?id=4569440
Earlier quoted context omitted.
The double standard when it comes to Python is mindblowing. No other language could have gotten away with such ridiculous fragmentation and perf regression for such a long period of time.
I think it's the opposite. When other languages make incompatible changes, they have serious problems (e.g perl6). Previous versions of python were back-compatible. Java versions stress back-compatibility. I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Python has done everything possible to avoid this fate, by maintaining 2.7. And I'm not e…
Swift breaks every major version at least but not as often and on a large scale anymore with point releases as with 1.x and 2.x. Has been like that from the beginning and everybody that writes it accepted it.
Earlier quoted context omitted.
Wasn't there a big brouhaha over the change from VB6 to VB.Net? The big difference there is that if it's ordained from your corporate overlords, you have little choice, whereas you feel like you've got a bigger right to complain when it's "just" coming from the BDFL.
As VB6 is compiled, you don't need your users to have a particular interpreter version installed.