[HN Gopher] PEP 760: No more bare excepts
___________________________________________________________________
PEP 760: No more bare excepts
Author : ayhanfuat
Score : 144 points
Date : 2024-10-09 13:54 UTC (9 hours ago)
(HTM) web link (discuss.python.org)
(TXT) w3m dump (discuss.python.org)
| sph wrote:
| This would be a backward-incompatible change, no?
|
| In other languages, such a change would only be possible with a
| major version bump, though I imagine that because of the Python 3
| collective trauma, the language designers now are OK with
| breaking older code without calling it Python 4. Anything goes,
| as long as it's called Python 3.
|
| (Python lost me in the 2->3 migration and I haven't used it in a
| decade, so correct me if I'm wrong)
| letmeinhere wrote:
| Python doesn't use semantic versioning. The number after the
| first period is a major (annual) release and can and does
| contain breaking changes (though so far never on the scale of
| the 2->3 upgrade).
|
| We may never see a 4.0 because of the scar tissue, but the
| language continues to evolve.
| sph wrote:
| Linux: let's bump the major version just because
|
| Python: for the love of God [1] don't touch the version
|
| I wonder if the scar tissue will ever heal and we'll see a
| Python 4 in two decades.
|
| 1: https://www.youtube.com/watch?v=asUyK6JWt9U
| hnlmorg wrote:
| Probably not before a Perl 6
| sgarland wrote:
| K8s: the major version will never change, so instead we'll
| introduce breaking changes with minor versions.
| infamia wrote:
| > We may never see a 4.0 because of the scar tissue, but the
| language continues to evolve.
|
| They should do the opposite really. If it hurts, do it more
| often and get better at it. A perfect time would be when
| Python gets some nice JIT performance improvements which
| everyone will probably like.
| mananaysiempre wrote:
| I don't think there have been significant backwards-
| incompatible changes in Python 3 the language. There have been
| _some_ , e.g. async and await were first introduced as soft
| keywords and then switched to being actual ones. But that's not
| all that different from the treatment of yield in Python 2.
|
| (Recent stdlib changes have been much more destructive, but I'm
| assuming that, like in the original thread, we're drawing a
| distinction between those and changes to the actual language.)
|
| Full disclosure, I welcomed Python 3, because for me that was
| the first time (since 2.4 on Windows XP) that I could count on
| my programs not randomly shitting their pants upon encountering
| Cyrillic in files or filenames, which for a native speaker of
| Russian you can imagine is quite important. (The csv stdlib
| module in Python 2 did that, IIRC. Perhaps I was holding it
| wrong, but experience shows that absolutely everybody did.)
| echoangle wrote:
| I think basically every new python version removes some
| standard libs and marks new ones as deprecated (at least 3.13
| did), that's potentially breaking.
| zahlman wrote:
| The bytecode format changes, too, as does the C ABI
| (although they're making improvements on the latter front -
| there's supposed to be a more stable subset now). But more
| recently, they committed to a proper scheduling procedure
| for standard library deprecations and removals.
| wren6991 wrote:
| One that bit me was the change to StopIteration propagating
| through chained generators, following PEP 479. Nothing huge,
| but I had to patch some previously working code to
| accommodate the new language release.
| zahlman wrote:
| It's still amazing to me that the old `csv` module expected
| you to open the file in binary mode. (This was fixed in 3.1 -
| the 3.0 release was honestly quite premature.)
| pdonis wrote:
| _> This would be a backward-incompatible change_
|
| Yes, indeed it would.
| neuronexmachina wrote:
| Yes, from PEP 760's draft: https://peps.python.org/pep-0760/
|
| > This change is not backwards compatible. Existing code that
| uses bare `except:` clauses will need to be modified. To ease
| the transition:
|
| > * A deprecation warning will be issued for bare `except`
| clauses in Python 3.14.
|
| > * The syntax will be fully disallowed in Python 3.17.
|
| > * A `from __future__ import strict_excepts` will be provided
| to invalidate bare except handlers in earlier versions of
| Python.
|
| > A tool will be provided to automatically update code to
| replace bare `except:` with except BaseException:
| jmyeet wrote:
| I'm not a fan of this for two reasons.
|
| First, consider this motivation from the PEP:
|
| > Requiring specific exception types makes the programmer's
| intentions clear and encourages thinking about what exceptions
| might occur.
|
| This reeks of the same rationale for checked exceptions in Java.
| That was a failed experiment. You can't force people to deal with
| exceptions. They end up just swallowing them instead. It's better
| to propagate an exception than do that almost all the time.
|
| Like will we see except: replaced with except object:? I don't
| even know if that's valid. It's never come up.
|
| Second, this would be a breaking change. I really feel like this
| is where Python 3 went off the rails. In the Python 2 days making
| breaking changes was essentially verboten. But ever since Python
| 3 decided breaking changes were OK< it's like there's little
| restraint now and minor releases seems to be far too comfortable
| with this.
| paiute wrote:
| Exactly, python is not Java. I don't want it to be. There are
| perfectly good cases to catch all exceptions like this.
| williamsmj wrote:
| I'm weakly opposed to the PEP, but if your concern is that
| you're going to lose the ability to catch all exceptions in
| new code, then that's wrong as discussed in the Backwards
| Compatibility section, i.e. do "except BaseException".
| Scubabear68 wrote:
| You nailed it on both counts.
|
| Going back more than a quarter century ago (!), I was one of
| those zealots in favor of checked exceptions in Java. It took a
| good 15 years to finally conclude the "checked" part is more
| trouble than it's worth.
|
| Given that there is inevitably a root context for any given
| language invocation (main() for a command li program, top of a
| thread for a multi threaded app, etc), unchecked exceptions and
| a top level handler have proven to be more than enough.
|
| I won't comment on Python backwards compat, will just shake my
| head.
| cuuupid wrote:
| If I'm understanding this correctly this proposal would fully
| break compatibility with many (most?) codebases, actually remove
| syntactic sugar and force more characters for the same
| functionality. I fail to see how this is even being considered.
|
| I don't understand the idiomatic viewpoint either here, I
| understand the author personally finds it confusing when excepts
| aren't verbose but I think you would be hard pressed to find many
| python developers who agree. Even outside the ecosystem, most
| languages have been adding more support for bare excepts (like js
| with bare catch) so this feels like a step backwards.
|
| But maybe I'm just not understanding this proposal!
| Larrikin wrote:
| Python feels like they are fixing the language the best they
| can by slowly and properly adding explicit types. Character
| count is not a valid argument when we have hard drives that are
| multiple terabytes and IDEs and LLMs that will gladly auto
| complete a full word with the import. Foo, bar variable names
| and i, n incrementers should be banished to freshman level
| undergrad tests meant to intentionally confuse the student.
|
| I'm hoping Python 4 will be a big breaking change similar to
| the previous one and full support for explicit types will be
| one of the reasons.
| AlexandrB wrote:
| Character count is a valid argument because a human is going
| to have to _read_ the code at some point. Otherwise, Java
| style names like
| "countriesFromAsiaWhereAreTheMostPlanesAndBoats" would be
| just fine.
|
| Edit: I don't get the hate for "i" or "j" as increment
| variables. When you're working with numerical data they
| closely match how you would express the same operation with
| mathematical notation and are idiomatic to the point that
| everyone with non-trivial experience in programming knows
| what they represent. There are better options in some cases
| (e.g. "for name in names:"), but there's nothing inherently
| wrong with i, j, k, etc.
| Larrikin wrote:
| But that's a ridiculous example you're proposing in bad
| faith.
|
| I flag nearly all abbreviations in code reviews because
| code is meant to be read and the names of things should be
| clear.
| AlexandrB wrote:
| It's not in bad faith to say that there's a cognitive
| load to having longer line lengths or, god forbid,
| wrapped lines when you're trying to figure out what the
| code is actually _doing_ with that data the variables
| represent. Obviously the Python "except" case being
| discussed is not a big deal in this regard, but you made
| a blanket statement about character count being no big
| deal because of big hard drives and IDEs.
| lostdog wrote:
| How about abbreviating the 12 most common things in the
| codebase, but everything else is long?
|
| That's a nice compromise where you need to learn a few
| core concepts, but the code itself is easier to scan for
| bugs in a lot of places.
| umanwizard wrote:
| I work on code that uses `pid` pervasively, and it would
| drive me crazy if someone insisted I write out
| `processId` every time. Same with `tx` or `rx` for
| channel endpoints, `i` for loop variables, `txId` or
| `tid` for transaction ID in databases, etc. If something
| is very common in the domain you're working in it's more
| annoying _not_ to abbreviate it.
| Kim_Bruning wrote:
| In certain contexts, I'm ok with eg (off the top of my
| head):
|
| * x, y, z (coordinates)
|
| * r, g, b, a; c, m, y, k; y, u, v (colors)
|
| * i, j, k matrices and such
|
| * p, i, d; Kp, Ki, Kd in process control
|
| * rv (return value), where it is clear what The Thing To
| Be returned is.
|
| * common variables from eg physics
|
| Generally because these are well known and defined in
| particular contexts.
|
| I don't always make it, but sometimes an argument can be
| made that single letters are better known/recognizable by
| their single letter name.
|
| Compare:
|
| * total_energy = mass * light_speed_constant ^ 2
|
| vs
|
| * E=m*c^2
|
| Or:
|
| * process_control_setting = proportional_component +
| integral_component + derivative_component
|
| vs
|
| * q=p+i+d (for those of us who know PID control)
| fwip wrote:
| Recently, I saw somebody writing that in their projects,
| they define a Glossary.txt of terms, and then set up
| their tooling to flag any use of an identifier that isn't
| a word or defined in the Glossary. (Allowing also for
| compound words like camelCase and snake_case, of course).
| So in their project they could define `pid: process
| identifier [...]`, and then their tooling would be allow
| a variable named `new_pid`.
|
| Upsides: consistent vocabulary in your project, a
| centralized place to look up jargon, and a subtle
| friction to avoid adding new terms that people might not
| immediately grok.
|
| I wish I could remember the source; because it sounded
| like a nice setup to steal.
| kstrauser wrote:
| That "in the domain" bit is an excellent callout, and I'm
| stealing it.
|
| "Why don't you write out 'process_id'?"
|
| "Because the people who maintain the sort of code that
| cares about pids all refer to it as 'pid'."
| xorcist wrote:
| So you intentionally make code harder to read for most of
| the humans on this planet, so satisfy a desire to use
| longer identifiers?
| tsimionescu wrote:
| So your code is full of
| HyperTextTransferProtocolSecureClients, using a
| TransportLayerSecurityCertificate?
| NAHWheatCracker wrote:
| At my last job, there was a frontend developer who added a
| linter rule that variable names must be at least 2
| characters long. The project already had 20,000 lines of
| code. Every time anyone made a change to a file, they would
| have to rename all the one letter variables. Usually, this
| meant all the for loops in the file. I tried to explain how
| pointless this rule was, but he wasn't having any of it.
|
| Most people just renamed variables like i > ii, which was
| worse.
| morkalork wrote:
| What is even the point of digging in deeper, did they not
| see everyone around them doing the i>ii workaround?
| You've lost, call it a failed experiment and move on.
| tomrod wrote:
| Eye and Jay are go to as well
| johnny22 wrote:
| a good linter rule would have exceptions for loop
| variables by context by just by name like i, j, k. Often
| just by name is good enough at least for a solo dev or
| small team. I require them to be at least 3 chars EXCEPT
| those.
|
| For example: https://clang.llvm.org/extra/clang-
| tidy/checks/readability/i...
| gjvc wrote:
| >>> I'm hoping Python 4 will be a big breaking change similar
| to the previous one
|
| Python3 _did not break enough_ to justify the jump from 2 to
| 3, IMHO.
|
| >>> and full support for explicit types will be one of the
| reasons.
|
| Fair point!
| hyperbrainer wrote:
| It did though. Anything worse would be reminiscent of the
| Perl5->Perl6 disaster.
| klardotsh wrote:
| Python 3 broke almost literally every non-trivial Python
| file on earth, and was saved only by `2to3` and `six` being
| able to automate or library-ify away 75% or so of the
| changes. The remaining 25% was make-work for teams needing
| to avoid the deprecation/EOL/vuln demons (or wanting to
| take up new language features that became Py3-only), and
| many teams took the opportunity to instead spend that time
| rewriting their codebases in Go or TypeScript+Node.
|
| I don't know how much more breakage you really wanted out
| of Python 3 if "permanently scoured the public image of the
| language and caused many Python shops to, at least
| partially, stop being Python shops" wasn't enough.
|
| (I say this as a still-fan of Python who has written quite
| a lot of it and contributed to MicroPython/CircuitPython's
| internals - I just also worked at a Python shop during the
| Py2->3 hell, and frankly, even my current dayjob still
| talks about that transition as a nightmare to watch out for
| if any other language starts doing similar talk.)
| kstrauser wrote:
| My experience was different. The single biggest change I
| had to deal with in a zillion places was change of str
| from bytes to unicode. That wasn't just a syntax change.
| It forced me to chase down all the places where I'd been
| handling treating strings like bytes because it worked
| 99% of the time as long as I was only dealing with ASCII.
| No amount of clever AST re-writing would save me from
| those earlier mistakes.
| zahlman wrote:
| Python 3 made entire classes of errors impossible:
|
| * Beginners don't introduce ACE exploits into their
| program from the get-go, because `input` is what
| `raw_input` was before and the "convenient" wrapper using
| `eval` was no longer available - so instructors were
| forced to teach students about explicit type conversions,
| like they should have been doing the whole time.
|
| * You can't get `UnicodeDecodeError` from calling
| `.encode`, or `UnicodeEncodeError` from calling
| `.decode`, because you're never in the position of
| pretending that a sequence of bytes is a "string".
| There's no illogical "basestring" type and no `str`
| objects with ambiguous semantics - `.decode` and
| `.encode` do what they say, and belong to separate types.
| These problems resulted in a huge mess of duplicate Q&A
| on Stack Overflow full of incorrect advice from people
| with no clue what they were doing, and empowered people
| to ignore essential truths about Unicode until it blew up
| into a bigger problem.
|
| * Similarly, when you read from a text file, you actually
| get text now.
|
| * `print` used to be confusing and have weird ambiguities
| and tons of special syntax. Being a function means it can
| be taught the same way as any other function call; plus
| you get use as a higher-order function, unpacking
| operators (you can't do `print(*range(10))` in 2.x).
|
| * `1000000000 in range(1000000000)` no longer hangs.
| `xrange` _does not solve this problem_ (although it does
| improve matters quite a bit by avoiding high memory
| usage).
|
| * Sorting heterogeneous lists correctly produces an
| error, rather than an ordering so strange as to merit its
| own Stack Overflow Q&A
| (https://stackoverflow.com/questions/3270680 and many
| duplicates). (You can still replicate the old order if
| you want.)
|
| * `isinstance(x, int)` doesn't fail because of `x` being
| too large. This was a bizarre speed bump in such a high-
| level language.
|
| * You can write 'PS' in your source code and you only
| have to declare an encoding if you use something other
| than UTF-8 (which Python correctly identified as the
| eventual winner).
|
| When Python 3.2 came out I found it to be a breath of
| fresh air. By 3.4 I was already starting to wonder why so
| many others were dragging their feet on migrating.
| zahlman wrote:
| > Python3 did not break enough to justify the jump from 2
| to 3
|
| I agree - it should have broken more (and thereby become
| able to fix more). It should also have been usable out of
| the gate and not majorly reworked (there was a serious
| battle over the syntax of byte and string literals, and
| possibly some other things, that resulted in 3.0 and 3.1
| not seeing a full 5-year maintenance lifetime), and of
| course developers should have actually fixed stuff promptly
| and accepted that the obviously superior new ways of doing
| things were, in fact, obviously superior.
|
| Unfortunately, a lot of other developers don't seem to
| agree.
|
| And as for explicit types - I really wish people would stop
| trying to fight the type system - of Python, and of
| whatever other language. Python is not meant to support
| static types. It's not designed to reject your code at
| compile time for a type error and it isn't designed to take
| type information into account when generating bytecode.
| It's designed, instead, very explicitly, to let you care
| about what a given object can do, rather than about how it
| categorizes itself.
| gizmo wrote:
| Javascript somehow manages to grow without breaking backwards
| compatibility. So does C++. Breaking countless packages (and
| forks of packages) in the pursuit of something as nebulous as
| language purity is a big mistake. I happen to like explicit
| typing but it's not the kind of thing you can graft onto a
| mature language without making awful compromises. Also, it
| pushes massive externalities onto the millions of people who
| rely on Python for their work.
| jerf wrote:
| By the time you've written a Python that has all explicit
| types in it, and harvested the speed advantages the
| interpreter can have when it can count on that, and all the
| other cascading changes that would result, and the fact that
| you would discard 100% of all previous modules both Python
| and C, you might as well just start using one of the existing
| statically-typed languages that already has a mature
| ecosystem.
|
| Python should be working on being the best Python it can be,
| not being an adequate Python and an inadequate bodged-on
| static language on the side.
| akkad33 wrote:
| > harvested the speed advantages the interpreter can have
| when it can count on that,
|
| Does the interpreter actually optimize code based on type
| information? My knowledge is that it does not
| jerf wrote:
| Python 3 does not, but the hypothetical Python 4 would be
| crazy to put types on everything and then not accelerate
| its interpreter with the resulting data.
|
| The problem Python 3 has is dynamic types, as the
| dynamically-typed languages implement them, are viral;
| one little crack lets them in somehow and all the code
| operating on the data has to assume it's viral.
| morningsam wrote:
| CPython doesn't, but there is Mypyc [1] which compiles
| statically typed Python to faster C extensions leveraging
| the type information. As usual, this comes with tons of
| limitations [2]
|
| [1]: https://mypyc.readthedocs.io/en/stable/
|
| [2]: https://mypyc.readthedocs.io/en/stable/differences_f
| rom_pyth...
| Chris2048 wrote:
| > I'm hoping Python 4 will be
|
| I'm hoping "Python 4" will be another language entirely that
| displaces it, Fixing some ecosystem problems upfront
| (packaging, concurrency/GIL). Nim is possible candidate,
| though Go is pretty popular w/ Pythonistas.
|
| My personal unhappiness with how Py3K was handled, plus
| recent PSF events make me feel new leadership would also be a
| boon..
| cb321 wrote:
| I have found Nim more useful/usable than Python + Cython
| since about 2014 for my personal use cases and almost
| always much more efficient on a "per unit of effort basis"
| than Go. At least if you are willing to write whatever code
| you need or link in C/C++ instead of relying on people
| gifting it to you.
|
| I think the ecosystem leadership position Python finds
| itself in lately may well make Py-core silly enough to
| think "our users will tolerate our breaking-all-their-code
| antics no matter what". I suggest a more consenting-adults
| alternative here:
| https://news.ycombinator.com/item?id=41790766
| zahlman wrote:
| FWIW I've been semi-actively designing a language of that
| sort, which I call Fawlty, since about February of this
| year. I was planning to start writing about it in July but
| then all the PSF drama stuff happened and I didn't want
| people to assume incorrectly that the idea was motivated by
| my disappointment with the community.
|
| In fact, I'd been thinking about doing it since probably
| November of the previous year - and it's motivated by long-
| held beliefs that
|
| Python's design falls short of the Zen;
|
| several of the most common beginner pitfalls could and
| should be avoided by syntax changes and by a different
| approach to parsing the code; and
|
| the standard library is full of ancient APIs that look
| terrible because they're motivated by C and Java designs
| that used to be the best we had but seem highly unidiomatic
| now.
|
| It was somewhere in November or December last year that I
| first wrote those thoughts down more concretely (with
| details about what those pitfalls are etc.).
|
| Given that pace of progress, however, I've more or less
| given up on ever expecting myself to publish something
| usable - by myself, at least. I've decided for now that it
| will be more practical to add blog posts about my ideas to
| the queue, and possibly see about my own implementation
| later.
| bryanlarsen wrote:
| > I'm hoping Python 4 will be a big breaking change similar
| to the previous one and full support for explicit types will
| be one of the reasons.
|
| History shows that's a good idea if and only if you use a new
| name for the new language.
|
| cf Python 2 -> 3, Perl 5 -> 6 -> Raku, Javascript ->
| Typescript
|
| You can keep Python as part of the name. Call it SuperPython
| or something. Just don't call it Python 4.
| dataflow wrote:
| > force more characters for the same functionality
|
| This is actually a good thing in some cases (possibly this
| one). Risky stuff should inherently be harder to do than safer
| stuff, otherwise people will reach for the risky alternatives
| when they don't need to, just to save time - or because they
| don't realize the risk.
|
| Or at least, that's often the case. What's lacking here is
| evidence that this is actually happening. I can believe it, but
| evidence is necessary for breaking the language.
| phkahler wrote:
| >> I fail to see how this is even being considered.
|
| To me it stinks of an ego-centric person thinking they're a
| "language developer" and knowing better than the actual users
| of the language what's best for them. Just because something
| can be misused doesn't mean you have to take it away.
|
| I haven't noticed, but since Rust came along is there a trend
| among languages to enforce "safer" programming at the language
| level? I could see that kind of thinking getting way out of
| hand. If that's the case, I would see this one as "I'm going to
| save the world with this dumb little change that breaks things
| for a bunch of people!"
|
| I would hope a PEP like this came about from frequent user
| requests but that doesn't seem to be the case.
| gmueckl wrote:
| Rust had extremely successful marketing based on its security
| claims. It's no surprise that other languages jump on that
| bandwagon to not get left behind, is it?
| slt2021 wrote:
| can these language improvements be implemented at linter
| level?
|
| so that people can opt-in or opt-out selectively, per their
| own discretion, for these kinds of rules
|
| I dont see the point of this being part of the language since
| it break compat and brings zero benefits at runtime
| 0cf8612b2e1e wrote:
| In the PEP, some of the comments noted this was basically a
| linting issue. No reason to break the language over it.
| willcipriano wrote:
| Flake8 already provides this for anyone concerned about it.
|
| https://www.flake8rules.com/rules/E722.html
| strunz wrote:
| So does pylint which has been there forever https://pylin
| t.pycqa.org/en/latest/user_guide/messages/warni...
| akkad33 wrote:
| Linters already flag this as error
| sestep wrote:
| It's interesting that you mention Rust, since Rust takes
| backward compatibility quite seriously; that's why it's still
| on version 1.x. Granted, sometimes there is a compiler bug
| that causes some old code not to compile with newer versions
| of Rust, but that is rare and never intentional like this
| PEP.
| umanwizard wrote:
| They do take it seriously, I agree. However, the commonly
| repeated meme that Rust only makes backwards-incompatible
| changes by mistake or to fix soundness issues is wrong.
| They allow themselves to make changes if they're judged to
| have a low (but nonzero) risk of causing backwards
| incompatibility in the wild. For example, adding a new
| function to a standard trait can be backwards incompatible
| but they do it all the time.
| kibwen wrote:
| Indeed. Although it's worth noting that the same is true
| of e.g. stable enterprise favorites like Java, which
| regularly makes minor breaking changes that are judged to
| have little impact (which is why every Java release is
| accompanied by a compatibility guide; see the "Important
| Changes", "Removed Features", and "Other Notes" sections
| of the most recent release notes: https://www.oracle.com/
| java/technologies/javase/23-relnote-i...).
| phkahler wrote:
| >> It's interesting that you mention Rust, since Rust takes
| backward compatibility quite seriously;
|
| I mentioned Rust because the memory safety guarantees are a
| significant new thing for a language like that. I forgot
| about "managed" languages like C# because that's quite far
| from my mind, but that's another significant attempt at
| safety. This kind of little detail in the PIP is really
| insignificant by comparison, so I was speculating that it
| might be driven by some kind of "save everyone" mentality.
| If so, wondering if that's a trend lately and I hadn't
| noticed.
| jbiason wrote:
| (Just to be sorta pedantic) I don't think it's the version
| 1.x that promotes backward compatibility, but editions.
|
| In 2016, you could call your function `fn async(...) { ...
| }` without any issues, and you can still compile this code
| with the modern version of rustc. If you want to use the
| async features of Rust, you need to change your edition to
| at least 2018, which brings breaking changes in the
| language.
|
| And you can have a project that mixes those editions, and
| cargo will correctly use the edition asked for each crate.
|
| (So, I guess the ideal world would to first look at the
| package management in Python, and *then* try to introduce
| breaking changes. And I'm withholding how much I'm angry at
| the PSF for postponing having a decent package manager for
| 20 years and investing in removing the GIL and adding JIT.)
| 0cf8612b2e1e wrote:
| Not meaning to apologize for Python here, but you have
| significantly more ability to segregate "editions" when
| you statically compile code.
|
| All the more reason to take a breakage very seriously.
| This is even worse than the walrus operator. At least I
| can ignore that. This breaks working code for some notion
| of purity.
| roblabla wrote:
| Code compilation doesn't really have much to do with it.
| Python already has a somewhat similar ability - opting
| into certain language features of python on a file-by-
| file basis - using __future__[0]. It'd be pretty easy to
| add something like Rust editions by looking for a special
| statement in the file. And to make it more convenient,
| put it in the __init__.py and have it be transitive to
| the module.
|
| [0]: https://docs.python.org/3/library/__future__.html
| drdaeman wrote:
| > And you can have a project that mixes those editions,
| and cargo will correctly use the edition asked for each
| crate.
|
| I'm curious - if you had a `pub fn async(...){...}` in
| some 2016 crate, can you still call it from a 2024
| codebase?
| Lorak_ wrote:
| You can: https://doc.rust-lang.org/rust-by-
| example/compatibility/raw_...
| drdaeman wrote:
| Wow, this is nice and looks well thought out. Thank you!
| umanwizard wrote:
| There have been people trying to enforce safer programming at
| the language level at least since Java positioned itself as
| the safer alternative to C++ way back in the 90s.
| riffraff wrote:
| I'm pretty sure Bertrand Meyer's OOSC[0] from 1988 had
| something like "if a language has a feature which comes
| with warnings that you shouldn't use it, it shouldn't have
| that feature" (paraphrasing).
|
| [0] https://en.wikipedia.org/wiki/Object-
| Oriented_Software_Const...
| pca006132 wrote:
| No. A serious language designer will try to make things they
| like at the beginning, not trying to patch it later. Patching
| via breaking public API (language design) is never a good
| thing.
| phkahler wrote:
| >> A serious language designer....
|
| That's why I put "language developer" in quotes.
| beeboobaa3 wrote:
| Let me just grab my time machine and go back 40 years
| chefandy wrote:
| PEP contains lots of best practices that aren't enforced by the
| interpreter though, doesn't it? e.g. PEP 8. It's been a while
| so maybe PEP 8 is more unique than I realize? It seems like a
| pretty sensible recommendation that wouldn't necessarily need
| to change the way exceptions are handled by Python. Right there
| in PEP 8 it says in big text "A Foolish Consistency is the
| Hobgoblin of Little Minds." I imagine that enforcing this in
| the interpreter would fall under that, but it seems like a good
| piece of advice for folks new to the language, or more likely,
| new to coding.
| kristjansson wrote:
| There are PEPs that are not language features, but this PEP
| is emphatically proposing a modification to the language.
| theamk wrote:
| No one would anyone would object if this was a "best
| practice" or "linter rule".
|
| It's the enforcement by compiler, which will break lots of
| existing code, that makes people unhappy.
| amelius wrote:
| I do have to say that this fun little scripting language is
| starting to look more and more like a serious compiled
| language.
| zahlman wrote:
| Python is compiled to bytecode just like Java and C# - it
| just also happens to provide an environment out of box that
| will do it on the fly, and makes it much easier to access the
| "compiler services" in the standard library (and the built-in
| `eval`). And it's always been that way. The idea that some
| languages are "serious" and others are not is already
| suspect. The idea that being a "serious" language requires
| being "compiled", or that other languages are just for
| "scripting", will severely limit you as a developer.
| thiht wrote:
| I love using the bare except in small 1-file scripts, it just
| does the job elegantly
| zahlman wrote:
| >actually remove syntactic sugar and force more characters for
| the same functionality. I fail to see how this is even being
| considered.
|
| Python is not APL. Getting at the functionality in fewer
| characters is not a design goal - it's just a usually
| consequence of the actual design goal.
|
| This is being considered because "Explicit is better than
| implicit." and because it helps avoid a common class of error
| (e.g. `except: continue` prevents aborting a loop with Ctrl-C,
| which is often not intentional).
|
| Or as the PEP puts it:
|
| > While this syntax can be convenient for a "catch all"
| handler, it often leads to poor coding practices: > > 1. It can
| mask important errors that should be propagated. > 2. It makes
| debugging more difficult by catching and potentially hiding
| unexpected exceptions. > 3. It goes against the Python
| principle of explicit over implicit.
|
| Python isn't any other language, either. It _certainly_ isn 't
| taking design guidance from JavaScript (which runs in an
| environment where the page is expected to show something
| coherent, and not a loud screaming error, no matter how absurd
| the input data and/or code).
|
| As for how much code it would break, you made me curious:
| ~/Desktop/dev$ find . -name "*.py" | wc -l 49433
| ~/Desktop/dev$ grep --include='*.py' -rnw . -e 'except.*:' | wc
| -l 109801 ~/Desktop/dev$ grep --include='*.py'
| -rnw . -e 'except:' | wc -l 5692 ~/Desktop/dev$
| grep --include='*.py' -rnw . -e 'except[ \t]*:' | wc -l # just
| to make sure 5692
|
| But drilling down further, over 2/3 of those bare excepts are
| in local copies of Python itself (i.e., multiple versions of
| the standard library) that I built from source. Probably all
| the rest are in dependencies. I don't write code like that
| myself if I'm even remotely paying attention. (Of course, that
| only tells me how many _occurrences_ there were, not how many
| files have them. But the first two results imply an average of
| about 2 `except`s per file, so.)
| 01100011 wrote:
| I don't know, but it seems like, as a language grows, the type
| of people working on improvements changes. In the beginning,
| the contributions come from people trying to solve application
| problems. In the end, the committees and contributors seem to
| be less connected to reality and more internal and isolated.
| They make changes that seem conceptually sound but aren't
| grounded in what the users of the language actually care about.
| peterhadlaw wrote:
| What does Tim Peters think about this change?
| williamsmj wrote:
| We may never know
| https://news.ycombinator.com/item?id=41234180.
| drcongo wrote:
| [ranier-wolfcastle-that's-the-joke.jpg]
| hyperion2010 wrote:
| 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 wrote:
| 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 wrote:
| Does that even require an LLM? It should be possible through
| traditional static analysis.
| pansa2 wrote:
| Everything requires an LLM nowadays.
| DrillShopper wrote:
| Especially if you want to get funding
| diggan wrote:
| > It should be possible through traditional static analysis
|
| Even better/worse, could do it with regex on text streams.
| sdenton4 wrote:
| There'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 wrote:
| From the PEP:
|
| > A tool will be provided to automatically update code to
| replace bare except: with except BaseException:.
| instig007 wrote:
| 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 wrote:
| I propose to call this tool 3to760, in memory of 2to3.
| hawski wrote:
| 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.
| zahlman wrote:
| I 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 wrote:
| 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.
| pansa2 wrote:
| > _like most Python programmers it 's not my "day job" to
| write Python code_
|
| I'd love to know whether that's true, and to what extreme.
| I believe you're right - that people using Python for a few
| hours a week (or less) greatly outnumber software
| developers using it as their primary language.
|
| I think that's a real issue for the evolution of Python,
| because updates to the language design (e.g. the makeup of
| the Steering Council) come almost entirely from the second
| group.
| mannykannot wrote:
| 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.
| zahlman wrote:
| >If your goal is a system in which all exceptions are
| explicitly and appropriately handled, your first mistake
| was picking Python.
|
| No, the goal is a system in which the code correctly
| indicates which exceptions it's intended to handle, and
| doesn't accidentally handle the wrong exceptions because
| the developer was either lazy or misinformed about the
| semantics (perhaps due to experience with a different
| programming language).
| a-french-anon wrote:
| Quickly read the thread, isn't "hours" a bit much for what is
| basically a sed -Ei 's/^([\t ]*except):/\1
| BaseException:/' **/*.py
| instig007 wrote:
| now try delivering that change to all of your dependencies
| before being able to deploy your software with a new
| interpreter.
| fny wrote:
| Not that I support the PEP but they could easily add an
| interpreter flag or environment variable to disable the
| behavior.
| Joker_vD wrote:
| Will this command be automatically run by venv, or poetry, or
| whatever, on every package update?
| himinlomax wrote:
| Multi-line strings don't exist.
| shadowgovt wrote:
| Definitely going to want to use Tree-sitter, not regex. That
| regex just broke my docstrings.
| diggan wrote:
| 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 wrote:
| That version will eventually become EOL, stop getting
| security patches, eventually stop compiling with the latest
| OpenSSL, etc. Bitrot.
| diggan wrote:
| Does 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 wrote:
| Old 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 wrote:
| > 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.
| dumpsterdiver wrote:
| When the qualifier is "granted you don't expose that code
| to the internet" then yes, it matters.
| diggan wrote:
| Who finds "old scientific code" and then exposes a server
| running that code to the internet without any changes?
| Sounds like asking for trouble, but I guess we all use
| computers differently...
| zahlman wrote:
| Either software is updated or it isn't. If you're worried
| about "bitrot" then you bear the responsibility for your
| end of keeping the system up to date. (Or finding a third
| party to do it.) API Changes occur for a reason, and it
| isn't reasonable to expect other developers to make
| security fixes to their older versions of code in
| perpetuity while guaranteeing that stable interface in
| perpetuity. They'd never get to fix anything that _isn 't_
| a security issue that way. Programmer resources are limited
| - especially for Python, which doesn't pay the overwhelming
| majority of its devs (although it can afford to pay several
| PSF staff).
|
| Python is open source. Nothing prohibits you from forking
| the 2.7 codebase and adding your own security patches (or
| more substantial things like back-porting new OpenSSL
| support, or even cherry-picking backwards-compatible
| features from 3.x that you do like), for example.
|
| I'm happy when people criticize new features in Python. But
| I expect to read criticism of features based on their
| actual merits and consequences, not on the principle that
| it's new or backwards-incompatible or would cause "churn".
| discretion22 wrote:
| > 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 wrote:
| As someone who doesn't follow the language, which recent
| events are you referring to?
| behnamoh wrote:
| 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 wrote:
| 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 wrote:
| Elixir's 'pipes' always felt very hacky to me. (But so
| does most of the language, compared to Erlang.)
| behnamoh wrote:
| 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.
| btown wrote:
| 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!
| kristjansson wrote:
| 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 wrote:
| 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 wrote:
| It wasn't recent by Internet time but when the debate on
| walrus operator drove out the BDF _L_ 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 wrote:
| Just as a reminder, the BDFL supported the "walrus
| operator" and co-authored the PEP for it.
| Narhem wrote:
| 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.
| yunohn wrote:
| > destroying the ability to run old scientific code
|
| TBH that kind of code barely survives minor Python version
| upgrades in my experience.
| setopt wrote:
| 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 wrote:
| With that PEP you can still do a quick "try: except:" it's
| just spelled "try: except Exception:"
| dataflow wrote:
| > warning every time an unspecific exception is caught
|
| Caught _and not re-raised_
| shadowgovt wrote:
| Anything popular is going to attract an increasingly high-
| variance group of engineers. With such variance comes such
| PEPS.
| northernman wrote:
| 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.
| kstrauser wrote:
| 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 wrote:
| 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.
| cortesoft wrote:
| 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
| plesner wrote:
| 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?
| new_user_final wrote:
| This person should be removed from the Steering Council Member.
| What an insane proposal.
| Waterluvian wrote:
| The existence of two opposing PEPs says to me that there may be a
| case to be made for either side, so we should default to not
| changing things.
|
| I used to think it's likely that you can make a much stronger
| case for one side, but I personally feel that's more for early
| language development phase. If it's been a certain way for a long
| time, it ought to be overwhelmingly obvious and overwhelmingly
| supported by the community to change it. And even then I feel a
| bit of doubt.
| williamsmj wrote:
| If you're referring to this PEP's "twin", i.e. "PEP 758 - Allow
| except and except* expressions without parentheses", that is
| not an opposing PEP. These two PEPs are orthogonal. One does
| not contradict the other. They are twins only in the sense that
| they are both about exception handling syntax.
| Waterluvian wrote:
| I'm trying to find it but I thought there was a PEP
| specifically about the relaxed behaviour of except. I might
| be wrong here.
| saikia81 wrote:
| Python errors are a mess. It's no surprise people overuse bare
| except clauses. Disallowing them is not the solution we need.
| dopylitty wrote:
| They really are hard to work with compared to languages where
| you declare which exceptions you'll throw,. I always get angry
| when pylint raises an error for catching over-broad
| exceptions[0]
|
| Of course I'm catching broad exceptions because I have no idea
| what kind of exception is going to be thrown 12 dependencies
| deep and I don't want it to completely crash the program
| instead of letting me retry or do something else.
|
| 0:https://pylint.readthedocs.io/en/stable/user_guide/messages/.
| ..
| byb wrote:
| 100% agree. Most of my bare except: are followed by import
| pdb;pdb.set_trace() so I can figure out what went wrong and
| then fix my code so that it never happens again, but I still
| leave it there because I I don't have time to consider the
| millions of ways my hastily thrown-together python script is
| going to fail nor do I want to game out how many different
| errors could happen. If Python would have been this hard to
| use 20 years ago, I wouldn't have been able to learn to
| program.
| dmart wrote:
| Yup this drives me crazy. I've been bitten by urllib3 or SSL
| exceptions being bubbled up by random libraries so many times
| that now I always include an except Exception: block just in
| case.
| joshkel wrote:
| Interesting.
|
| The way I was taught Python, you really, really don't want to use
| bare `except:`, because it catches _everything_: Ctrl-C
| interruptions, system exit, etc. Instead, you really ought to use
| `except Exception:` (where `Exception` is the base class for any
| "normal" runtime error).
|
| So I definitely understand the rationale, but it's hard to say
| it's worth the pain of backward incompatibility - we have
| linters, style guides, etc. that can catch this.
| wild_pointer wrote:
| Yes, I was bitten by it in the past. Still, it'd better be a
| lint, or at least a very very long deprecation period... like,
| deprecated and removed in Python 4 or something.
| shadowgovt wrote:
| Having your linter catch `except:` is both simpler and
| cleaner than changing the language.
| dtech wrote:
| Deprecating without removing ever seems reasonable
| dimator wrote:
| absolutely, this should not be done at the language level. the
| language should not enforce "best practices", that's what the
| ecosystem is for.
| OscarCunningham wrote:
| One example of a time I used a bare except was when I wanted a
| program to retry three times if it failed for any reason. I just
| wrapped everything in a for loop with a catchall except.
|
| The problem occurred when our scheduling program (Airflow)
| noticed the program was taking too long to run and decided to
| kill it. It sent a kill signal to Python, which dutifully caught
| the exception, retried and continued to run. I had to add a
| special case to allow Airflow to kill the program.
|
| This PEP just forced me to look up the difference between the
| classes Exception and BaseException. It turns out that
| BaseException includes every exception, whereas Exception
| excludes those that are trying to exit the program (like
| SystemExit and KeyboardInterrupt).
| williamsmj wrote:
| With a bare except, your code will continue to retry even if
| SystemExit or KeyboardInterrupt is raised. This is almost
| always a bug.
|
| In other words, your comment is an argument _for_ the proposal!
|
| I don't think it's a good _enough_ argument to make a backwards
| incompatible change. This is a wart Python has to live with
| now. But I do think it 's a shame that bare excepts behave in a
| way that is almost always a bug.
| bee_rider wrote:
| Maybe bare excepts could be modified to just catch
| Exceptions. It seems like a reasonable expression of the
| idea: everything that could go with my program but not with
| the OS.
| williamsmj wrote:
| Personally I think that would have been a better choice in
| Python's original design, but to change it now would be a
| backwards-incompatible change, i.e. it suffers from the
| same big problem everyone is highlighting in the PEP.
| kstrauser wrote:
| That seems less bad in the sense it would affect fewer
| people, but the ones it did affect would likely be much
| more strongly affected. For instance, I could imagine
| someone with an old daemon that had a too-level loop like:
| while True: try: serve()
| except: log('oops')
|
| so that it was more or less bulletproof. This might be a
| highly unpleasant change for those people who counted on it
| running 24/7 and never dying.
|
| In other words, the current behavior is a minor hassle for
| many people. That change would be a major hassle for a few.
|
| I'd be all for a deprecation warning on bare excepts. That
| might nudge a lot of people to fix their code without
| actively breaking anything.
| williamsmj wrote:
| > I'd be all for a deprecation warning on bare excepts.
| That might nudge a lot of people to fix their code
| without actively breaking anything.
|
| The PEP proposes a deprecation timeline for exactly this.
| pansa2 wrote:
| In terms of "break everyone's code for no good reason", this
| proposal is comparable to the removal of the `print` statement.
| kstrauser wrote:
| At least that one was beneficial in the long run. It had clear
| advantages beyond purity.
| graemep wrote:
| This reeks of "our users are idiots and we need to keep them away
| from sharp edges".
|
| A bare except is something to be flagged up by tools, not
| disallowed by the language. It is definitely not worth a
| backward-incompatible change.
|
| I am slowly going off Python.
| forgottofloss wrote:
| "our users are idiots and we need to keep them away from sharp
| edges" is exactly what keeps driving me away from Python and
| pip. It's why I wrote https://pip.wtf -- Python package
| management would be so simple if they'd just stop adding more
| and more seatbelts and cushions to Python.
| rurp wrote:
| No kidding about pip. The dependency resolver change several
| years ago was a similar terrible move to the PEP being
| considered here. It broke so much legitimately working code
| for no good reason; just paternalism from the core devs. The
| change pushed my team to stop using pip at all for dependency
| management.
| kstrauser wrote:
| Hard disagree there. It was way too easy to get yourself
| into an incompatibility hell with the old resolver, where
| package A relied on transitive dependency X v1.2 and
| package B needed X v2.1. Which version of X you got
| depended on whether you installed A or B first.
|
| Yes, the new version _did_ mean I had to straighten out a
| few projects that were already working before, but they
| were working by coincidence because my code paths weren't
| stumbling across the incompatibilities. The problem already
| existed. The new resolver just exposed it.
| rurp wrote:
| My case was different from yours. Our project wasn't
| working by coincidence, the dependency resolver was
| flagging incompatibilities that simply didn't apply to
| our case, and began refusing to build a stable working
| project. Yes it's more risky to override that kind of
| guardrail, that's why I would only do it when I know the
| risks and tradeoffs and determine it's the best course of
| action on balance. I strongly believe that tools should
| ultimately work for the user, over dogmatic principles.
|
| I'm fine with the those safety guardrails being the
| default behavior, but removing any sort of escape hatch
| because the pip devs think that they know better than the
| users of the tool 100% of the time is what I object to.
|
| In the end we ended up ditching pip entirely for this use
| case and ended up with a much better system, with
| absolutely no disasters as a result, but we had a burn a
| lot of time and angst that could have been spent on
| actual problems we were trying to solve.
| kstrauser wrote:
| Asking out of curiosity, not to insinuate that "you were
| holding it wrong". The docs at
| https://pip.pypa.io/en/stable/user_guide/#resolver-
| changes-2... say:
|
| > If you don't want pip to actually resolve dependencies,
| use the --no-deps option. This is useful when you have a
| set of package versions that work together in reality,
| even though their metadata says that they conflict. For
| guidance on a long-term fix, read Dealing with dependency
| conflicts.
|
| Did that not work?
| kstrauser wrote:
| For others stumbling across this, the idea was considered in
| PEP 722 (https://peps.python.org/pep-0722/) and is supported
| today by uv
| (https://docs.astral.sh/uv/guides/scripts/#declaring-
| script-d...).
| morningsam wrote:
| Not just considered in PEP 722 - the uv feature is just an
| implementation of PEP 723 [1] (PEP 722's
| successor/competitor), which was accepted. Other tools like
| pipx support it as well.
|
| [1]: https://peps.python.org/pep-0723/
| kstrauser wrote:
| Oh! So it was. If I ever remembered that those were
| separate PEPs, I'd forgotten it.
| zahlman wrote:
| "seatbelts and cushions" is not how I'd describe a package
| manager that can run arbitrary code from the downloaded
| package when you explicitly tell it "please only download
| this", simply because it wants to verify that building it
| will result in it having name and version metadata that
| matches what you asked for
| (https://github.com/pypa/pip/issues/1884).
|
| This is not fixed in 24.2 btw, even if you do everything
| according to the latest standards - you're still allowed and
| expected to _have_ a setup.py if you choose Setuptools as
| your backend and you release an sdist with a non-trivial
| build step. 24.3 should be out some time this month and I 'll
| be interested to see if they've finally done something about
| this issue, which has existed for almost the entire lifetime
| of Pip.
| wiz21c wrote:
| Let me check, we're not the first of April, are we ?
| bjourne wrote:
| As others have stated this idea is gratuitous breakage. Hope it
| won't become reality.
| aftbit wrote:
| One must imagine Sisyphus happy. Python just loves to break
| working code on a regular basis with its new releases. If your
| code is protected from untrusted user data and the internet,
| Python 2 is actually a really nice language that doesn't
| constantly force rewrites.
|
| Oh, you want to know the naive UTC datetime in Python, to
| interface with something like PostgreSQL that recommends naive
| times? Back in the old days, a simple datetime.datetime.utcnow().
| Now days, you need something like: try:
| from datetime import UTC as tz_UTC except ImportError:
| from pytz import UTC as tz_UTC dt =
| datetime.datetime.now(tz_UTC).replace(tzinfo=None)
| bigstrat2003 wrote:
| > If your code is protected from untrusted user data and the
| internet, Python 2 is actually a really nice language that
| doesn't constantly force rewrites.
|
| If Python 2 is acceptable for your use case, then you could
| stay on an old version of Python 3 just fine as well.
| echoangle wrote:
| I think the point was making sure that code won't break in
| the future. If you tell someone ,,use python 2 to run my
| script", you know it's going to work basically forever
| because the latest python 2 won't be changed. That's not true
| for python 3. I still think it's a bad argument, but that's
| what I understood the idea as.
| cdrini wrote:
| That argument still seems inconsistent to me, since saying
| "use python 2, pin your dependences and never upgrade
| python so your script runs forever" is the same as "use
| python 3.12, pin your dependences and never upgrade python
| so your script runs forever".
| echoangle wrote:
| Well you can't update python 2 so there is nothing to pin
| kccqzy wrote:
| No you can't. For example I use a script to compress scanned
| PDFs by combining individually processed JBIG2 images and
| that script hasn't been updated for more than a decade:
| https://github.com/agl/jbig2enc/blob/master/pdf.py It works
| and generates perfectly good PDFs. No it doesn't work with
| Python 3 because it mixes bytes and strings copiously. I
| could spend half an hour upgrading it to work with Python 3
| but there's no reason to.
|
| Don't forget the whole reason why Python 3 exists is because
| it broke compatibility with Python 2. Plenty of old
| unmaintained scripts were forever stuck in Python 2. Not to
| mention an old version of Python 3 actually performs worse
| than Python 2.
| aftbit wrote:
| Well I'd be careful, that's a classic example of untrusted
| user data.
| kccqzy wrote:
| Nothing is untrusted. I trust my own scanner. It's just
| that it produces files that are too large. And when it is
| told to reduce file size, it reduces resolution instead
| of using good compression.
| zahlman wrote:
| > I could spend half an hour upgrading it to work with
| Python 3 but there's no reason to.
|
| How about empowering people other than yourself to
| understand how the code works, rather than relying on them
| to decipher the precise way in which you "mixed bytes and
| strings copiously"?
|
| What if someone else did it for you? Would you reject the
| PR on principle?
| instig007 wrote:
| > Oh, you want to know the naive UTC datetime in Python, to
| interface with something like PostgreSQL that recommends naive
| times?
|
| Postgres never recommended naive datetimes. A TZ-aware datetime
| is semantiacally the same as a tuple of (<location/agreed
| offset>, <time in the moment since unix epoch defined in terms
| of UTC>). Those who recommended dropping the knowledge of the
| first part from that pair did it because they didn't know
| better.
| codr7 wrote:
| It's a perfectly fine strategy in some situations to only
| store UTC in the database and handle time zones on display.
| It's your database, you know what's in there. As an added
| bonus it allows easily flagging non-UTC timestamps as errors
| on some level to make sure you don't get tangled up in time
| zones.
| hauntsaninja wrote:
| You don't need to use pytz, you can use the following on all
| Python 3: tz_UTC = datetime.timezone.utc
| torginus wrote:
| will this be one of those wonderful changes that will make most
| python programs unrunnable on contemporary versions of python?
| bee_rider wrote:
| They explicitly describe the PEP as evil, is there a tradition in
| the Python community for having obviously terrible PEPs, just to
| document the reasons for not doing something? Because that would
| make this a lot more understandable.
| arp242 wrote:
| If it's not a serious proposal then that's even worse, because
| there's a long discussion on that thread. So this non-serious
| proposal is just wasting people's time.
| eesmith wrote:
| There is PEP 666. https://peps.python.org/pep-0666/
|
| > I figure if I make this PEP, we can then ask Guido to quickly
| reject it, and then when this argument next starts up again, we
| can say 'Guido isn't changing things to suit the tab-haters or
| the only-tabbers, so this conversation is a waste of time.' ...
|
| > This proposal, if accepted, will probably mean a heck of a
| lot of work for somebody. But since I don't want it accepted, I
| don't care.
|
| I don't know if there are others.
| veggieroll wrote:
| Genius-level risk taking
| bee_rider wrote:
| Kinda yah, I mean, it seems like it is getting a strong
| negative response based on the poll.
| jjice wrote:
| This was on April Fool's Day, but the roman numeral constants
| PEP always gives me a laugh https://peps.python.org/pep-0313/
| bee_rider wrote:
| > Any literal composed entirely of M, D, C, L, X, V and I
| characters that does not follow this format will raise a
| syntax error, because explicit is better than implicit.
|
| Good as a reminder that rules like "explicit is better than
| implicit" should not be followed all the way to the most
| absurd possible conclusions.
| sundarurfriend wrote:
| "the evil twin of PEP 758: Allow `except` and `except*`
| expressions without parentheses"
|
| They're using "evil twin" in the sense of "it's closely related
| to 758, but goes in the opposite direction to it".
| williamsmj wrote:
| I have mixed feelings about this.
|
| There are two "problems" this PEP is trying to solve.
|
| One is that bare excepts are permitted. The argument against this
| is that explicit is better than implicit. A matter of taste, but
| I don't find this convincing.
|
| The other problem is what bare excepts _mean_. Bare excepts are
| syntactic sugar for `except BaseException`. This means that an
| application containing a bare `except` followed by the vast
| majority of real-world error handling will continue to run even
| if SystemExit or KeyboardInterrupt is raised. This is almost
| always a bug.
|
| I _do_ find this second argument convincing, and I wish Python
| did not contain this design wart.
|
| If I could go back in time and change Python syntax, it would
| make it hard for people to silently treat these special
| interrupts as "handleable" like regular errors. The tiny set of
| applications that really can and should handle them (e.g. TUIs or
| the mailman example discussed in the final section of the PEP)
| can explicitly do so with e.g. `except KeyboardInterrurpt` or
| even `except BaseException`.
|
| But I agree with the consensus here that this does not rise to
| the level of something being worth a backwards-incompatible
| change.
| theamk wrote:
| Disagree. I do this kind of code all the time:
| try: something() except:
| log_tons_of_debug_info() raise
|
| and I am very glad that I get my debug info works even if I
| press Ctrl-C or someone calls sys.exit().
| bee_rider wrote:
| I dunno, this just usually means I'm going to hold control
| and mash C, hopefully I can get my interrupt to occur inside
| your except
| rcxdude wrote:
| That's unecessary, because of the 'raise' statement. This
| construct effectively only hooks exceptions, it doesn't
| swallow them.
| encoderer wrote:
| Signals are non-reentrant.
| theamk wrote:
| You know about Ctrl-\, right? Kills python right away, no
| exceptions or anything.
|
| (there is also coredump but most distros disable or hide
| them, so it's not a problem in practice)
| williamsmj wrote:
| Anyone reading your code is going to assume this is a bug.
| The PEP is right that explicit is better than implicit. You
| should write `except BaseException` (whether or not this PEP
| is approved).
| TuxSH wrote:
| "except:" is explicit enough and "except BaseException" is
| redundant.
|
| Moreover I think there is a real risk people are going to
| write "except Exception:" instead, which breaks in the
| fringe case an exception that derives from BaseException
| (enforced by interpreter) but not from Exception is thrown.
|
| Even if catch Exception is what users usually mean,
| changing code from "catch (BaseException):" to "catch
| Exception:" may break some code if improperly reviewed.
|
| It's also not worth breaking production code over this.
| williamsmj wrote:
| > "except:" is explicit enough and "except BaseException"
| is redundant.
|
| Take that up with the consensus view of the python
| community, as reflected by python linters in their
| default configuration, almost all of which warn on bare
| except.
|
| The debate in the PEP is whether this should be a syntax
| error. The debate about whether it is good style is over
| though.
|
| > It's also not worth breaking production code over this.
|
| Agreed.
| zahlman wrote:
| >which breaks in the fringe case an exception that
| derives from BaseException (enforced by interpreter) but
| not from Exception is thrown.
|
| For many users, in many cases, this would be fixing the
| code rather than breaking it.
|
| Forcing people to write either `except BaseException:` or
| `except Exception:` means forcing them to _think about_
| which one they actually mean. This is a good thing, just
| like the enforcement of proper separation between bytes
| and text is a good thing.
| rcxdude wrote:
| Only if they don't understand what 'raise' means. It's
| obvious this construct is just injecting some additional
| information in a passing exception, there's no issue if it
| catches everything.
| williamsmj wrote:
| > It's obvious this construct is just injecting some
| additional information in a passing exception
|
| There is a good chance it will fail to do that. See
| elsewhere in this thread.
| theamk wrote:
| It will change exception class if logging function will
| fail... I wouldn't call this "good chance", those kinds
| of things are pretty unlikely in my experience.
| int_19h wrote:
| Bare except + reraise is a very common Python pattern, so
| no, it won't be assumed to be a bug. This was actually one
| of the major points in the discussion of the PEP that led
| to its rejection.
| 1st1 wrote:
| Just noting it here: your code is incorrect. In case of a
| KeyboardInterrupt error and another error raised by
| `log_tons_of_debug_info()` (there's no error free code,
| right?), KeyboardInterrupt would end up being masked (it
| would go into the __context__ attribute of another error).
| The program won't abort its execution. And it's just one
| example out of many where it's critical to not mask error
| types.
|
| Correct code would be: try:
| something() except BaseException as ex: try:
| log_tons_of_debug_info() finally:
| raise ex
|
| But really, you don't want to mess with BaseExceptions at
| all, so just do `except Exception` instead of a bare
| `except:`.
| theamk wrote:
| Why wouldn't I want to mess with BaseExceptions? They are
| not magic, and add only 3 classes to the list:
|
| SystemExit - You _definitely_ want to catch this one for
| logging. If a library (not top-level app) calls `sys.exit`
| you at least want to know what's happening, if anything so
| you can talk to author and get them to use proper exception
| types.
|
| KeyboardInterrupt - I normally want to catch this one as
| well. If the program was taking too long and I hit Ctrl-C
| to stop it, I _do_ want to see all the debug output. And if
| I don't, for some reason, there is always Ctrl-\ which
| kills python immediately and unconditionally.
|
| GeneratorExit - this one is tricky and I agree that in a
| lot of cases, you don't want to print logs on it. But it
| also very rare - it only appears in async functions
| (emitted by yield), and never propagated to caller. So as
| long as you are not doing async, you can simply ignore it,
| which covers majority of the the code I write.
| 1st1 wrote:
| Because accidentally masking some BaseExceptions like
| `asyncio.CancelledError` can lead to things like
| memory/resource leaks and potentially your production app
| going down in pretty hard to debug ways.
| gmueckl wrote:
| Java solved the problem by having Throwable as the root of all
| exceptions and not advertising that fact loudly. The derived
| Exception class is the root of all safely catchable exceptions.
| When someone catches a Throwable, something strange is going
| on.
| williamsmj wrote:
| Python does the same thing. It just calls Throwable something
| different.
|
| Java Throwable ~= Python BaseException.
|
| Java Exception ~= Python Exception.
|
| The problem here is that a bare except catches something
| similar to Throwable, not something similar to Exception.
| rectang wrote:
| > _Bare excepts are syntactic sugar for `except
| BaseException`._
|
| I'm guessing that a `3to4` script would be provided which
| replaces bare `except:` with `except BaseException:`. We have
| the experience of `2to3` to draw on with regards to how that
| might play out.
|
| EDIT: Haha, I now see that this PEP proposes a change without
| advancing the major version. That surprises me.
| williamsmj wrote:
| 1. Such a script is proposed in the PEP.
|
| 2. Python does not use semantic versioning. 3.13 is a
| different major version to 3.12.
| MantisShrimp90 wrote:
| I think Rich Hickeys advice of not breaking people applies here.
|
| The anger from this potential change is that really all you are
| doing is taking something away that was working, and now people
| will need to review their code or keep python on a previous
| version which sucks.
|
| I think that people who propose these kinds of changes don't
| appreciate the importance of the programming language being at
| the bottom of the stack so there's really never a good reason to
| break people even if you think it's nicer as you really can't
| appreciate how much work you are creating for people.
| TeddyDD wrote:
| Python breaks compatibility across minor versions. I'm not
| surprised seeing such proposal.
| dimator wrote:
| do you have examples?
| sseagull wrote:
| One painful one that is still reverberating a bit in some
| areas is the renaming of "SafeConfigParser" to just
| "ConfigParser" in the standard library (in 3.12). This
| caused a whole lot of breaking in some areas because
| versioneer (a package for determining a package version
| from git tags) used it (in code that was placed inside your
| package, and so couldn't be solved by just upgrading
| versioneer).
|
| Also, I'm starting to get warning about something in
| tarfile that I will need to track down:
| https://peps.python.org/pep-0706/
| mardifoufs wrote:
| I think distutils is a good example of that (though imo
| it's a justified break, but still)
| dig1 wrote:
| IMHO, working on a programming language is only for some, just
| like working on a database is only for some. The first rule
| should be: "you should never break the language, ever". Just
| like you should never break the database or kernel behavior.
|
| This is why I like to stick to C, Common Lisp, Clojure, and (to
| some extent) Java/JVM. I don't know about Clojure's future, but
| C and Common Lisp have been fine for the last 40 years, and I'm
| not expecting the least in the upcoming years.
| thefaux wrote:
| I half agree with this rule. I think that it's fine to break
| things as long as you make a semantic version change _and_
| provide automated tooling for upgrading old code. If you
| can't build this tool, that is a strong negative signal for
| both versions of the language.
|
| What I don't like about say, c, is that it has various
| backward compatible additive dialects like c11 vs c99. I
| personally don't agree that c11 and c99 are the same language
| in spite of the backwards compatibility and I think it makes
| the entire ecosystem worse. At some point there needs to be a
| successor rather than just piling on to old broken designs. I
| would prefer a better FFI or other tools to interface with
| legacy code in the new dialect.
| INTPenis wrote:
| That's funny, I code a lot of python but I don't participate in
| any large projects where a pipeline might fail due to this. So I
| don't follow the PEP news much.
|
| And yet I have created my own habit of not using bare excepts.
| TIL what bare except even means, but I do not use them. Simply
| because I think it makes more sense to specify the exception I
| want to catch, and failing that I specify the base class
| Exception.
|
| So I guess I understand the author of this PEP, we're of one mind
| on this. :)
|
| Also thanks to this post TIL that a bare except might catch
| interrupts like ctrl-c. Even more justification for my new habit.
| cpburns2009 wrote:
| The proposal (not part of PEP 760) to add an implicit `raise` to
| the end of bare `except:` blocks would be far more damaging than
| making bare-excepts a syntax error.
| ramses0 wrote:
| [Citation Needed]?
| cpburns2009 wrote:
| > Now there's an interesting idea: don't make bare except
| illegal, make it have an implicit raise at the end (and
| disallow return, break, and continue).
|
| https://discuss.python.org/t/pep-760-no-more-bare-
| excepts/67...
| ramses0 wrote:
| ...ahh, a bit of a misreading on my part. However, I was
| really looking for your explanation of the horrors that
| could happen rather than what the suggestion was. Thinking
| through a bit more, yeah, implicit re-raise does have some
| pretty bad outcomes if you can't change code in a
| dependency.
|
| It still feels like `deno` is somewhat on the right track
| where permissions are dropped by default, but It'd Be
| Nice(tm) if programming languages enabled that a bit
| easier. import sales_tax_calculator as
| xyz with [ cap.NETWORK, cap.FILESYSTEM, cap.USB, ...etc...
| ] xyz.calculate( sales_price,
| state=user.address.state )
|
| We're implicitly allowing imported libraries the full power
| of the containing programming language where with
| promiscuous code sharing (trending towards a low-trust
| environment), it'd be a lot better to _not_ give `cap.FS,
| NETWORK, USB, etc...` by default.
|
| Bringing it back around: `import somelib with [
| cap.BARE_EXCEPT, cap.RAISE ]` or something to control their
| handling of "unknown" exceptions is interesting. Let them
| handle any exceptions or interrupts they've authored, but
| let me explicitly have control over catching stuff that
| isn't "from them".
|
| ...an extended version of dependency injection or inversion
| of control.
| cpburns2009 wrote:
| Adding an implicit raise to the end of a bare-except
| would quietly break things, and is non-trivial to detect.
| Say you have a naive base-except: def
| loop(): try: check_service()
| except: logging.exception("Error while
| checking service.") time.sleep(60)
|
| Really you shouldn't be using a base-except here. You
| should at the bare minimum catch `Exception`. Adding an
| implicit `raise` at the end will break this function
| without so much as a warning. Instead of calling the
| function every minute, the loop is broken with an
| unexpected exception that was deliberately suppressed
| (and logged).
|
| A more common scenario for myself is write a lot of my
| scripts in the style: def main(argv:
| list[str]) -> int: # Parse args, setup
| logging, etc. try:
| run_script(args) except:
| log.exception("Script failed.") return 1
| return 0 if __name__ == '__main__':
| sys.exit(main(sys.argv))
|
| An implicit raise would obnoxiously break them when my
| bare-except is intentional, and effectively cause the
| error to be printed twice to the terminal. Now I'm not
| wholly opposed to forcing `except BaseException:` instead
| of `except:`, but an implicit raise would cause all sorts
| of subtle bugs.
| tln wrote:
| -1000
|
| Why would you ever consider breaking everyone's throwaway
| scripts?? For what is already a universal linter rule?
| shadowgovt wrote:
| I'm not categorically against it, but it needs to go into
| Python4, not a minor revision. It breaks too much.
|
| (Plus, the suggested transition easement, "A tool will be
| provided to automatically update code to replace bare except:
| with except BaseException:", indicates a fundamental flaw in this
| approach: it's still trivial for developers to catch-and-kill
| exceptions. So we're strictly increasing the verbosity of the
| language without actually solving the problem. :( ).
| stackskipton wrote:
| This is what not having sane BDFL does to organization.
|
| Only proper response is private email from sane BDFL similar to
| Linus email of "WE DON'T BREAK USERSPACE"
| Chris2048 wrote:
| This is just a proposal though, having a (sane) BDFL needn't
| change anything.
| stackskipton wrote:
| Sane BDFL would have already stepped in with "Absolutely not"
| and PEP closed with "Will not implement"
|
| EDIT: Add on, Private Email to Pablo going "Dude, why are you
| purposing stuff that will break code spectacularly? I think
| we need to talk about your approach to language design."
| int_19h wrote:
| The community (including many of the maintainers) has
| spoken, and the PEP has been withdrawn, so apparently you
| don't _need_ a BDFL for this.
| byyoung3 wrote:
| they might as well add semicolons while they are at it
| akuchling wrote:
| Erm, Python has accepted semicolons to separate statements
| since version 0.9.2, released in the fall of 1991.
| shadowgovt wrote:
| FWIW, on the poll near the bottom of the comment thread, "I think
| we should always allow bare except blocks" is winning
| significantly.
| dataflow wrote:
| > which can lead to overly broad exception handling and mask
| important errors
|
| I'm sure it can, but some evidence of this actually happening
| feels rather critical for a change that will break the language
| for everybody.
| pech0rin wrote:
| Cant stand the infantilization of software tools. People can
| choose for themselves what features to use or not use. Doesnt
| need to be determined by our keepers. Also do Python maintainers
| just hate backwards compat as some sort of religion?
| eesmith wrote:
| Yeah, no. I know I'll mistakenly do except
| Exception: resource.rollback() raise
|
| instead of except BaseException:
| resource.rollback() raise
|
| and it's going to be really hard to insert a test case which
| ensures I really handled KeyboardInterrupt and the like.
| prpl wrote:
| This is something that can be handle easily with static analysis
| and should not be a language feature
| pjmlp wrote:
| I hope this goes nowhere, it adds very little value, to the
| expense breaking compatibility.
| bunderbunder wrote:
| I get that lately Python has decided it wants to be an
| industrial-grade enterprise programming language. But there's a
| part of me that misses when the Python community retained a
| "we're all adults here" ethos.
| move-on-by wrote:
| I just completed upgrading a monolith from Python 3.8 to 3.11 -
| no doubt many others in the same position with 3.8 going EOL. It
| was a monumental effort. I will say the huge majority of work was
| upgrading libraries that hadn't been updated in years. I won't go
| into the specifics of why we had chosen not to update these
| libraries earlier (unless there is interest), but I will say
| Python being as backward compatible as possible has huge real
| world value. More for the community and ecosystem than the
| language itself. For the people who care about PEP 760, they have
| their choice of linting tool to enforce this requirement.
| b5n wrote:
| I've spent a lot of time fixing/explaining python exceptions over
| the years, and I get pretty annoyed when I encounter bare
| exceptions. Exceptions themselves are so often misunderstood, it
| seems most people just take them at face value. However, do we
| really need to dull all the sharp edges and add guardrails to
| every fucking thing? In a corporate environment, sure, you can
| implement all the protections you like _without attempting to
| force your constraints on all users_.
|
| If you care about types, safety, etc. there are plenty of
| fantastic projects that share your priorities, but they don't
| need to bleed into everything under the sun.
|
| Sharing and adopting new ideas is healthy, but homogenization
| kills creativity.
|
| Maybe I'm just grumpy today.
| berdario wrote:
| A bunch of people are mentioning the bugbear of the Python3
| migration, but there's an important difference that makes the
| migration a lot simpler for a backward-incompatible change like
| this one proposed in PEP760:
|
| You can just write code that is compatible with Python runtimes
| both _before_ and _after_ the change.
|
| That means that you can use the same test suite, gradually
| getting the code more and more compatible with the new version,
| and you can switch your production runtime, without having to
| worry about a more complicated and involved rollback process.
|
| Notably, in the Python 2->3 migration, it was not really possible
| (at first[*]) because "" (and b"") literals became -> b""
|
| while u"" literals became -> ""
|
| So, there was no way to write literals that would mean the same
| thing, and have the same type across the two versions
|
| This is also the reason why libraries like six offered a `six.u`
| function (https://six.readthedocs.io/#binary-and-text-data) but
| that required banning use of non-ASCII codepoints in your string
| literals
|
| [*] This was eventually addressed with PEP 414 (and of course,
| even with with PEP 414, the migration was not trivial)
|
| https://peps.python.org/pep-0414/
| move-on-by wrote:
| > That means that you can use the same test suite, gradually
| getting the code more and more compatible with the new version,
| and you can switch your production runtime, without having to
| worry about a more complicated and involved rollback process.
|
| This is all well and good for your own code, but it's seldom
| the case the libraries. A new library release that 'adds
| support for Python 3.14' is very likely to include other
| changes in the same release that may or may not be trivial,
| even assuming you were already on the latest version of the
| library prior to needing to update. A change like this to the
| Python language might be trivial, but it would have a massive
| impact on the ecosystem.
| ck45 wrote:
| I don't remember there to be that much complaint about
| https://peps.python.org/pep-0352/ and from having worked on a
| large Python code base at that time, it was rather easy change.
| amelius wrote:
| Next step: ... except Exception as err:
| pass
|
| Error: variable err not used!
| BurningFrog wrote:
| I've had and seen this philosophical debate a few times.
|
| To me, "if _anything_ goes wrong, do the following " is perfectly
| valid semantics that appears a lot, and a bare excepts is a fine
| way to implement that.
|
| I think what confuses these discussions is that a common "rookie
| mistake" is slapping on a bare except when you really should be
| specific.
|
| For some people, this is reason enough to blindly enforce a "bare
| excepts" rule. To me, the costs vastly outweigh the benefits in
| this case.
|
| At it's core, this might be a personality type issue more than
| anything else.
| _hl_ wrote:
| What's wrong with being explicit about "I really do mean
| anything that goes wrong" by catching the base class?
| BurningFrog wrote:
| That's actually the better way for me as well! So my comment
| is somewhat off topic.
|
| I still don't like the proposed change because of how much
| existing code it would break, but if we're designing a new
| language I approve.
| _hl_ wrote:
| I see - I suppose that's a fair viewpoint to have!
|
| I'm not much of a python programmer but my experience with
| the language would make me tend to agree actually. There
| are bigger fish to fry and so the effort to go after this
| relatively tiny sardine is perhaps not worth it.
| nomel wrote:
| I don't understand this. To me, a bare exception is
| explicitly that. By not providing a _specific_ exception, you
| 're saying "nothing specific, literally anything".
| dtech wrote:
| The pep explicitly adresses the use case, and it's still
| allowed.
|
| The point of the pep is that it should be explicit, especially
| because the short form doesn't show whether catching
| terminating exceptions is a bug or intentional
| veggieroll wrote:
| I switched to Go years ago because I know that code I wrote a
| decade ago is still going to work. And that guarantee is even
| more ironclad in recent years with modules and vendoring.
|
| With a Go project, I can leave it to sit for 3+ years and then
| pick it back up and add a feature without any issues. I've never
| had that with a Python project. (and this isn't even about the
| 2-to-3 situation, I just mean minor version to minor version and
| packages)
| berkayozturk wrote:
| Even though there are valid use cases for having catch-all
| clauses, I see people forget about properly handling SystemExit
| exception. If your service receives SIGTERM from the scheduler,
| you need to capture it and gracefully handle the shutdown instead
| of swallowing it.
| czscout wrote:
| Personally, I don't agree with this proposal. While yes, I agree,
| that bare excepts are often a source of bugs, I don't think it
| should be the language's responsibility to nanny the programmer
| on such things. To me, this seems to only reduce the
| functionality of the language. If explicit exception handling is
| necessary, let the programmer make that decision.
| kristjansson wrote:
| My concern, and IMO what should be the overwhelming concern of
| the maintainers, is not the code that is being written, or the
| code that will be written, but all the code that has been
| written, and will never be touched again. A break like this will
| force lots of python users to avoid upgrading to 3.17, jettison
| packages they may want to keep using, or deal with the hassle of
| patching unmaintained dependencies on their own.
|
| For those Python users for whom writing python is the core of
| their work that might be fine. For all the other users for whom
| python is an foreign, incidental, but indispensable part of their
| work (scientists, analysts, ...) the choice is untenable. While
| python can and should strive to be a more 'serious',
| 'professional' language, it _must_ have respect and empathy for
| the latter camp. Elevating something that should be a linter rule
| to a language change ain't that.
| isoprophlex wrote:
| Exactly this. I totally agree. It's incredible to think that
| some people still run python 2 scripts; something unpalatable
| to the point of being nauseating for a day-to-day python
| programmer, but totally understandable in the context of
| incidental usage by a scientist dealing with legacy systems.
|
| If these things start happening to python 3 on a larger scale,
| might as well throw in the towel and go for python 4.
| mrbungie wrote:
| I read "python 2" and a part of my soul cried in utf-8.
| bdowling wrote:
| Are you sure it didn't cry in `bytes()`?
| nine_k wrote:
| There are places that don't operate in anything but ASCII.
| Or even anything but 0123456789,\n\r.
| bobim wrote:
| Not sure 3 did anything to the number of circular
| permutations of encode and decode one need to fiddle with
| until that damn csv is pulled in correctly.
| afiori wrote:
| Programming languages are too obsessed with unicode in my
| opinion:
|
| String operations should have bytes and utf-{8,16}
| versions. The string value would have is_valid_utf_{8,16}
| flags and operations should unset them if they end up
| breaking the format (eg str[i] = 0xff would always mark the
| string as not unicode, str[i] = 0x00 would check if the
| flag was set and it so check whether the assignment broke a
| codepoint and unset the flag if so)
| sigh_again wrote:
| There are zero reasons to not go full UTF-8, everywhere,
| all the time. Strings should not be allowed to be built
| directly from bytes, but only from converting them into
| explicitly UTF-8 (or, for API specific needs, other
| encodings should you want to enter the fun world of UCS-2
| for some reason), which can and should be a cheap wrapper
| to minimize costs.
|
| Bytes are not strings. Bytes can represent strings,
| numbers, pointers, absolutely anything.
| nly wrote:
| Still loads of Python 2 scripts floating around at my
| employer and my prior 2 employers (6 years total)
| afiori wrote:
| I guess it did not happen but I liked the idea of keeping
| python2 as a supported but forever frozen language.
|
| Sort of like if c was still c90 and compilers mostly had no
| extensions.
| Narhem wrote:
| Disagree, I'm so disappointed in companies who do sprint type
| development refusing to use Python. It works well with the
| "Silicon Valley startup ecosystem".
|
| That being said, as far as workplace differences I'd say Java
| shops would be the ideal, slower, less long term problems but
| so much more initial investment.
| stackskipton wrote:
| As SV startup with Python monolith, yes, it's very common for
| startup but generally gets ejected because lack of strict
| typing and speed. We are replacing with Go, Node and .Net.
| Narhem wrote:
| Python offers typing with static compiling. .Net doesn't
| really match with startup culture.
|
| I'm on the fence about Go, but maybe that's my preference
| to having classes.
|
| But yeah I'm the general case if I was an investor I'd be
| more careful with purely Python based startups.
| bigstrat2003 wrote:
| > Python offers typing with static compiling.
|
| Python doesn't enforce types and as far as I know has no
| plans to.
|
| > .Net doesn't really match with startup culture.
|
| Who the hell cares? If it's the best tool for the job,
| use it. Anything else is unprofessional as hell.
| Narhem wrote:
| Tell that to the people who downvote me which seems
| unprofessional as hell.
|
| If I want to learn .Net which is more time consuming and
| more difficult to find employees why would I use it?
| Makes sense if you are in an area with a lot of windows
| people, but that's not the case anywhere other than
| Texas.
|
| And the compiler enforce typing. Admittedly not as nice
| as Go since you have to rely on external tools but
| workable.
|
| People like their curly brackets though. Just not as
| helpful when dealing with system problems.
| stackskipton wrote:
| .Net came from group we acquired who yes, deployed things
| on Windows. However, their code now runs on .Net Core, in
| Linux Containers on Kubernetes. It's very performant as
| well, my only gripe is startup JIT. .Net does great in
| startup culture if you are not chasing trends and want
| code that works.
| neonsunset wrote:
| Hmm, usually the application start latency should be very
| good. Significant improvements have been made to ensure
| that Tier-0 compiles very fast. A base ASP.NET Core
| template takes about 120ms to start on my machine as
| tested with .NET 8 and Hyperfine (it makes sure to start
| the server with app.RunAsync, then cancels it in 10ms,
| outputs an error message in console about the fact and
| exits).
|
| There is a good chance something else might be going on
| in one of the dependencies or perhaps some other infra
| package a team maintains, that slows this down. Sometimes
| teams publish SDK images on accident that have to be
| pulled over the network if they got evicted from the node
| cache, or try to use self-contained instead of runtime
| image + plain application - I know at least two cases
| where this was causing worse than desired deployment
| speed on GKE (arguably GKE is as much at fault here, but
| that's another topic).
| rurban wrote:
| major changes with breaking backward compatibility would
| require a major bump. Fine for python 4 I would say.
| kristjansson wrote:
| Sure I guess? But we've just barely stopped talking about
| Python3, and that was released 13-16 years ago[1]. Is _this_
| change worth another decade of thrashing the ecosystem? Is
| __any__ change?
|
| [1]: depending on if we count 3.0 vs 3.2 when it was actually
| kinda usable.
| nine_k wrote:
| Why, it just should be opt-in: from
| __future__ import no_bare_except
|
| ...and enjoy.
| afiori wrote:
| Python should have the ability to set per-module flags for
| these kinds of incompatibilities.
|
| I guess that __future__ is doing something similar, but I
| am thinking of something like declaring how options should
| be set for your module and then only the code in that
| module is affected. (It would be nice being able to set
| constraints on what options your dependencies can enable)
|
| I guess that for std functionality this is impossible (like
| if the dict changed its key sorting it might be too hard to
| dispatch on the original file) but for syntax it should be
| perfectly possible.
| williamsmj wrote:
| Again, python does not use semantic versioning. 3.12 and 3.13
| are different major versions. The deprecation policy is
| documented and public. https://peps.python.org/pep-0387/.
| unethical_ban wrote:
| TIL.
|
| In the doc you linked, they reference "major" and "minor"
| versions. So they claim to have some concept of version
| numbers having different significance... Why don't they
| adhere to semantic versioning if they dress their version
| numbers like that?
|
| At least Linux just admits their X.Y scheme means nothing.
| nikcub wrote:
| Most active developers opt into this behaviour via linter
| rules[0]. I see only the downsides of building this into the
| language.
|
| [0] https://docs.astral.sh/ruff/rules/bare-except/
| adamc wrote:
| This, in a huge way. Especially given all the code that
| already exists.
| kragen wrote:
| The Python maintainers have switched from considering backward
| compatibility useful but costly to considering it actively
| harmful; there was a campaign a few years ago to convince
| library maintainers to stop making their code
| Python-2-compatible:
|
| > _The Python 3 statement was drawn up around 2016. Projects
| pledged to require Python 3 by 2020, giving other projects
| confidence that they could plan a similar transition, and
| allowing downstream users to figure out their options without a
| nasty surprise. We didn't force people to move to Python 3, but
| if they wanted to stick with Python 2, they would stop getting
| new versions of our projects._
|
| (https://python3statement.github.io/)
|
| I know this sounds like a joke, and you probably think you're
| misreading, but no. Projects _pledged to require Python 3 by
| 2020_. They _made a promise_ to _break backward compatibility_.
| Not just a few minor projects, either; TensorFlow, Spark,
| IPython, Pandas, NumPy, SymPy, Hypothesis, etc.
|
| Since that happened, everyone who considers backward-
| compatibility good (if costly), rather than evil, has abandoned
| Python.
|
| The "other users for whom python is an foreign, incidental, but
| indispensable part of their work (scientists, analysts, ...)"
| would have to fork Python, but it's probably too late for that;
| they can hardly hope to fork TensorFlow, Pandas, etc., as well.
| williamsmj wrote:
| 1. That python 3 statement was not drawn up by "the Python
| maintainers". It was drawn up by downstream library owners.
|
| 2. To the extent you object to changes in the core language,
| the python maintainers do have a backwards compatibility
| statement and prominent timelines for deprecation. You may
| disagree with these, but they are public.
|
| 3. At the time it was written, the python 3 statement
| proposed dropping support for a version of python with known
| security problems and no plans for security updates. It seems
| like your argument is with the python 2 to python 3
| transition, which feels like a conversation we've had here
| before.
| kragen wrote:
| Anyone can of course apply security fixes to Python 2,
| because it's open-source.
|
| My objection is not to library owners _dropping support
| for_ Python 2, which is a perfectly reasonable choice for
| them to make--backward compatibility can be costly, after
| all, and the benefits may not be worth it. My objection is
| to library owners _pledging to drop_ support for Python 2,
| because that entails that they think backward compatibility
| _is itself harmful_. To me, that 's pants-on-head crazy
| thinking, like not wanting to wear last season's sweater,
| or not wanting to use JSON because it's too old.
|
| Observably, since this happened, the Python maintainers
| have been very active at breaking backward compatibility.
| (And there's substantial overlap between Python maintainers
| and major Python library maintainers, which I suspect
| explains the motivation.) I think this is probably due to
| people who don't think backward compatibility is actually
| evil (the aforementioned "all the other users for whom
| python is an foreign, incidental, but indispensable part of
| their work") fleeing Python for ecosystems like Node,
| Golang, and Rust. This eliminates the constituency for
| maintaining backward compatibility.
|
| I do think the botched 2-3 transition was probably the
| wellspring of this dysfunction, but I don't think that in
| itself it was necessarily a bad idea, just executed badly.
|
| As a result of this mess, it's usually easy for me to run
| Lisp code from 40 years ago, C code from 30 years ago, or
| Perl or JS code from 20 years ago, but so difficult to run
| most Python code from 5 years ago as to be impractical.
| wizee wrote:
| It seems to be a gross exaggeration to say most Python
| code from 5 years ago doesn't work on current Python
| versions. Python 3 was mainstream a decade ago, and
| almost all code written for Python 3.3 or 3.4 still works
| on Python 3.13. Maybe some libraries have had breaking
| changes, but at least for common libraries like Numpy,
| Scipy, and Matplotlib, most code from a decade ago still
| works fine.
| kragen wrote:
| There's plenty of Python 2 code from 5 years ago, and
| virtually none of it works on current Python versions. A
| decade ago virtually all Python code was Python 2 code;
| in 02014 Python 3 was almost unusable. Perhaps what you
| mean is that most _individual lines of Python code_ using
| Numpy and Scipy from ten years ago work fine in current
| Python versions, but very few complete programs or even
| library modules do.
| bastardoperator wrote:
| They made a new version which is highly indicative of
| breaking changes if not the entire meaning behind bumping
| the version. What's the problem? I think it's bold of you
| to rag on volunteers for a supposed botched upgrade,
| whatever, but I don't know anyone writing python 2 today?
| int_19h wrote:
| If you actually read the discussion of this PEP, you can see
| many Python maintainers strong opposing it on backwards
| compatibility grounds:
| https://discuss.python.org/t/pep-760-no-more-bare-
| excepts/67...
|
| In fact, the consensus was so strongly against it that it has
| already been withdrawn.
| zitterbewegung wrote:
| Well this PEP won't be going forward see
| https://discuss.python.org/t/pep-760-no-more-bare-excepts/67...
| m463 wrote:
| Honestly 2->3 has been a _HUGE_ mess, and python should be
| learning from these sorts of mistakes.
| martinbaun wrote:
| I love Python, but it seems to always get more complicated and
| more things in the core and now backward incompatible changes.
| Not so good. I love Python and how much I can get done, but I
| must admit I also love that I know the Go code I have from 7
| years ago can run without problems. It is just more stable
| __turbobrew__ wrote:
| Continuing Pythons tradition of breaking perfectly functional
| code.
| kh_hk wrote:
| Seems like a troll PEP and still would not surprise me. Explicit
| is better than implicit, except if it makes you look like a fool.
| lpapez wrote:
| If this was Go, instead of making a breaking change they would
| opt for a linter rule or a go vet directive.
|
| This is the sensible approach IMO to handle a hazardous
| programming construct. Warn people about it and give them the
| choice to shoot their foot.
|
| But don't break their code.
| ziml77 wrote:
| Fortunately the votes on the poll for this look to very much be
| against the PEP's proposal.
|
| I don't mind Python being improved, but as we learned from the
| 2->3 transition it should not be changed in ways that break old
| code. All that will do is have people forever sitting on an old
| version of Python. That's a worse situation that having code with
| bare excepts.
| xorcist wrote:
| Valid reasons for backwards incompatible changes to language
| syntax:
|
| 1. The language guarantees have become inconsistent, and the
| syntax breaks security boundaries or realtime guarantees that the
| language explicitly promises, and it is unfixable.
|
| 2. The universe of all written code is small enough that there
| are guarantees the syntax is unused, or we can change all
| instances of the syntax in an atomic manner.
|
| Invalid reasons for backwards incompatible language changes:
|
| 1. Everything else.
| dsign wrote:
| I know what this is! They want to "to give it" to Jeff Bezos, by
| breaking AWS' boto3, that has a nightmare of a story for
| handling/catching specific exceptions. It's all politically
| motivated!
| kkirsche wrote:
| I wish people would stop holding onto compatibility as if it is
| some amazing feature. It has benefits, but also comes with many
| drawbacks to innovation and improvement in established ecosystems
| smbullet wrote:
| This seems silly. I hate backwards compatibility but this change
| will just cause people to use `except BaseException` everywhere
| which seems even less idiomatic than bare excepts.
|
| ETA: Nobody is going to dig through a large codebase to find
| exactly what exceptions can be bubbled up if they didn't design
| it with explicit exception handling in mind from the beginning.
| It will also potentially become a pattern people will copy in new
| code.
| jgb1984 wrote:
| As someone who is using python professionally for over 17 years I
| sincerely hope this PEP gets rejected.
| Scea91 wrote:
| Not all python code is production code. Sometimes I just need to
| write simple one-off script for one-off task. For that bare
| except is totally fine.
| zmnayt wrote:
| As many people have observed here, this is a couple of Steering
| Council members showing activity. Getting one's PEPs accepted has
| a totally inflated weight in the Python "community". The more,
| the better (by contrast very few people care about perfect and
| bug-free code).
|
| So, if this thing is accepted, it pads the resume of certain
| people even more. And many software orgs will have one additional
| week of job security by rewriting existing code. It's a win-win
| situation.
|
| Ever since the walrus operator coup Python has descended into
| madness and make-work initiatives.
| wyldfire wrote:
| > Currently, Python allows catching all exceptions with a bare
| except: clause, which can lead to overly broad exception handling
| and mask important errors.
|
| The fact that this pattern catches NameError and other things
| which are obviously design errors means that it is a really bad
| behavior which is unfortunately common.
|
| Of course, many folks in this comment section and the PEP
| discussion thread point out the pitfalls with the suggested
| remedies. It would be great if some amount of
| linting/warning/static check could be devised to help people
| uncover the problem though.
| joshlk wrote:
| Would it be possible to move all the language developers to work
| on packaging?
|
| IMO the Python language is feature complete but the packaging
| system needs heart surgery.
| dcchambers wrote:
| ELI5: Why do people love Python so much?
|
| From an outsiders perspective: The ecosystem is a disaster, on a
| level even exceeding that of JavaScript IMO. The 2->3 transition
| was awful and lead to a rift in the python community for years
| (still causes issues 15 years later). Maintainers seem happy to
| introduce breaking changes without major version bumps. It's not
| that performant of a language (slower than modern Ruby, for
| example). Best thing it's got going for it is readability.
| gnulinux wrote:
| Python ecosystem is a disaster for certain reasons but there is
| simply no ecosystem better than Python for other reasons. It's
| a trade-off. For literally any niche problem you can find out
| there there will be a Python library somewhere in the annals of
| the internet. I use many many many programming languages and
| everything starts out as a Python script in my flow, because by
| the time you start half the code is already written.
| linguae wrote:
| Python is not my favorite programming language, but back in
| 2006 Python felt like a breath of fresh air for writing short
| programs. I felt more productive in Python than in C, C++, or
| Java, which were the other languages I knew at the time (I was
| an undergraduate CS student), and I still use Python as my
| first choice for short data processing scripts. In addition,
| Python has many libraries, built-in and external. When I worked
| as an AI researcher before returning to academia, Python was
| our team's main language since there's a rich ecosystem of
| numerical computing and machine learning libraries.
|
| I agree, though, that the ecosystem has many rough edges,
| especially when it comes to package management, dependency
| management, and environments/containers. This is especially
| true in the AI ecosystem, especially as a researcher, where I
| had to deal with third-party code that is sometimes written by
| people who are solid scientists but have little software
| engineering experience.
|
| I'm now back in academia as a teaching-oriented professor; it's
| been a few months now since I've had to use pip and conda,
| though I have written some Python scripts to aid with grading.
| I teach C++ and Haskell to undergrads now, and I also have side
| projects involving Scheme and Common Lisp :).
| dbrueck wrote:
| > ELI5: Why do people love Python so much?
|
| Developer productivity.
|
| > Maintainers seem happy to introduce breaking changes without
| major version bumps
|
| Nah. Keep in mind that this is a PEP, not an announcement of
| what is going to happen, see also
| https://peps.python.org/pep-0313/ .
| mrguyorama wrote:
| It's the absolute best tool for "I need to programmatically do
| <thing> and will never touch this script again" or "I want to
| build a tiny utility app for myself and myself alone, and I
| don't want to have to pull in ANY dependencies or do ANY build
| steps"
|
| I have literally used it instead of writing a curl one liner
| because I didn't feel like looking up the arguments.
|
| Python is incredible for building _tools_ , exactly like a
| small time machinist might build certain cutters for a part
| they are manufacturing, or a blacksmith build tools, or a
| welder building a jig, etc etc
|
| I cannot fathom when people choose to build heavyweight or long
| lived applications and business products with it. Django is
| alright I guess, except that complicated database stuff will
| cause you problems eventually, and migrations are a lot of fuss
| for not as many guarantees as you would hope for the effort.
| cb321 wrote:
| Possibly relevant -- Nim has a compile-time warning for bare
| exceptions, initially enabled by default [1]. I think Nim-core
| changed their mind about this being a good idea a few months
| later: https://github.com/nim-lang/Nim/pull/21728 (though the
| message still says "The bare except clause is deprecated" if you
| _do_ compile with --warning:BareExcept:on - I think the urge to
| actually deprecate has gone away).
|
| I think for Python, rather than breaking bajillions of
| unpublished lines of code they should start with a more tentative
| & minimally invasive environment var/CLI switch opt-out warning
| that says something like " _may_ be deprecated " where even the
| Python ./configure script lets you opt out at Python interpreter-
| compile-time. Measure the scope of the porting problem for a few
| years before trying to decide on The Plan for something that
| might be too disruptive.
|
| [1] https://github.com/nim-
| lang/Nim/commit/91ce8c385d4ccbaab8048...
| gweinberg wrote:
| This has to be some kind of joke. If it had gone the other way
| and python had originally required people to write "except
| BaseException", a PEP to allow a bare except would be an obvious
| improvement to the language, since it would allow people to do
| the same thing and save pointless typing. This proposal is
| suggesting we break virtually all existing Python code to make
| the language objectively worse. I'm guessing this is a sort of
| "modest proposal" type parody.
| braiamp wrote:
| I don't know why this is seen with such aversion. This is the
| language forcing sane coding practices, since you always include
| what should be cached. Also, the syntactic sugar for except
| BaseException is to not catch it in your `try ... except` clause.
| If you do, for example:
|
| >>> try: ... raise TypeError ... except ValueError: ...
| print("keke") ... raise ...
|
| TypeError will bubble up. If you want to catch everything, and
| handle it, like the example from Mailman[0], you should catch the
| base exception anyways.
|
| This can be solved and detected by static analysis tools anyways.
|
| [0]:
| https://gitlab.com/mailman/mailman/-/blob/master/src/mailman...
| thih9 wrote:
| A lot of comments are about this affecting existing unmaintained
| code and causing problems with upgrades.
|
| But couldn't the old code be automatically updated? E.g. wouldn't
| replacing every 'except:' with 'except BaseException:' make old
| codebase compatible with the proposed change?
|
| Sure, that's a pain too and I'm not a fan of the change itself
| either; still, a breaking change that can be addressed
| automatically sounds relatively easy.
| NelsonMinar wrote:
| Python is also a scripting language, not just a systems
| engineering language. Sometimes fast-and-loose error handling is
| appropriate to the task.
| krzyk wrote:
| I was afraid that this is something similar to infamous PEP 572
| (also known as make-python-c), but it actually is a great change
| - it will remove errors and will make code more readable
| (contrary what PEP 572 did).
| zahlman wrote:
| You did notice that Guido van Rossum was a co-author of that
| one, yes?
| objektif wrote:
| This is how beautiful languages are ffed up. Can you leave the
| core syntax alone and let people write elegant code if they want
| to? Why do we try to force a certain type of coding down the
| throat of people. Ease of use made python popular and we should
| leave it that way.
| wren6991 wrote:
| Someone needs to set up a Clockwork Orange-style viewing session
| with the Python developers and Linus' WE DO NOT BREAK USER SPACE
| email: https://linuxreviews.org/WE_DO_NOT_BREAK_USERSPACE
|
| I help maintain a small Python codebase at work (bulk of my work
| is in Verilog) and the number of times somebody's PEP science
| fair project has broken production code following a Python
| version upgrade is too damn high.
| camgunz wrote:
| Leave this in linters.
| zitterbewegung wrote:
| Latest post on this says that this PEP won't be implemented at
| all.
|
| https://discuss.python.org/t/pep-760-no-more-bare-excepts/67...
| kej wrote:
| The PEP has been withdrawn based on the poll results, which
| mostly echo the comments here:
| https://discuss.python.org/t/pep-760-no-more-bare-excepts/67...
|
| >Hi everyone!
|
| >Thanks a lot for voicing your opinions and concerns! After
| reading carefully all the arguments, the poll and the different
| positions we have decided that the best course of action is to
| withdraw the PEP as there is clear agreement that the breakage
| doesn't justify the benefits here.
|
| >Thanks a lot!
| zahlman wrote:
| What bothers me more on a meta level is that some people in the
| community are apparently empowered to just write PEPs on a whim
| that will be quickly withdrawn, whereas most people will be
| forced to fight through long discussion threads before finding
| a sponsor willing to co-sign to a PEP (if that ever happens).
| The "Ideas" section of the forum is probably the least pleasant
| to use; and for all the controversial new stuff that gets
| added, the dev team is _stunningly_ conservative WRT ideas that
| come from outside.
|
| In particular, they'll commonly tell you to demonstrate your
| feature as a third-party package on PyPI first, _then_ show
| that it gains popularity (i.e. you as a random developer are
| responsible for _promoting_ your idea, not merely justifying
| it) - and if you succeed at that, they 'll have the argument
| waiting for you that you already have a maintained, mature
| library that's perfectly capable of working on its own, so why
| would it need to become part of the language? "The standard
| library is where packages go to die", don't you know?
|
| BTW, they will also tell you these things if the nature of your
| idea makes it impossible - e.g., you propose to add a method to
| a builtin type; subtyping won't work, because part of the point
| is that literal values should get the functionality
| automatically.
| dfhfg wrote:
| So, after wasting everyone's time they issue a bureaucratic
| power talk statement that the casual reader will interpret as
| "nice". They certainly do know how to play mostly socially
| incompetent followers.
|
| (These are the same people who humiliated Tim Peters and
| others.)
| benrutter wrote:
| Love the boldness here of trying to make something you dislike a
| syntax error.
|
| I don't really get preferring `except BaseException` over
| `except`. I'd love to get more info on _possible_ exceptions
| though and I think it would cut down a lot of the catch all
| handling I see.
|
| As far as I know, python doesn't give you _any_ way of asking
| "what exceptions can this function run" - aside from just
| inspecting every line of code. I'd massively love to have those
| kind of details available.
| atoav wrote:
| Having a catchall exception may seem like a bad idea to some, but
| I am quite often in situations where I write code that I really
| don't want to fail (and I want it to continue running). Fore
| these cases I always used it as such: try:
| result = somethingrisky() except SomeKnownException as e:
| return handle_known_error(e) except Exception as e:
| log_error(e) return None return result
|
| or something among those lines. And this is perfectly fine if
| that risky function e.g involves requests that in my experience
| can fail for a ton of reasons and it is hard to know them all.
| neeleshs wrote:
| Looks like this PEP has been withdrawn now
___________________________________________________________________
(page generated 2024-10-09 23:01 UTC)