7 ms·

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 decis

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.

oblio 9y ago
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 improve performance by an order of magnitude; Python is still way too dynamic and this basically sunk Google's Unladen Swallow and Dropbox's Pyston, at least in terms of worldwide adoption I say this because I'm a bit worried that long term Python has locked itself into a corner where it will keep getting pushed into as the other languages develop a better developer UX. Python was a bit lucky to catch the ML train but who knows how long this will last. And Go, Kotlin, Typescript, Swift, Julia, Rust even are improving their ergonomics and edging towards Python's core competency.
- jononor 9y ago
  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-syntax https://www.python.org/dev/peps/pep-0484/#type-definition-sy...
  - tobltobs 9y ago
    > a_list = [] # type: List[T] How do you do that with out a comment?
    - Osmium 9y ago
      > a_list: List[T] = []
    - umanwizard 9y ago
      a_list: List[T] = []
    - Chickenosaurus 9y ago
      from typing import List a_list: List[T] = [] Visit https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html for more information.
  - oblio 9y ago
    They badly need to update the docs, then. Almost everything I see on that page does this: vec = [] # type: Vector[float] vec = [] # type: Iterable[Tuple[float, float]] a = MyClass() # type: MyClass[int] x = Foo() # type: Foo[int]
    - icegreentea2 9y ago
      Ugh that's because PEP 484 (which introduced 'proper' type hints) only introduced it for parameters and return types and implemented in Python 3.5. Type hinting bare variables was introduced with PEP 526 and implemented in Python 3.6. While I really like the concept of PEPs, and I think keeping original (like as they were written) PEPs around are the right thing to do, I do wish sometimes that Python did a better job at incorporating changes from PEPs into the core documentation once implemented.
- afarrell 9y ago
  > a bit lucky to catch the ML train I'd argue that the fact that it was explicitly a design goal to be a teaching language meant that it saw wide-scale adoption by universities, which made it more likely that someone writing an adaptor library to old linear algebra packages would write it in python.
