5 ms·

None of these ideas seem outright specific to Python and I don't think it makes sense to attribute all these changes to Python influence. C# and D, for example,

by nv-vn 11y ago

None of these ideas seem outright specific to Python and I don't think it makes sense to attribute all these changes to Python influence. C# and D, for example, have had most of these features for a few years. One could just as easily say "how C++ is becoming Haskell" or "how C++ is becoming Go" (both of which have many of these features). I think a better title for this would be something along the lines of "Python idioms in C++".

coldtea 11y ago
>how C++ is becoming Go Hmm? Go has almost none of these features.
- nv-vn 11y ago
  It has tuples, local type inference, for loops on ranges, and anonymous functions/lambdas (which act as closures/"capture" scope). Hardly "almost none of these features".
  - leetrout 11y ago
    I'm new to Go- but I don't think it has tuples in the python sense[1]. Happy to be corrected here if there's a broader definition you're referring to. I do wish it had support for slice unpacking like it does for return values. The assignment from returns or ranges is one of the things I really ejoy. Edit: [1] I'll clarify that I define that as an immutable, indexable data structure that you can unpack in to multiple assignments.
    - nv-vn 11y ago
      It doesn't have "true tuples" but you can do multiple returns in a tuple-like way and there is syntax for unpacking it. While a pair can't be stored in a single variable, you can just manually unpack and repack them for a similar effect to what tuples can do. For the record, most languages don't have indexable tuples as far as I'm aware and make you unpack them with some form of pattern matching.
      - pcwalton 11y ago
        > For the record, most languages don't have indexable tuples as far as I'm aware Most languages with tuples have indexable tuples either via language syntax or library functions. (For example, OCaml practically does, with fst and snd.) > It doesn't have "true tuples" but you can do multiple returns in a tuple-like way and there is syntax for unpacking it. There's a large difference between having multiple return values and having first-class tuple values.
        nv-vn 11y ago
        Haskell/OCaml style "fst" and "snd" functions can't index arbitrary tuples (they only work on 2-tuples/pairs): http://i.imgur.com/PbhNxmu.png http://i.imgur.com/PbhNxmu.png.
  - coldtea 11y ago
    Go doesn't have tuples (multiple return isn't that). This leaves us with local type inference, for loops on ranges, and anonymous functions/lambdas. The parent also mentions: binary literals, raw string literals, uniform Initialization, standard algorithms like map, filter and any, and parameter packing. All of which Go doesn't have. Plus, Go range loops are constrained to built-in types (slices, channels, etc.), unlike C++/Python where you can implement begin()/end() or the iterator protocol respectively and get it for any type. So, from 10 things mentioned, whereas C++ and Python share ALL of them, Go only has 2 of them and sort of has one more (the range-for). I'd stick with: "almost none of these features".
    - cespare 11y ago
      Go has raw string literals.
    - catnaroek 11y ago
      Go doesn't even have local type inference: http://ideone.com/RQzz7E http://ideone.com/RQzz7E. Contrast with a language that actually does: http://ideone.com/LtN1vQ http://ideone.com/LtN1vQ. Type inference, even the local kind, means figuring out the types of variables from how they're used, not just from how they're initialized.
      - Raphael_Amiard 11y ago
        That's a completely arbitrary definition, and it is wrong. Type inference limited to the initialization point is still type inference, and actually most languages before Rust and Swift that have local type inference (C#, D, C++11) are limited to type inference at the declaration/initialization point.
        catnaroek 11y ago
        > That's a completely arbitrary definition, and it is wrong. The definition is very simple - the inference engine must use nontrivial inference rules to reconstruct the types. The rule “given P then P” alone doesn't quite cut it, which means that ”given that 0 is an int, then something that's initialized to 0 is an int“ also doesn't quite cut it. Calling what Go, C# and C++11 have “type inference” is akin to calling Python a statically typed language because it has a trivial type system with exactly one static type. > actually most languages before Rust and Swift that have local type inference (C#, D, C++11) are limited to type inference at the declaration/initialization point. Then they just have unidirectional type propagation - which is perfectly fine, just not type inference.
  - catnaroek 11y ago
    Go doesn't have local type inference: http://ideone.com/RQzz7E http://ideone.com/RQzz7E. This is local type inference: http://ideone.com/LtN1vQ http://ideone.com/LtN1vQ. And it also doesn't have tuples: you can't store tuples in variables or larger data structures, pass them as function arguments, etc.
  - spriggan3 11y ago
    Go doesn't have tuples. Go doesn't have local type inference For loops on ranges are limited to Go built-in types, you can't create your own iterators. So yes, almost none of these features are available in Go.
incepted 11y ago
> C# and D, for example, have had most of these features for a few years Come on, now. D is 15 years old, C# 16. Python is more than 25 years old.
- nv-vn 11y ago
  Most of these features were not present in Python until later (mentioned in the article: "In 2001, Python added statically nested scopes, which allow lambda functions to capture variables defined in enclosing functions"). And if we're discussing the original source of these features, Lisp had every single one of these before Python even existed.
  - pjmlp 11y ago
    With the advantage of compiling to native code and proper use of all CPU cores!
