Hacker News Reader

Comment by discretion22 | Hacker News Reader

> It is hard for me to articulate how much peps like this reinforce my desire to never start another python project

I completely understand this sentiment. Recent python events have made me wonder if there are some people intent on sabotaging the management of the language.

I loved the incremental improvements and thoughtful process involved up until a couple of years ago but it feels like python will become brittle and break badly if things continue the way they are. It feels like the adults have been driven out the room when it comes to stewardship. I'm not sure how recoverable the situation is.

View on HN

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

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!

Just as a reminder, the BDFL supported the "walrus operator" and co-authored the PEP for it.

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."

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.

Very good point and 'cheers!' for raising it.

It's not the "walrus operator" per se that's the problem, it's the change in project governance.

Python has been captured by bureaucracy and corporate interests. The way it's being improved-to-death is a symptom. The unceremonious eviction of Tim Peters indicates to me that the take-over is complete: the new guard feels comfortable throwing out the old guard, they expect that their power is such that no one will blink, and no one did. (No corporation withdrew support for them, the blow-back was all hot air.)

It would be interesting to know GvR's opinions of some of the new cruft, but it's not really relevant.

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).

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.

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 and specifically 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!

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__.

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).

Elixir's 'pipes' always felt very hacky to me. (But so does most of the language, compared to Erlang.)

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.

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.

I feel like as a scripting language Python excels. Glad to have this PEP, but it would be more pythonic have except be optional.

The reason I pick up Python for projects is because it grows with the application; opportunities to add typing etc. Who knows maybe in a few years Python will enforce all the types and it will be as verbose as Java. Personally I’d like to see how they handle declaring a method or function throws exceptions.

Pretty narly we have compiled Python apps with poetry, it’s starting to punch out of its weight class.

Reply on news.ycombinator.com