18 ms·

Because there's been not enough carrot and too much stick. The only real killer feature of Python3 is the async programming model. Unfortunately, the standard

Because there's been not enough carrot and too much stick. The only real killer feature of Python3 is the async programming model. Unfortunately, the standard library version is numbingly complex. (Curio is far easier to follow, but doesn't appear to have a future.) On the down side, switching to Unicode strings is a major hurdle. It mostly "just works", but when it doesn't, it can be difficult to see what's going on. Probably most programmers don't really understand all of the ins and outs. And on top of that, you get weird bugs like this one, which apparently is simply never going to be fixed. https://github.com/pallets/click/issues/1212 https://github.com/pallets/click/issues/1212

semiotagonal 7y ago
I wonder how many people feel that migrating to Python3 would have been worth doing in the absence of being forced to do so. Dropbox invested three years of work, actually hired Python's creator, and are still not done. What are they getting out of it that they wouldn't have gotten if Python2 simply had been maintained?
- ogre_codes 7y ago
  This is backwards thinking. Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. If someone wanted other than the core Python team wants to step up and maintain Python 2, they are free to do so, it's open source. But failing that, expecting the Python team to support the older/ less functional version of the code indefinitely is unrealistic. Corporate owned languages have even shorter lifecycles for exactly this reason.
  - coldtea 7y ago
    >This is backwards thinking. And the alternative is cargo cult "newer is better". >Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java...
    - sullyj3 7y ago
      Both Java and Javascript are giant messes.
      - coldtea 7y ago
        Java is nothing like a mess, and JS is going from strength to strength.
        voldacar 7y ago
        int max = new Max(10, 5).intValue();
        coldtea 7y ago
        Not sure what's that supposed to be. What's this "Max" class? In any case, that's not some counter-argument, even if it points to a real wart. It's "let me throw a random Java wart, as if it means something, and as if other languages don't have their own warts".
      - jusssi 7y ago
        And yet, somehow, Python manages to be a bigger mess than than both of them combined.
    - bobbylarrybobby 7y ago
      JS and Java can do that because they were designed reasonably well from the start. All they tend to add are more features on top of the solid core language. Python's language was not solid (e.g., strings not unicode by default) so they needed a major overhaul.
      - downerending 7y ago
        Kind of an odd slam, given that Python (and most other widely used languages) predated Unicode. In any case, I think the jury is still out on whether Unicode in the primary string type is a good idea.
  - daveguy 7y ago
    > If someone wanted other than the core Python team wants to step up and maintain Python 2, they are free to do so, it's open source. Only if they name it something completely different from python or py-anything. Guido refuses to allow anyone to just step in to maintain py2. Tauthon is a project that aims to keep compatability with py2 while adding whatever features of py3 that won't break py2 and to have a maintained py2. https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon
  - flukus 7y ago
    > Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. No maintaining 2 versions of python is much cheaper, it's only being done in one place compared to the thousands and thousands of python 2 code bases you'd have to convert. It also only needs bug fixes, there are plenty of people/organisations out there that would be perfectly happy for the language to be unchanging.
    - takeda 7y ago
      That's only true if you ignore all packages on PyPi. It's extremely hard to keep compatibility with Python 2, many authors can't wait to do the support next year, many already dropped.
      - flukus 7y ago
        > That's only true if you ignore all packages on PyPi. Presumably any packages worth maintaining will have far more dependent projects, so it's still far less overall effort. > It's extremely hard to keep compatibility with Python 2 So don't? I don't think most of the people dragging their feet on the upgrade need or even want new features. A stable python 2 branch with bug fixes and security patches would suffice for most and be ideal for many. Over time the bug fixes should trend to zero and there probably aren't a heap of security issues in python projects anyway.
