[hyperion2010]

I'll add a 4th rationale: 4. It will create work for countless developers which is completely consistent with the python core value of disdain for other people's time.

If this pep were implemented I suspect it would result in forcing thousands of not tens of thousands of people to spend hours modifying perfectly working code and destroying the ability to run old scientific code without modification. Extremely effective industrial sabotage if it were to be accepted.

It is hard for me to articulate how much peps like this reinforce my desire to never start another python project. Even if this pep is rejected the fact that there are people who would put in the time and effort to write and submit such a PEP tells me that they will do it again, and eventually they might succeed.

[discretion22]

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

[nightpool]

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

[Narhem]

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.

[diggan]

So it doesn't matter if it goes through or not, just that someone proposed a change like this is enough to steer you away from Python?

If the change goes through, couldn't you just use older Python versions for those specific projects, or has the Python ecosystem still not figured out how to do this without huge hassles?

[hamandcheese]

That version will eventually become EOL, stop getting security patches, eventually stop compiling with the latest OpenSSL, etc. Bitrot.

[yunohn]

> destroying the ability to run old scientific code

TBH that kind of code barely survives minor Python version upgrades in my experience.

[northernman]

Perhaps in a few years we can have another PEP, to require "except BaseException" to be replaced with bare "except:". Then we can all change our code back again.

[plesner]

If someone on my team or in my company proposed to break most of our python code for no substantial reason, unless they were pretty junior I would count that as a real red flag against their judgement.

How do people land on the python steering council exactly?

[dpwm]

From the PEP:

> A tool will be provided to automatically update code to replace bare except: with except BaseException:.

[arp242]

That's besides the point. I don't want to muck about with tools on my Python scripts.

I have sometimes not run a Python script for a few years, and then when I need it, it stopped working and I need to track down what changed/broke or run some tool or whatnot. I don't keep track of the latest greatest Python changes – like most Python programmers it's not my "day job" to write Python code so I now need to track what changed between "the Python version I used about 3 years ago, whatever that was" and now. It's pretty annoying.

And that's assuming said tool will be fool-proof. Never mind of course that all my dependencies (if any) will need updating too.

What will happen in practice is that people will write "except Exception:" rather than "except:" and do nothing different. Basically nothing will change.

Meanwhile, I have C and Go programs that have worked without modification for about 10 years. Not that nothing ever breaks in C or Go, but it's the exception (hah!) rather than the rule.

[mannykannot]

Which just underscores the point that this is mostly software engineering theater. If your goal is a system in which all exceptions are explicitly and appropriately handled, your first mistake was picking Python.

I propose a rider to the PEP in which implementation will be deferred until its proponents can correctly affirm that the library reference lists, for each function and method, every exception it might throw.

[hawski]

Thank goodness there was 2to3 tool in the past. It made the migration to Python 3 so smooth and quick. /partial-s

I know it is not nearly on the same level, but people seriously overestimate the effort needed between not doing anything at all and even the slightest work, no matter how reliable and easy. The difference between nothing and anything is huge.

[instig007]

will there be a tool to upgrade all direct and transitive dependencies of your project to make them work in that new interpreter?

[Joker_vD]

I propose to call this tool 3to760, in memory of 2to3.

[shadowgovt]

Anything popular is going to attract an increasingly high-variance group of engineers. With such variance comes such PEPS.

[kstrauser]

Eh, while I sympathize with what you’re saying, PEPs get written and rejected all the time. I’ve gotten the impression that some were written for the main goal of documenting the reasons why a common request is a bad idea.

Like, I don’t know if there’s a PEP to use braces, but it wouldn’t surprise me if someone had made one so that from then on there’d be an official doc you could point people at when they ask about it.

Not saying this is one of those, and I see Brett Cannon’s on this one. I am saying not to get too worked up over the existence of a draft PEP.

[zahlman]

PEP 666 was supposedly written to be rejected so as to document the community stance on indentation.

The rejection of braces isn't in a PEP to my knowledge; it's only in the __future__ Easter egg.

[setopt]

I think emitting a warning every time an unspecific exception is caught might be a better balance. That way, you could still do a quick “try: … except: …” when drafting new code, but the code might warn you if the bare except block is ever used (including what exception was caught, and a suggestion for how to catch only that specific exception).

[linsomniac]

With that PEP you can still do a quick "try: except:" it's just spelled "try: except Exception:"

[dataflow]

> warning every time an unspecific exception is caught

Caught and not re-raised

[cortesoft]

I often find discussions of these sorts, whether for python or other open source projects, get so focused on purity of concept that they totally forget practicality

[a-french-anon]

Quickly read the thread, isn't "hours" a bit much for what is basically a

  sed -Ei 's/^([\t ]*except):/\1 BaseException:/' **/*.py

[instig007]

now try delivering that change to all of your dependencies before being able to deploy your software with a new interpreter.

[Joker_vD]

Will this command be automatically run by venv, or poetry, or whatever, on every package update?

[shadowgovt]

Definitely going to want to use Tree-sitter, not regex. That regex just broke my docstrings.

[himinlomax]

Multi-line strings don't exist.

[sdenton4]

On the bright side, turning bare exceptions into types exceptions is the kind of thing an llm is great for. It's also basically zero cost for new code.

On the other hand, I completely agree that it's not worth a breaking change.

[relaxing]

Does that even require an LLM? It should be possible through traditional static analysis.