6 ms·
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'
by hyperion2010 2y ago
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.
- sdenton4 2y agoOn 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 2y agoDoes that even require an LLM? It should be possible through traditional static analysis.
- diggan 2y ago> It should be possible through traditional static analysis Even better/worse, could do it with regex on text streams.
- pansa2 2y agoEverything requires an LLM nowadays.
- DrillShopper 2y agoEspecially if you want to get funding
- sdenton4 2y agoThere's some space for interpretation in picking exactly which exception type to use depending on context (value error vs runtime error vs not implemented error), and there may be package specific exceptions available.
- dpwm 2y agoFrom the PEP: > A tool will be provided to automatically update code to replace bare except: with except BaseException:.
- Joker_vD 2y agoI propose to call this tool 3to760, in memory of 2to3.
- instig007 2y agowill there be a tool to upgrade all direct and transitive dependencies of your project to make them work in that new interpreter?
- hawski 2y agoThank 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.
- zahlman 2y agoI feel like I've heard this argument countless times, and yet I'm never swayed by it. I've been using Python for about 20 years and I've never felt put out by the need to change anything to work with a new version of Python (or of a library). It simply hasn't caused significant pain - my memories are more filled with painful debugging sessions caused by overly-clever designs or trying to refactor too much at once.
- arp242 2y agoThat'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.
- a-french-anon 2y agoQuickly read the thread, isn't "hours" a bit much for what is basically a sed -Ei 's/^([\t ]*except):/\1 BaseException:/' **/*.py
- instig007 2y agonow try delivering that change to all of your dependencies before being able to deploy your software with a new interpreter.
- fny 2y agoNot that I support the PEP but they could easily add an interpreter flag or environment variable to disable the behavior.
- Joker_vD 2y agoWill this command be automatically run by venv, or poetry, or whatever, on every package update?
- himinlomax 2y agoMulti-line strings don't exist.
- shadowgovt 2y agoDefinitely going to want to use Tree-sitter, not regex. That regex just broke my docstrings.
- diggan 2y agoSo 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 2y agoThat version will eventually become EOL, stop getting security patches, eventually stop compiling with the latest OpenSSL, etc. Bitrot.
- diggan 2y agoDoes that matter when you just want to run "old scientific code"? Old version of libraries like OpenSSL can still be run in that context, granted you don't expose that code to the internet at large.
- lbhdc 2y agoOld scientific code broke for many people with the introduction of the mac m1. I would think this would be a continuing trend in the future. Staying on old versions simply isn't possible over a long period without keeping the hardware going with it too.
- diggan 2y ago> Old scientific code broke for many people with the introduction of the mac m1. How could the people maintaining Python possibly avoid that? It would be up to Apple to proactively reach out to affected projects, if Apple cares about that.
- hamandcheese 2y agoThe way to "avoid" it is to make it easier to upgrade to the latest version of python rather than making it harder.
- discretion22 2y ago> 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 2y agoAs someone who doesn't follow the language, which recent events are you referring to?
- behnamoh 2y agoUsing "|" 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 agoThe “|” 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 agoElixir's 'pipes' always felt very hacky to me. (But so does most of the language, compared to Erlang.)
- behnamoh 2y agoIn 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.
- yunohn 2y ago> destroying the ability to run old scientific code TBH that kind of code barely survives minor Python version upgrades in my experience.
- setopt 2y agoI 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 2y agoWith that PEP you can still do a quick "try: except:" it's just spelled "try: except Exception:"
- dataflow 2y ago> warning every time an unspecific exception is caught Caught and not re-raised
- shadowgovt 2y agoAnything popular is going to attract an increasingly high-variance group of engineers. With such variance comes such PEPS.
- northernman 2y agoPerhaps 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.
- kstrauser 2y agoEh, 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 2y agoPEP 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.
- cortesoft 2y agoI 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
- plesner 2y agoIf 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?
- deleted 2y ago[deleted]