- crustacean 7y ago
  This is such a good point. Take SQL. It has survived because it is well designed, and changes so little and so slowly, and it’s obvious what SQL is and isn’t meant for. Amateur programmers can port SQL queries between database systems semi-painlessly. In the right environment a query can survive with small edits for YEARS. Who wants to break old SQL? Nobody.
  - skybrian 7y ago
    That's something of an illusion. The flaws in SQL often aren't noticed because you usually pick one database vendor and stick with them. There are plenty of differences between vendors, but you don't usually have to support them at the same time, and you don't notice for simple cases. But changing database vendors for a company can be a big deal, as bad as going from Python 2 to 3.
    - just_myles 7y ago
      This is true. But, I think he means syntactically you can make jumps from one dbms to another without much of a fuss. Obviously there are non-language features but, that is not what is being discussed here.
      - wvenable 7y ago
        Dealing with Unicode in SQL has long been a backwards-compatibility nightmare.
        just_myles 7y ago
        In all fairness, dealing with unicode in general has been a pain point for me.
      - setr 7y ago
        That's mostly a result of databases (kinda) converging, SQL being a declarative language and it primarily being a wrapper around relational algebra, with a bunch of flags. And of course, it's a very direct interface to the RDBMS, and you're just migrating between systems that try very hard to have the same interface. As a language however, it's a whole lot of nonsense. Extremely inconsistent syntax, stuffing a trinary logic into a boolean system, a standard that gets extended arbitrarily, and even the tooling ecosystem is a fair bit pathetic (the lack of formatters particularly annoy me; everyone tries to support SQLs generally, and end up missing every extended feature.. if it's not a simple select query/ddl, you're not getting a decent format output) And it most certainly is a whole lot of fuss to migrate unless your database is tiny, or you didn't actually utilize the DB except as a dumb datastore (eg you relied solely on your ORM + indexes); there's a reason no good translator exists, and those that exist only support a very limited subset of any particular SQL variant, despite programming languages having a whole array of transpilers; it's simply not at all a simple language, and the variants only superficially look the same.
- SignalsFromBob 7y ago
  I suspect that someone, or a group of people, will step up to unofficially maintain Python 2 for the foreseeable future. It's clear that there are a lot of people using it that either can't easily migrate or are unwilling to do so for the various reasons already discussed in this thread.
  - takeda 7y ago
    I'm sure that for the right money you can find someone. Don't forget that that person/organization would not only have to maintain python but also all the packages that you will be used.
  - JohnFen 7y ago
    If I encounter Python 2 bugs that matter to me, I can and will fix them myself if needed, and submit or otherwise publish the change. I'm quite certain I'm not the only one.
    - marcus_holmes 7y ago
      Why not just migrate to 3? genuinely curious...
      - JohnFen 7y ago
        Because of the amount of work involved in porting my existing Python code. Python 3 doesn't offer any advantages that matter to me, so that's a lot of effort for little gain.
        marcus_holmes 7y ago
        OK, thanks. Good luck with the bug fixing ;)
        JohnFen 7y ago
        I'm not really worried about bugs, because the code I have works well, and I doubt I'm going to do any serious new Python 2 development.
erokar 7y ago
Python 3 seems like a bit of a missed opportunity. Since they were introducing breaking changes in the first place, why didn't they go bigger? E.g. make the OOP seem less tacked on, immutable data structures, clean up inconsistencies in the standard library?
- chungy 7y ago
  Can you describe how OOP feels tacked on? One of the major changes in Python 3 is that new-style classes are the only style of classes.
  - CoolGuySteve 7y ago
    I myself, speaking for my self and only my self find that, in regards to myself, the redundant self keyword, in my self's opinion, is somewhat selfish and easy for my self to accidentally omit. Self.
    - zabzonk 7y ago
      To be pedantic "self" is not a keyword.
      - WorldMaker 7y ago
        Worse than that not being a keyword, `self` isn't special at all, it's a naming convention that can be freely broken. Python codebases using `this` instead of `self` exist. Codebases that mix the two depending on who wrote which method in a class exist. I believe I saw `it` used once somewhere as the name for that parameter. I'm sure there are codebases with even crazier horrors for first argument names in class methods out there in the depths of corporate machines.
    - timw4mail 7y ago
      My experience with Python is a little lacking, but doesn't the self keyword mean the difference between an instance method, and a static method? Rust does the same thing - with self, it's an instance method, without, it's a static method.