brianberns 11y ago
I would say that most of the features in the article (e.g. lambdas) originated in functional languages, not Python. Static type inference, in particular, comes from the functional world. Python's dynamic typing is completely opposite.

by nv-vn 11y ago

coldtea 11y ago

>how C++ is becoming Go Hmm? Go has almost none of these features.

nv-vn 11y ago
It has tuples, local type inference, for loops on ranges, and anonymous functions/lambdas (which act as closures/"capture" scope). Hardly "almost none of these features".
- leetrout 11y ago
  I'm new to Go- but I don't think it has tuples in the python sense[1]. Happy to be corrected here if there's a broader definition you're referring to. I do wish it had support for slice unpacking like it does for return values. The assignment from returns or ranges is one of the things I really ejoy. Edit: [1] I'll clarify that I define that as an immutable, indexable data structure that you can unpack in to multiple assignments.
  - nv-vn 11y ago
    It doesn't have "true tuples" but you can do multiple returns in a tuple-like way and there is syntax for unpacking it. While a pair can't be stored in a single variable, you can just manually unpack and repack them for a similar effect to what tuples can do. For the record, most languages don't have indexable tuples as far as I'm aware and make you unpack them with some form of pattern matching.
    - pcwalton 11y ago
      > For the record, most languages don't have indexable tuples as far as I'm aware Most languages with tuples have indexable tuples either via language syntax or library functions. (For example, OCaml practically does, with fst and snd.) > It doesn't have "true tuples" but you can do multiple returns in a tuple-like way and there is syntax for unpacking it. There's a large difference between having multiple return values and having first-class tuple values.
      - nv-vn 11y ago
        Haskell/OCaml style "fst" and "snd" functions can't index arbitrary tuples (they only work on 2-tuples/pairs): http://i.imgur.com/PbhNxmu.png http://i.imgur.com/PbhNxmu.png.
- coldtea 11y ago
  Go doesn't have tuples (multiple return isn't that). This leaves us with local type inference, for loops on ranges, and anonymous functions/lambdas. The parent also mentions: binary literals, raw string literals, uniform Initialization, standard algorithms like map, filter and any, and parameter packing. All of which Go doesn't have. Plus, Go range loops are constrained to built-in types (slices, channels, etc.), unlike C++/Python where you can implement begin()/end() or the iterator protocol respectively and get it for any type. So, from 10 things mentioned, whereas C++ and Python share ALL of them, Go only has 2 of them and sort of has one more (the range-for). I'd stick with: "almost none of these features".
  - cespare 11y ago
    Go has raw string literals.
  - catnaroek 11y ago
    Go doesn't even have local type inference: http://ideone.com/RQzz7E http://ideone.com/RQzz7E. Contrast with a language that actually does: http://ideone.com/LtN1vQ http://ideone.com/LtN1vQ. Type inference, even the local kind, means figuring out the types of variables from how they're used, not just from how they're initialized.
    - Raphael_Amiard 11y ago
      That's a completely arbitrary definition, and it is wrong. Type inference limited to the initialization point is still type inference, and actually most languages before Rust and Swift that have local type inference (C#, D, C++11) are limited to type inference at the declaration/initialization point.
      - catnaroek 11y ago
        > That's a completely arbitrary definition, and it is wrong. The definition is very simple - the inference engine must use nontrivial inference rules to reconstruct the types. The rule “given P then P” alone doesn't quite cut it, which means that ”given that 0 is an int, then something that's initialized to 0 is an int“ also doesn't quite cut it. Calling what Go, C# and C++11 have “type inference” is akin to calling Python a statically typed language because it has a trivial type system with exactly one static type. > actually most languages before Rust and Swift that have local type inference (C#, D, C++11) are limited to type inference at the declaration/initialization point. Then they just have unidirectional type propagation - which is perfectly fine, just not type inference.
- catnaroek 11y ago
  Go doesn't have local type inference: http://ideone.com/RQzz7E http://ideone.com/RQzz7E. This is local type inference: http://ideone.com/LtN1vQ http://ideone.com/LtN1vQ. And it also doesn't have tuples: you can't store tuples in variables or larger data structures, pass them as function arguments, etc.
- spriggan3 11y ago
  Go doesn't have tuples. Go doesn't have local type inference For loops on ranges are limited to Go built-in types, you can't create your own iterators. So yes, almost none of these features are available in Go.

incepted 11y ago

> C# and D, for example, have had most of these features for a few years Come on, now. D is 15 years old, C# 16. Python is more than 25 years old.

nv-vn 11y ago
Most of these features were not present in Python until later (mentioned in the article: "In 2001, Python added statically nested scopes, which allow lambda functions to capture variables defined in enclosing functions"). And if we're discussing the original source of these features, Lisp had every single one of these before Python even existed.
- pjmlp 11y ago
  With the advantage of compiling to native code and proper use of all CPU cores!

brianberns 11y ago

I would say that most of the features in the article (e.g. lambdas) originated in functional languages, not Python. Static type inference, in particular, comes from the functional world. Python's dynamic typing is completely opposite.