4 ms·

As someone who doesn't follow the language, which recent events are you referring to?

behnamoh 2y ago
Using "|" to merge dictionaries (which was possible in other ways before) instead of offering pipes as in bash and Elixir (a feature that's actually useful).
- eloisius 2y ago
  The “|” operator was already used for set unions and binary OR, so it’s a little late to reserve it for control flow. Personally I don’t mind having a “dict union” operator at all.
- eru 2y ago
  Elixir's 'pipes' always felt very hacky to me. (But so does most of the language, compared to Erlang.)
  - behnamoh 2y ago
    In what ways does Elixir feel "hacky"? I get that it can be inconsistent at times but the whole language is really a Lisp-2 in disguise.
    - eru 2y ago
      Any Lisp-ness comes from Elixir being a skin on Erlang, and so comes almost anything else good to say about Elixir. (And my comment was explicitly comparing Elixir to Erlang.) The 'pipe' is hacky, for example, because it's just syntactic sugar that only works in one specific case, and not in general.
- btown 2y ago
  https://peps.python.org/pep-0584/ https://peps.python.org/pep-0584/ is the PEP for merging dictionaries; sadly, it barely mentions pipes as a consideration. To be fair, the notion that pipes are lower-priority than other syntax needs is not exclusive to Python: in the JS world, discussion in https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator and specifically https://github.com/tc39/proposal-pipeline-operator/wiki/Bikeshedding-the-Hack-topic-token/ https://github.com/tc39/proposal-pipeline-operator/wiki/Bike... has been going on since 2018, with things like Tuple Literals taking precedence. On the Python side, though, at least you can build your own pipes! You can define various helper classes that have, say, an `__rrshift__` method, to let you do the following with full type-checking support: load_iterable_from_db() >> to_dict_by("id") >> tee(logger) >> call_(dict.values) >> to_dataframe (With great apologies to FP folks who see a bind operator, and C++ folks who have seen enough operator overloading for a lifetime!) Not necessarily something you want to use unless you want to confuse your team, but quite useful for fluent code in notebooks!
- kristjansson 2y ago
  Like all of python, `a | b` operator is just `a.__or__(b)`. If you want that operator to do something different in a different context, just override __or__.
- zahlman 2y ago
  Nothing prevents you from defining the | operator for other user-defined types where that would actually make sense. A dictionary doesn't represent an ongoing process or stream. Lots of things are possible; that isn't a reason not to find better ways to do them (cf. Raymond Hettinger).
carapace 2y ago
It wasn't recent by Internet time but when the debate on walrus operator drove out the BDFL that was the obvious break. Python has been circling the drain ever since. A lot of motion, yes, but to what end? - - - - Oh! How could I forget!? The creeps actually banned Tim Peters!
- zahlman 2y ago
  Just as a reminder, the BDFL supported the "walrus operator" and co-authored the PEP for it.
  - nightpool 2y ago
    Yes? and as GP said, he stepped down because (as explained in the first line of his email) "Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions."
    - zahlman 2y ago
      A lot of the time, people say things like "Python has been circling the drain ever since." referring to the implementation of the "walrus operator", to imply that they don't like the feature and that it was the first of a series of changes to the language that have made it progressively worse; and they often further imply that if only we still had the original leadership then we could avoid such damage to the language. I was, in a sense, in that camp at the time, before I looked it up. I felt that the operator went against the spirit of the language by trampling on what was previously a strong, and clearly very conscious, separation between statements and expressions. And I misguidedly imagined, and lamented, that GvR was unable to keep it out of the language, being overruled by consensus. I just want to make sure it's clear that things are not like that. Rather, the Python envisioned (nowadays, though not originally) by the original leadership includes PEP 572 - and probably also the large majority of what's been added since.
      - carapace 2y ago

Using "|" to merge dictionaries (which was possible in other ways before) instead of offering pipes as in bash and Elixir (a feature that's actually useful).

eloisius 2y ago
The “|” operator was already used for set unions and binary OR, so it’s a little late to reserve it for control flow. Personally I don’t mind having a “dict union” operator at all.
eru 2y ago
Elixir's 'pipes' always felt very hacky to me. (But so does most of the language, compared to Erlang.)
- behnamoh 2y ago
  In what ways does Elixir feel "hacky"? I get that it can be inconsistent at times but the whole language is really a Lisp-2 in disguise.
  - eru 2y ago
    Any Lisp-ness comes from Elixir being a skin on Erlang, and so comes almost anything else good to say about Elixir. (And my comment was explicitly comparing Elixir to Erlang.) The 'pipe' is hacky, for example, because it's just syntactic sugar that only works in one specific case, and not in general.
btown 2y ago
https://peps.python.org/pep-0584/ https://peps.python.org/pep-0584/ is the PEP for merging dictionaries; sadly, it barely mentions pipes as a consideration. To be fair, the notion that pipes are lower-priority than other syntax needs is not exclusive to Python: in the JS world, discussion in https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator and specifically https://github.com/tc39/proposal-pipeline-operator/wiki/Bikeshedding-the-Hack-topic-token/ https://github.com/tc39/proposal-pipeline-operator/wiki/Bike... has been going on since 2018, with things like Tuple Literals taking precedence. On the Python side, though, at least you can build your own pipes! You can define various helper classes that have, say, an `__rrshift__` method, to let you do the following with full type-checking support: load_iterable_from_db() >> to_dict_by("id") >> tee(logger) >> call_(dict.values) >> to_dataframe (With great apologies to FP folks who see a bind operator, and C++ folks who have seen enough operator overloading for a lifetime!) Not necessarily something you want to use unless you want to confuse your team, but quite useful for fluent code in notebooks!
kristjansson 2y ago
Like all of python, `a | b` operator is just `a.__or__(b)`. If you want that operator to do something different in a different context, just override __or__.
zahlman 2y ago
Nothing prevents you from defining the | operator for other user-defined types where that would actually make sense. A dictionary doesn't represent an ongoing process or stream. Lots of things are possible; that isn't a reason not to find better ways to do them (cf. Raymond Hettinger).

carapace 2y ago

It wasn't recent by Internet time but when the debate on walrus operator drove out the BDFL that was the obvious break. Python has been circling the drain ever since. A lot of motion, yes, but to what end? - - - - Oh! How could I forget!? The creeps actually banned Tim Peters!

zahlman 2y ago
Just as a reminder, the BDFL supported the "walrus operator" and co-authored the PEP for it.
- nightpool 2y ago
  Yes? and as GP said, he stepped down because (as explained in the first line of his email) "Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions."
  - zahlman 2y ago
    A lot of the time, people say things like "Python has been circling the drain ever since." referring to the implementation of the "walrus operator", to imply that they don't like the feature and that it was the first of a series of changes to the language that have made it progressively worse; and they often further imply that if only we still had the original leadership then we could avoid such damage to the language. I was, in a sense, in that camp at the time, before I looked it up. I felt that the operator went against the spirit of the language by trampling on what was previously a strong, and clearly very conscious, separation between statements and expressions. And I misguidedly imagined, and lamented, that GvR was unable to keep it out of the language, being overruled by consensus. I just want to make sure it's clear that things are not like that. Rather, the Python envisioned (nowadays, though not originally) by the original leadership includes PEP 572 - and probably also the large majority of what's been added since.
    - carapace 2y ago