snagglegaggle 7y ago
The main change people cite is the UTF-8 "support" but frankly it seems like far more pomp and circumstance than is necessary. Appropriate code point handling could have been provided and everything left as it was. And when you get rid of that, there's not that much left that is breaking.
- CoolGuySteve 7y ago
  I find the stronger differentiation between bytes and strings leads to a lot of gotchas, like when I forget to encode bytes or pass a string where bytes are expected. I understand why it's the way it is, but when it comes the the typical unixy things I need to do shuffling of files around, tar'ing stuff, etc, it definitely trips me up more than I'd wish.
  - mkesper 7y ago
    You at least notice it's wrong. In Python2 sometimes 'it worked' until it broke and you had to figure out why.
    - snagglegaggle 7y ago
      See, it just broke when UTF-8 was interpreted as ASCII. It's entirely possible to treat bytes as bytes and leave encoding out of it for the vast majority of programs. If you're dealing with text editing and so on, then you know you need to be UTF-8 aware, and the broken programs would still be broken in either language. The visibility of the errors is a minor point, but I think it more appropriate that it be solved by e.g. the windowing toolkit API.
      - stefco_ 7y ago
        > the broken programs would still be broken in either language. You need to slap a decode anyway on reads from subprocesses in python3, and files open in Unicode mode by default. Wouldn't that fix the majority of silly UTF-8 compat bugs? Or am I missing a class of bugs that's not avoided automatically by python3 strings?
hermod 7y ago
With respect to async, I'm partial to trio [0], which is a spiritual successor to curio [1]. The model is similar to Golang in many ways, e.g. communication using channels [2] and cancellation [3] reminiscent of context.WithTimeout, except that in Golang you need to reify the context passing. The author has written some insightful commentary on designing async runtimes [4] and is actively developing the library, so I'm optimistic about its future. There were plans to use it for requests v3 until the fundraiser fiasco [5]. [0] https://github.com/python-trio/trio https://github.com/python-trio/trio [1] https://vorpus.org/blog/announcing-trio/ https://vorpus.org/blog/announcing-trio/ [2] https://trio.readthedocs.io/en/stable/reference-core.html#using-channels-to-pass-values-between-tasks https://trio.readthedocs.io/en/stable/reference-core.html#us... [3] https://trio.readthedocs.io/en/latest/reference-core.html#cancellation-and-timeouts https://trio.readthedocs.io/en/latest/reference-core.html#ca... [4] https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... [5] https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet...
- privateSFacct 7y ago
  I was curious about [5] The link to support requests (which is a great piece of software) is here: https://cash.app/$KennethReitz https://cash.app/$KennethReitz Note: This is NOT a charitable donation, it is a gift to an individual. These are not tax deductible under US law. Njs has a long attacking blog post saying this needs to go through PSF (huh?) and that they should be getting most of this money not the person the funds were directed towards (it's not clear how much they've actually contributed to requests over time). This supposedly also may trigger folks who have also suffered from "gaslighting". Supporting the developer of a piece of software does not, as far as I know, require that they sign up to handle it on a charitable basis. A big todo is made about the "large" amount raised. The amounts is 33K. To be frank, this is almost zero in tech land at least in the bay area and requests is a very highly used project. I was literally expecting something like 300K or even $1M - silly kickstarter projects raise for more and deliver nothing. Requests has already delivered a lot of utility. Just a bit of perspective from someone who wasn't familiar with this "fiasco".