- petre 9y ago
  Perl6 was brave enough. It became a totally different language and lost much of its user base who moved on to Python, Ruby and to a lesser extent Node. 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.
  - lizmat 9y ago
    > If you use ugly C-style loops instead of nicer native for loops, your loop will run 2x faster. This is what I currently consider a workaround. At the moment if you have a constant endpoint and it fits in a native int, such as `for ^10`, it is already highly optimized and actually runs faster than the equivalent in Perl 5. That is not done yet where the endpoint is a native int variable. :-(
- dagw 9y ago
  the GIL was not removed or at least a solid parallelism story was not included Not for lack of trying. People have been trying to do this since at least python 1.4. They just haven't found a way of doing it without negatively affecting single threaded performance, which Guido considers an unacceptable trade-off. http://pyparallel.org http://pyparallel.org is probably the most interesting latest experiment in this field, but it never got cross platform support and seems to have stalled out.
  - oblio 9y ago
    They were breaking many things, maybe they should have rewritten the C API? From what I remember that's the blocker. That would have broken all C extensions, but it's not like Python 3 at launch was a raving success regarding library porting.
    - dagw 9y ago
      Here's a video and HN thread that covers most of the current problems with removing the GIL: https://news.ycombinator.com/item?id=11842779 https://news.ycombinator.com/item?id=11842779
    - UncleEntity 9y ago
      They did break all C extensions in py3k -- not so bad you can't work around it with some preprocessor magic but break it they did. And they continued to break them within the py3k lifetime, mostly unicode related stuff from what I can remember. Probably still break stuff but I haven't had time for my toy python projects in a while so haven't been messing with the C-API lately.
      - oblio 9y ago
        We're actually agreeing here, I think. I wished they had broken everything harder and once and for all, in order to fix the issue. If there's going to be breakage anyway, people adjust their expectations. The scale is basically: a lot of breakage > a bit of breakage >>>>>> no breakage. Once you do break backwards compatibility, you might as well do it in a big way, provided you: * don't offer vaporware for a decade (hello Perl 6!) * try to offer some mitigations for the migration pain (auto-conversions, support libraries, top-notch docs, etc.) * offer a great carrot at the end of the tunnel (good performance would be such a carrot)
- jerf 9y ago
  "I say this because I'm a bit worried that long term Python has locked itself into a corner where it will keep getting pushed into as the other languages develop a better developer UX." You can stop worrying. That is absolutely what will happen. But it is a good thing. Languages should be something, not merely an accumulation of every fad and trend that appeared over its lifetime. That means eventually they will mature, and eventually hit a peak, and then fade. But during that process, at least you'll have a nice, mature language, instead of one always chasing the latest pretty-shiny, immature, confusing, crammed with too many features, with libraries constantly jerking around trying to keep up and always just a bit broken. Indeed, I kind of thing Python has already done a bit too much of the latter, and were I in charge of Python I'd give some serious attention to the idea of simply freezing the core language. Python is what it is. Let it be what it is, because what it is is pretty good. It's by far my favorite language of the genre it is in. It's got way too much baggage to compete in the next arena, so let it be the master of the one it is in instead.
  - oblio 9y ago
    What's the last mainstream language that died? Even more so, what's the last mainstream language since the age of the internet that died? Nothing truly dies anymore. It just lives as a ghost and haunts unfortunate journeymen.
  - username223 9y ago
    > [Languages] will mature, and eventually hit a peak, and then fade. "Maintenance mode" should be a badge of honor: you have created something that is a stable foundation for new things. For example, how many programming languages are implemented in anything other than C and/or themselves? Not a lot, and that's a huge compliment to C. Despite its faults, you can probably count on your C program working after you're dead.
- silval 9y ago
  > I think Python 3 was not brave enough, to be honest Agree 100%. I would have added: * fix the C API and pass the interpreter instance as the first parameter to all functions as is common in other interpreted languages, rather than relying on a global state.

oblio 9y ago

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 improve performance by an order of magnitude; Python is still way too dynamic and this basically sunk Google's Unladen Swallow and Dropbox's Pyston, at least in terms of worldwide adoption I say this because I'm a bit worried that long term Python has locked itself into a corner where it will keep getting pushed into as the other languages develop a better developer UX. Python was a bit lucky to catch the ML train but who knows how long this will last. And Go, Kotlin, Typescript, Swift, Julia, Rust even are improving their ergonomics and edging towards Python's core competency.

jononor 9y ago
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-syntax https://www.python.org/dev/peps/pep-0484/#type-definition-sy...
- tobltobs 9y ago
  > a_list = [] # type: List[T] How do you do that with out a comment?
  - Osmium 9y ago
    > a_list: List[T] = []
  - umanwizard 9y ago
    a_list: List[T] = []
  - Chickenosaurus 9y ago
    from typing import List a_list: List[T] = [] Visit https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html for more information.
- oblio 9y ago
  They badly need to update the docs, then. Almost everything I see on that page does this: vec = [] # type: Vector[float] vec = [] # type: Iterable[Tuple[float, float]] a = MyClass() # type: MyClass[int] x = Foo() # type: Foo[int]
  - icegreentea2 9y ago
    Ugh that's because PEP 484 (which introduced 'proper' type hints) only introduced it for parameters and return types and implemented in Python 3.5. Type hinting bare variables was introduced with PEP 526 and implemented in Python 3.6. While I really like the concept of PEPs, and I think keeping original (like as they were written) PEPs around are the right thing to do, I do wish sometimes that Python did a better job at incorporating changes from PEPs into the core documentation once implemented.
afarrell 9y ago
> a bit lucky to catch the ML train I'd argue that the fact that it was explicitly a design goal to be a teaching language meant that it saw wide-scale adoption by universities, which made it more likely that someone writing an adaptor library to old linear algebra packages would write it in python.
petre 9y ago
Perl6 was brave enough. It became a totally different language and lost much of its user base who moved on to Python, Ruby and to a lesser extent Node. 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.
- lizmat 9y ago
  > If you use ugly C-style loops instead of nicer native for loops, your loop will run 2x faster. This is what I currently consider a workaround. At the moment if you have a constant endpoint and it fits in a native int, such as `for ^10`, it is already highly optimized and actually runs faster than the equivalent in Perl 5. That is not done yet where the endpoint is a native int variable. :-(
dagw 9y ago
the GIL was not removed or at least a solid parallelism story was not included Not for lack of trying. People have been trying to do this since at least python 1.4. They just haven't found a way of doing it without negatively affecting single threaded performance, which Guido considers an unacceptable trade-off. http://pyparallel.org http://pyparallel.org is probably the most interesting latest experiment in this field, but it never got cross platform support and seems to have stalled out.
- oblio 9y ago
  They were breaking many things, maybe they should have rewritten the C API? From what I remember that's the blocker. That would have broken all C extensions, but it's not like Python 3 at launch was a raving success regarding library porting.
  - dagw 9y ago
    Here's a video and HN thread that covers most of the current problems with removing the GIL: https://news.ycombinator.com/item?id=11842779 https://news.ycombinator.com/item?id=11842779
  - UncleEntity 9y ago
    They did break all C extensions in py3k -- not so bad you can't work around it with some preprocessor magic but break it they did. And they continued to break them within the py3k lifetime, mostly unicode related stuff from what I can remember. Probably still break stuff but I haven't had time for my toy python projects in a while so haven't been messing with the C-API lately.
    - oblio 9y ago
      We're actually agreeing here, I think. I wished they had broken everything harder and once and for all, in order to fix the issue. If there's going to be breakage anyway, people adjust their expectations. The scale is basically: a lot of breakage > a bit of breakage >>>>>> no breakage. Once you do break backwards compatibility, you might as well do it in a big way, provided you: * don't offer vaporware for a decade (hello Perl 6!) * try to offer some mitigations for the migration pain (auto-conversions, support libraries, top-notch docs, etc.) * offer a great carrot at the end of the tunnel (good performance would be such a carrot)
jerf 9y ago
"I say this because I'm a bit worried that long term Python has locked itself into a corner where it will keep getting pushed into as the other languages develop a better developer UX." You can stop worrying. That is absolutely what will happen. But it is a good thing. Languages should be something, not merely an accumulation of every fad and trend that appeared over its lifetime. That means eventually they will mature, and eventually hit a peak, and then fade. But during that process, at least you'll have a nice, mature language, instead of one always chasing the latest pretty-shiny, immature, confusing, crammed with too many features, with libraries constantly jerking around trying to keep up and always just a bit broken. Indeed, I kind of thing Python has already done a bit too much of the latter, and were I in charge of Python I'd give some serious attention to the idea of simply freezing the core language. Python is what it is. Let it be what it is, because what it is is pretty good. It's by far my favorite language of the genre it is in. It's got way too much baggage to compete in the next arena, so let it be the master of the one it is in instead.
- oblio 9y ago
  What's the last mainstream language that died? Even more so, what's the last mainstream language since the age of the internet that died? Nothing truly dies anymore. It just lives as a ghost and haunts unfortunate journeymen.
- username223 9y ago
  > [Languages] will mature, and eventually hit a peak, and then fade. "Maintenance mode" should be a badge of honor: you have created something that is a stable foundation for new things. For example, how many programming languages are implemented in anything other than C and/or themselves? Not a lot, and that's a huge compliment to C. Despite its faults, you can probably count on your C program working after you're dead.
silval 9y ago
> I think Python 3 was not brave enough, to be honest Agree 100%. I would have added: * fix the C API and pass the interpreter instance as the first parameter to all functions as is common in other interpreted languages, rather than relying on a global state.