Most active commenters

    ←back to thread

    2024 points randlet | 20 comments | | HN request time: 3.111s | source | bottom
    Show context
    bla2 ◴[] No.17515883[source]
    > I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions.

    Leading a large open source project must be terrible in this age of constant outrage :-(

    replies(9): >>17515955 #>>17515972 #>>17516193 #>>17516427 #>>17516776 #>>17516884 #>>17517282 #>>17517716 #>>17517821 #
    symmitchry ◴[] No.17515972[source]
    I'm a little confused though, by his feelings here. Why did he feel the need to "fight so hard for a PEP" if it was so controversial, and everyone was outraged?

    I do understand people's points about "the age of outrage" and "internet 2018" but still: the PEP wasn't generally accepted as being a fantastic improvement, so why did he feel the need to fight so hard for it?

    replies(5): >>17516128 #>>17516129 #>>17516223 #>>17516774 #>>17519017 #
    jnwatson ◴[] No.17516128[source]
    It was controversial syntax, inline assignment-as-expression. There's always a tension between "keep it simple stupid" and "let's make it better", especially when a large user demographic of Python are non-professional-programmers.

    Interestingly, C++ is going through the same process, with lots of great ideas being proposed, but the sum total of them being an even more complicated language (on top of what is probably the most complicated language already).

    Python has been successful, IMHO, because Guido has made several brave, controversial calls. Python 3 breakage and async turned out to be prescient, fantastic decisions.

    replies(6): >>17516204 #>>17516226 #>>17516681 #>>17517178 #>>17517212 #>>17533584 #
    1. chimeracoder ◴[] No.17516226[source]
    > Python 3 breakage and async turned out to be prescient, fantastic decisions.

    The jury is still out on the Python 3 decision, to be honest. Heck, Python 2 is still officially supported until 2020.

    Python 3 adoption is increasing, but the instability and breakage that it introduced caused a lot of knock-on effects throughout the Python community that held it back and hindered its adoption and mindshare. It'll take a while before we can really say whether the long-term gains will make up for that.

    replies(4): >>17516673 #>>17516682 #>>17516696 #>>17517423 #
    2. jimmaswell ◴[] No.17516673[source]
    I'll probably never switch for personal use. The print statement change is intolerable to me. It would have cost them nothing to just leave the old syntax in. It's supposed to be a quick and convenient scripting language and they're actively working to make it more verbose and less convenient. I also still don't like not being able to use "string" objects as dumb byte containers, like I do with an IRC bot that doesn't crash with an encoding exception trying to write IRC control characters into a text file. Yes, I know I can work around that wrapping everything up nice and pretty to tell python "this isn't a real string it's okay you don't need to throw an encoding exception ssh." I just don't think that's good design.
    replies(2): >>17516821 #>>17516939 #
    3. cuckcuckspruce ◴[] No.17516682[source]
    Python 3 avoided becoming what Perl 6 has. That alone is a victory.
    replies(1): >>17517296 #
    4. nas ◴[] No.17516696[source]
    > The jury is still out on the Python 3 decision, to be honest.

    It's not. Python 3 has overtaken 2 and there is no stopping migration to it now. Python 3.7 is a lot better than 2.7. Just on memory use alone, 3.7 is massively better. Sure, there will be some hold outs on 2.7 for a long time. That's fine.

    Also, this is not the say that migration from 2 to 3 was handled well. It wasn't. Python 3.0 should have had backwards compatible features like allowing the 'u' string prefix. Indexing byte strings should have returned length one byte strings. Byte strings should have supported at least a minimal amount of %-style formats. Etc.

    That has all been mostly resolved and is in the past. Mistakes were made because, shock, the Python core developers are not perfect and didn't foresee all the migration issues. However, there is no way that we are going back and reviving the Python 2.x branch.

    replies(4): >>17517214 #>>17517416 #>>17518146 #>>17519190 #
    5. keymone ◴[] No.17516821[source]
    Syntax regularity is infinitely more important than scripting convenience.
    replies(1): >>17517415 #
    6. mywittyname ◴[] No.17516939[source]
    Try Ruby.
    replies(1): >>17520093 #
    7. TylerE ◴[] No.17517214[source]
    How much momentum was lost in the transition though? I know that with the pain of 3 at the time a lot of people started looking at languages like Go or even Scala.
    replies(1): >>17519883 #
    8. jandrese ◴[] No.17517296[source]
    Is there even a "production ready" version of Perl 6 yet? It has to be the worst example of production hell for a computer language in history. It's the poster boy for the second system effect.
    replies(1): >>17518382 #
    9. jimmaswell ◴[] No.17517415{3}[source]
    Button regularity on your keyboard is infinitely more important than ergonomics too, right? Anything but a grid of equally-sized squares must be wrong by virtue of aesthetics. Spoken language too: let's eliminate all contractions because they reduce regularity. Let's also make all the speed limits in the country equal at 20mph, because regularity is infinitely more important than convenience.

    You should be supporting return being made into a function too, right? That would be much more regular.

    Reminder that a guideline of python was supposed to be "practicality beats purity" which is in stark contrast to the changes to print and strings. [1] Reminds me of the gradual shift of the message on the wall in Animal Farm from "four legs good, two legs bad" to "four legs good, two legs better."

    1: https://www.python.org/dev/peps/pep-0020/

    replies(1): >>17517602 #
    10. olooney ◴[] No.17517416[source]
    It was touch and go for a couple of years there but yeah, Python 3 is now well and truly over the hump.

    The Python 3 Readiness Project now lists [341](http://py3readiness.org/) of the 360 most common packages as Python 3 compatible.

    Even that's underselling it really. For example it lists BeautifulSoup as not converted, but the link goes to BeautifulSoup 3.2.1. However, BeautifulSoup4 works great on Python 3. And for MySQL there's mysqlclient and several others, and since database packages usually follow PEP 249 pretty closely its very easy to switch. So in reality, rather than 341/360, its more like "everything worth converting has been converted." Or just "everything" for short.

    11. pjmlp ◴[] No.17517423[source]
    Well, many embedded developers will never move beyond C89 unless forced to do so.

    Meanwhile C22 work is ongoing.

    replies(1): >>17519131 #
    12. keymone ◴[] No.17517602{4}[source]
    Are you fingers equally spaced square shape manipulators?

    I don’t support having return at all. Statements that are not expressions are a mistake.

    Syntax irregularities are anti-practical.

    13. mistrial9 ◴[] No.17518146[source]
    false imperative => "Python 3 has overtaken 2 and there is no stopping migration to it now. "

    this shows a superficial, almost entertainment-industry sort of view of a software development lifecycle..

    in the latest Ubuntu Bionic with apps, building right now on a local machine, I see 143 python-xx packages installed and 43 python3-xxx ..

    saavy package authors use import future and six to side-step the whole issue, while core maintainers struggle, and outsiders invoke a mob voice

    Python 2.7 for LTS

    14. lizmat ◴[] No.17518382{3}[source]
    There has been a production ready version of Rakudo Perl 6 (https://perl6.org) since Christmas 2015. It has been on a monthly release cycle for years, and a 3-monthly release cycle for Rakudo Star, the "user" distribution (with some bells and whistles added).

    Cro (https://cro.services) is a set of libraries for building reactive distributed systems. Comma IDE (https://commaide.com) is an IDE for Perl 6, based on the JetBrains IDEA platform, now in (paid) beta.

    If you want to keep up-to-date on Perl 6 development, check out the Perl 6 Weekly (https://p6weekly.wordpress.com).

    15. llukas ◴[] No.17519131[source]
    > Well, many embedded compilers will never move beyond C89 unless vendor is forced to do so.

    FTFY

    replies(1): >>17520842 #
    16. cwyers ◴[] No.17519190[source]
    That's not the point of the person you're responding to. They didn't say that the transition didn't happen. They said it's not yet known if it was worth it. All you're saying is that it happened.
    replies(1): >>17519438 #
    17. nas ◴[] No.17519438{3}[source]
    I'm saying it happened and Python 3 is the language I want to use. If you don't do Python 3, you either keep the error prone str/unicode string model or you dream up some way to evolve to a better model. Would some mythical version of an evolved Python 2.x be better than what we have? I mean, how to argue against that? I haven't seen anyone propose a workable migration plan. Python 3.7 is better than 2.7.15 and better than 'tauthon'.
    18. lenocinor ◴[] No.17519883{3}[source]
    Python currently still 4th at https://www.tiobe.com/tiobe-index/ . As the most popular scripting language on there by some margin, I'd say they're still doing pretty well.
    19. cutler ◴[] No.17520093{3}[source]
    Aw, alright then.
    20. pjmlp ◴[] No.17520842{3}[source]
    Not really, many of those developers do have C99 compilers with partial C11 support at their disposal.

    There are almost no vendors left offering C89 only compilers.