mxcrossb 7y ago
On the topic of not enough carrot, I’m curious how impactful the end of support for python2 will be. How many programs stuck in python2 are encountering bugs in the runtime?
- carapace 7y ago
  I actually find this aspect of the whole thing exciting, perhaps paradoxically. Now that Python 2 is static the runtime can become asymptotically bug-free. Meaning that, if you only change it to fix bugs (as opposed to introducing new syntax|semantics) it's going to approach perfection.
  - joshuamorton 7y ago
    Who will do that though?
    - carapace 7y ago
      I'm making it a hobby, at least: https://lists.sr.ht/~sforman/bladders-announce/%3C20190911164635.92CC6C06F5%40smtp.hushmail.com%3E https://lists.sr.ht/~sforman/bladders-announce/%3C2019091116...
    - downerending 7y ago
      I've considered taking it on. If there were enough money in it, I'd very seriously consider it. It's a very good language.
      - arbie 7y ago
        In ten years, there will be serious money in it as enterprise codebases need to be renewed.
  - d0mine 7y ago
    You are assuming that fixing bugs introduces less new bugs.
- 7y ago
dividuum 7y ago
> The only real killer feature of Python3 is the async programming model. I understand that this is one of the major features, but I personally never saw the appeal, given that gevent exists and in my experience works well most of the time. It also allows me to multiplex IO operations and doesn't rely on new syntax. I'm probably missing something?
- d0mine 7y ago
  In gevent, any call may behave like an implicit "goto". Here's why "goto" is bad https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... (the link is stolen from @hermod's comment above)
  - jlokier 7y ago
    I think the nursery construct described in that link looks a lot like par blocks in Occam, Handel-C and XMOS XC.
- Scramblejams 7y ago
  I find it much easier to reason about my async Python code when the async yield points are explicit. If every line can potentially yield to another async task, I find myself thinking long and hard about a lot of those lines.
x0x0 7y ago
And the side-effect of an endless trail of shit to deal with. I write primarily ML code so until 3.5 or 3.6 python 3 offered me almost nothing better. It did, however, make managing environments even more of a mess. I quite frankly resented having to deal with code in both, swapping back and forth between python2, python3, pip2, pip3, etc.
epx 7y ago
For me the major gain in Py3 is exactly the sane handling of strings, that fixes the major flaw of Py2: weaking the String type to make the migration to UnicodeStrings "easy".
oarabbus_ 7y ago
I ran into an issue recently specific to Pandas and python3 with unicode. pd.read_excel(filepath) will read an entire dataset even if it contains unicode characters. pd.ExcelFile() silently drops(!!) unicode rows. The resulting object will simply skip unicode-containing rows (in ANY column) them without even a warning. For example, if you had an excel file: word --- "hello" "hello" 你早你早 "hello" then pd.read_excel() would give you a dataframe with 5 rows. ExcelFile() on the other hand would return (silently!) a dataframe with only the first two and the last row. Maybe this is a pandas issue, not a python issue, but it was really horrendous to debug for such a long time only to realize this was the issue.
- j88439h84 7y ago
  Is there an issue for this in the bug tracker?
  - oarabbus_ 7y ago
    I searched, and this is the closest thing (https://github.com/pandas-dev/pandas/issues/11503 https://github.com/pandas-dev/pandas/issues/11503) but it is not the issue I experienced. I'm not sure how to submit a bug report, to be honest.
meowface 7y ago
It's funny, because I consider asyncio (and derivatives like curio) to be the worst part of Python 3. There are plenty of other compelling reasons to move over. No, none of them revolutionize the language, but there are fewer warts and cleaner ways of doing many things.
rtpg 7y ago
- format strings - mandatory keyword arguments - multi-dict splatting - nicer yield semantics for generators - Fixing system-specific encoding ambiguities - dataclasses - inline type annotations - better metaclass support - more introspection tooling - pathlib (for nicer path handling) - mocking pulled into the standard library in a cleaner way - stable ABIs for extensions - secrets handling - ellipsis instead of pass (yeah who cares but I care) - lots of standard lib API cleanup All of this is very helpful for making clean applications. But I would say it's _very_ helpful for making good libraries as well. This stuff is about having a strong language foundation to avoid plain weirdness like the click issue . Obviously it doesn't kill all of them, but there used to be even more of that kind of thing all the time. Library issues would basically get exported to its users, all basically due to language problems.

semiotagonal 7y ago

I wonder how many people feel that migrating to Python3 would have been worth doing in the absence of being forced to do so. Dropbox invested three years of work, actually hired Python's creator, and are still not done. What are they getting out of it that they wouldn't have gotten if Python2 simply had been maintained?

ogre_codes 7y ago
This is backwards thinking. Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. If someone wanted other than the core Python team wants to step up and maintain Python 2, they are free to do so, it's open source. But failing that, expecting the Python team to support the older/ less functional version of the code indefinitely is unrealistic. Corporate owned languages have even shorter lifecycles for exactly this reason.
- coldtea 7y ago
  >This is backwards thinking. And the alternative is cargo cult "newer is better". >Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java...
  - sullyj3 7y ago
    Both Java and Javascript are giant messes.
    - coldtea 7y ago
      Java is nothing like a mess, and JS is going from strength to strength.
      - voldacar 7y ago
        int max = new Max(10, 5).intValue();
        coldtea 7y ago
        Not sure what's that supposed to be. What's this "Max" class? In any case, that's not some counter-argument, even if it points to a real wart. It's "let me throw a random Java wart, as if it means something, and as if other languages don't have their own warts".
    - jusssi 7y ago
      And yet, somehow, Python manages to be a bigger mess than than both of them combined.
  - bobbylarrybobby 7y ago
    JS and Java can do that because they were designed reasonably well from the start. All they tend to add are more features on top of the solid core language. Python's language was not solid (e.g., strings not unicode by default) so they needed a major overhaul.
    - downerending 7y ago
      Kind of an odd slam, given that Python (and most other widely used languages) predated Unicode. In any case, I think the jury is still out on whether Unicode in the primary string type is a good idea.
- daveguy 7y ago
  > If someone wanted other than the core Python team wants to step up and maintain Python 2, they are free to do so, it's open source. Only if they name it something completely different from python or py-anything. Guido refuses to allow anyone to just step in to maintain py2. Tauthon is a project that aims to keep compatability with py2 while adding whatever features of py3 that won't break py2 and to have a maintained py2. https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon
- flukus 7y ago
  > Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. No maintaining 2 versions of python is much cheaper, it's only being done in one place compared to the thousands and thousands of python 2 code bases you'd have to convert. It also only needs bug fixes, there are plenty of people/organisations out there that would be perfectly happy for the language to be unchanging.
  - takeda 7y ago
    That's only true if you ignore all packages on PyPi. It's extremely hard to keep compatibility with Python 2, many authors can't wait to do the support next year, many already dropped.
    - flukus 7y ago
      > That's only true if you ignore all packages on PyPi. Presumably any packages worth maintaining will have far more dependent projects, so it's still far less overall effort. > It's extremely hard to keep compatibility with Python 2 So don't? I don't think most of the people dragging their feet on the upgrade need or even want new features. A stable python 2 branch with bug fixes and security patches would suffice for most and be ideal for many. Over time the bug fixes should trend to zero and there probably aren't a heap of security issues in python projects anyway.
crustacean 7y ago
This is such a good point. Take SQL. It has survived because it is well designed, and changes so little and so slowly, and it’s obvious what SQL is and isn’t meant for. Amateur programmers can port SQL queries between database systems semi-painlessly. In the right environment a query can survive with small edits for YEARS. Who wants to break old SQL? Nobody.
- skybrian 7y ago
  That's something of an illusion. The flaws in SQL often aren't noticed because you usually pick one database vendor and stick with them. There are plenty of differences between vendors, but you don't usually have to support them at the same time, and you don't notice for simple cases. But changing database vendors for a company can be a big deal, as bad as going from Python 2 to 3.
  - just_myles 7y ago
    This is true. But, I think he means syntactically you can make jumps from one dbms to another without much of a fuss. Obviously there are non-language features but, that is not what is being discussed here.
    - wvenable 7y ago
      Dealing with Unicode in SQL has long been a backwards-compatibility nightmare.
      - just_myles 7y ago
        In all fairness, dealing with unicode in general has been a pain point for me.
    - setr 7y ago
      That's mostly a result of databases (kinda) converging, SQL being a declarative language and it primarily being a wrapper around relational algebra, with a bunch of flags. And of course, it's a very direct interface to the RDBMS, and you're just migrating between systems that try very hard to have the same interface. As a language however, it's a whole lot of nonsense. Extremely inconsistent syntax, stuffing a trinary logic into a boolean system, a standard that gets extended arbitrarily, and even the tooling ecosystem is a fair bit pathetic (the lack of formatters particularly annoy me; everyone tries to support SQLs generally, and end up missing every extended feature.. if it's not a simple select query/ddl, you're not getting a decent format output) And it most certainly is a whole lot of fuss to migrate unless your database is tiny, or you didn't actually utilize the DB except as a dumb datastore (eg you relied solely on your ORM + indexes); there's a reason no good translator exists, and those that exist only support a very limited subset of any particular SQL variant, despite programming languages having a whole array of transpilers; it's simply not at all a simple language, and the variants only superficially look the same.
SignalsFromBob 7y ago
I suspect that someone, or a group of people, will step up to unofficially maintain Python 2 for the foreseeable future. It's clear that there are a lot of people using it that either can't easily migrate or are unwilling to do so for the various reasons already discussed in this thread.
- takeda 7y ago
  I'm sure that for the right money you can find someone. Don't forget that that person/organization would not only have to maintain python but also all the packages that you will be used.
- JohnFen 7y ago
  If I encounter Python 2 bugs that matter to me, I can and will fix them myself if needed, and submit or otherwise publish the change. I'm quite certain I'm not the only one.
  - marcus_holmes 7y ago
    Why not just migrate to 3? genuinely curious...
    - JohnFen 7y ago
      Because of the amount of work involved in porting my existing Python code. Python 3 doesn't offer any advantages that matter to me, so that's a lot of effort for little gain.
      - marcus_holmes 7y ago
        OK, thanks. Good luck with the bug fixing ;)
        JohnFen 7y ago
        I'm not really worried about bugs, because the code I have works well, and I doubt I'm going to do any serious new Python 2 development.

erokar 7y ago

Python 3 seems like a bit of a missed opportunity. Since they were introducing breaking changes in the first place, why didn't they go bigger? E.g. make the OOP seem less tacked on, immutable data structures, clean up inconsistencies in the standard library?

chungy 7y ago
Can you describe how OOP feels tacked on? One of the major changes in Python 3 is that new-style classes are the only style of classes.
- CoolGuySteve 7y ago
  I myself, speaking for my self and only my self find that, in regards to myself, the redundant self keyword, in my self's opinion, is somewhat selfish and easy for my self to accidentally omit. Self.
  - zabzonk 7y ago
    To be pedantic "self" is not a keyword.
    - WorldMaker 7y ago
      Worse than that not being a keyword, `self` isn't special at all, it's a naming convention that can be freely broken. Python codebases using `this` instead of `self` exist. Codebases that mix the two depending on who wrote which method in a class exist. I believe I saw `it` used once somewhere as the name for that parameter. I'm sure there are codebases with even crazier horrors for first argument names in class methods out there in the depths of corporate machines.
  - timw4mail 7y ago
    My experience with Python is a little lacking, but doesn't the self keyword mean the difference between an instance method, and a static method? Rust does the same thing - with self, it's an instance method, without, it's a static method.

snagglegaggle 7y ago

The main change people cite is the UTF-8 "support" but frankly it seems like far more pomp and circumstance than is necessary. Appropriate code point handling could have been provided and everything left as it was. And when you get rid of that, there's not that much left that is breaking.

CoolGuySteve 7y ago
I find the stronger differentiation between bytes and strings leads to a lot of gotchas, like when I forget to encode bytes or pass a string where bytes are expected. I understand why it's the way it is, but when it comes the the typical unixy things I need to do shuffling of files around, tar'ing stuff, etc, it definitely trips me up more than I'd wish.
- mkesper 7y ago
  You at least notice it's wrong. In Python2 sometimes 'it worked' until it broke and you had to figure out why.
  - snagglegaggle 7y ago
    See, it just broke when UTF-8 was interpreted as ASCII. It's entirely possible to treat bytes as bytes and leave encoding out of it for the vast majority of programs. If you're dealing with text editing and so on, then you know you need to be UTF-8 aware, and the broken programs would still be broken in either language. The visibility of the errors is a minor point, but I think it more appropriate that it be solved by e.g. the windowing toolkit API.
    - stefco_ 7y ago
      > the broken programs would still be broken in either language. You need to slap a decode anyway on reads from subprocesses in python3, and files open in Unicode mode by default. Wouldn't that fix the majority of silly UTF-8 compat bugs? Or am I missing a class of bugs that's not avoided automatically by python3 strings?

hermod 7y ago

With respect to async, I'm partial to trio [0], which is a spiritual successor to curio [1]. The model is similar to Golang in many ways, e.g. communication using channels [2] and cancellation [3] reminiscent of context.WithTimeout, except that in Golang you need to reify the context passing. The author has written some insightful commentary on designing async runtimes [4] and is actively developing the library, so I'm optimistic about its future. There were plans to use it for requests v3 until the fundraiser fiasco [5]. [0] https://github.com/python-trio/trio https://github.com/python-trio/trio [1] https://vorpus.org/blog/announcing-trio/ https://vorpus.org/blog/announcing-trio/ [2] https://trio.readthedocs.io/en/stable/reference-core.html#using-channels-to-pass-values-between-tasks https://trio.readthedocs.io/en/stable/reference-core.html#us... [3] https://trio.readthedocs.io/en/latest/reference-core.html#cancellation-and-timeouts https://trio.readthedocs.io/en/latest/reference-core.html#ca... [4] https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... [5] https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet...

privateSFacct 7y ago
I was curious about [5] The link to support requests (which is a great piece of software) is here: https://cash.app/$KennethReitz https://cash.app/$KennethReitz Note: This is NOT a charitable donation, it is a gift to an individual. These are not tax deductible under US law. Njs has a long attacking blog post saying this needs to go through PSF (huh?) and that they should be getting most of this money not the person the funds were directed towards (it's not clear how much they've actually contributed to requests over time). This supposedly also may trigger folks who have also suffered from "gaslighting". Supporting the developer of a piece of software does not, as far as I know, require that they sign up to handle it on a charitable basis. A big todo is made about the "large" amount raised. The amounts is 33K. To be frank, this is almost zero in tech land at least in the bay area and requests is a very highly used project. I was literally expecting something like 300K or even $1M - silly kickstarter projects raise for more and deliver nothing. Requests has already delivered a lot of utility. Just a bit of perspective from someone who wasn't familiar with this "fiasco".

mxcrossb 7y ago

On the topic of not enough carrot, I’m curious how impactful the end of support for python2 will be. How many programs stuck in python2 are encountering bugs in the runtime?

carapace 7y ago
I actually find this aspect of the whole thing exciting, perhaps paradoxically. Now that Python 2 is static the runtime can become asymptotically bug-free. Meaning that, if you only change it to fix bugs (as opposed to introducing new syntax|semantics) it's going to approach perfection.
- joshuamorton 7y ago
  Who will do that though?
  - carapace 7y ago
    I'm making it a hobby, at least: https://lists.sr.ht/~sforman/bladders-announce/%3C20190911164635.92CC6C06F5%40smtp.hushmail.com%3E https://lists.sr.ht/~sforman/bladders-announce/%3C2019091116...
  - downerending 7y ago
    I've considered taking it on. If there were enough money in it, I'd very seriously consider it. It's a very good language.
    - arbie 7y ago
      In ten years, there will be serious money in it as enterprise codebases need to be renewed.
- d0mine 7y ago
  You are assuming that fixing bugs introduces less new bugs.
7y ago

dividuum 7y ago

> The only real killer feature of Python3 is the async programming model. I understand that this is one of the major features, but I personally never saw the appeal, given that gevent exists and in my experience works well most of the time. It also allows me to multiplex IO operations and doesn't rely on new syntax. I'm probably missing something?

d0mine 7y ago
In gevent, any call may behave like an implicit "goto". Here's why "goto" is bad https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g... (the link is stolen from @hermod's comment above)
- jlokier 7y ago
  I think the nursery construct described in that link looks a lot like par blocks in Occam, Handel-C and XMOS XC.
Scramblejams 7y ago
I find it much easier to reason about my async Python code when the async yield points are explicit. If every line can potentially yield to another async task, I find myself thinking long and hard about a lot of those lines.

x0x0 7y ago

And the side-effect of an endless trail of shit to deal with. I write primarily ML code so until 3.5 or 3.6 python 3 offered me almost nothing better. It did, however, make managing environments even more of a mess. I quite frankly resented having to deal with code in both, swapping back and forth between python2, python3, pip2, pip3, etc.

epx 7y ago

For me the major gain in Py3 is exactly the sane handling of strings, that fixes the major flaw of Py2: weaking the String type to make the migration to UnicodeStrings "easy".

oarabbus_ 7y ago

I ran into an issue recently specific to Pandas and python3 with unicode. pd.read_excel(filepath) will read an entire dataset even if it contains unicode characters. pd.ExcelFile() silently drops(!!) unicode rows. The resulting object will simply skip unicode-containing rows (in ANY column) them without even a warning. For example, if you had an excel file: word --- "hello" "hello" 你早你早 "hello" then pd.read_excel() would give you a dataframe with 5 rows. ExcelFile() on the other hand would return (silently!) a dataframe with only the first two and the last row. Maybe this is a pandas issue, not a python issue, but it was really horrendous to debug for such a long time only to realize this was the issue.

j88439h84 7y ago
Is there an issue for this in the bug tracker?
- oarabbus_ 7y ago
  I searched, and this is the closest thing (https://github.com/pandas-dev/pandas/issues/11503 https://github.com/pandas-dev/pandas/issues/11503) but it is not the issue I experienced. I'm not sure how to submit a bug report, to be honest.

meowface 7y ago

It's funny, because I consider asyncio (and derivatives like curio) to be the worst part of Python 3. There are plenty of other compelling reasons to move over. No, none of them revolutionize the language, but there are fewer warts and cleaner ways of doing many things.

rtpg 7y ago

- format strings - mandatory keyword arguments - multi-dict splatting - nicer yield semantics for generators - Fixing system-specific encoding ambiguities - dataclasses - inline type annotations - better metaclass support - more introspection tooling - pathlib (for nicer path handling) - mocking pulled into the standard library in a cleaner way - stable ABIs for extensions - secrets handling - ellipsis instead of pass (yeah who cares but I care) - lots of standard lib API cleanup All of this is very helpful for making clean applications. But I would say it's _very_ helpful for making good libraries as well. This stuff is about having a strong language foundation to avoid plain weirdness like the click issue . Obviously it doesn't kill all of them, but there used to be even more of that kind of thing all the time. Library issues would basically get exported to its users, all basically due to language problems.