> From a cultural perspective (with python traditionally not being written in
> this style)
> I think writing code like this at the level of internal library code (that
> the user of the
> library will not see when using the library) is perfectly fine.
>From a cultural perspective (with python t
> Alas, this still doesn't work because type annotations are advisory and
> not mandatory. Regardless of the type hints given, I can still call
> div(1, "surprise") and get a TypeError.
I'd assume that everyone is a consenting adult and if someone really wanted to
shoot themselves in the foot t
I think on this point at lot of people will have to agree to disagree. The
clear advantage for me is that the `ZeroDivisionError` that is naturally part
of `div` is made explicit and handled in a type safe way (given than one is
using a type checker like mypy). Especially in this example I can't
On Sat, Sep 26, 2020 at 09:59:27AM +0200, Sascha Schlemmer via Python-ideas
wrote:
> I think a clear distinction has to be made between errors that belong
> to the api surface of a function e.g. some `ValueError` or
> `ZeroDivisionError` and *exceptional* errors e,g.`KeyboardInterrupt`
> or `D
On Sat, Sep 26, 2020 at 10:47 PM Sascha Schlemmer via Python-ideas
wrote:
> ```
> def div(a: int, b: int) -> Result[float, ZeroDivisionError]:
> try:
> return Success(a / b)
> except ZeroDivisionError as error:
> return Failure(error)
> ```
>
> Now `div` does return a valid instanc
On Sat, Sep 26, 2020 at 8:50 AM Sascha Schlemmer via Python-ideas <
python-ideas@python.org> wrote:
> I think a clear distinction has to be made between errors that belong to
> the api surface of a function e.g. some `ValueError` or `ZeroDivisionError`
> and *exceptional* errors e,g.`KeyboardInter
On Fri, Sep 25, 2020 at 3:38 PM Steven D'Aprano wrote:
> The last thing I want to see is people being encouraged to write code
> like this:
>
> def demo(arg)->Something:
[... elided ...]
> except:
> # Any other unexpected error.
> raise ValueError('somet
I think a clear distinction has to be made between errors that belong to the
api surface of a function e.g. some `ValueError` or `ZeroDivisionError` and
*exceptional* errors e,g.`KeyboardInterrupt` or `DatabaseExplodedError`. For
the latter case exceptions work perfectly well as they are and it
On 26/09/20 7:26 am, Oscar Benjamin wrote:
The suggestion ... was not that it would be a
type-checking error to call the inverse function without catching the
exception. It only becomes a type-checking error if a function calls
the inverse function and claims not to raise the exception.
This is
On 2020-09-26 01:23, Greg Ewing wrote:
On 26/09/20 4:32 am, Oscar Benjamin wrote:
annotations could be used to document in a statically
analysable way what the "expected" exceptions are. A type checker
could use those to check whether a caller is handling the *expected*
exceptions
But that wou
On 26/09/20 5:27 am, Wes Turner wrote:
Safe coding styles (in other languages) do specify that *there may not
be any unhandled exceptions*.
I don't think a blind rule like that actually makes a program any safer.
It encourages a coding style that covers up problems and carries on to
produce ga
On Fri, Sep 25, 2020 at 04:58:00PM -0400, Wes Turner wrote:
> On Fri, Sep 25, 2020 at 1:43 PM Steven D'Aprano wrote:
> > Of course rare or unusual exceptions probably won't be discovered
> > without a lot of testing, including stress testing, or not until the
> > code goes out into production. Th
On Fri, Sep 25, 2020 at 08:01:39PM +0100, Paul Moore wrote:
> On Fri, 25 Sep 2020 at 18:42, Steven D'Aprano wrote:
> > There may be practical difficulties in sticking exceptions into
> > annotations. Annotations already can be pretty long and bulky. But if
> > you are okay with functions documenti
Search upwards for what (if anything) is going to catch an Exception would
be a mighty useful static/dynamic analysis thing. Is there anything that
can do this?
I'd hazard to guess that *most* apps will just crash and expect the process
spawner (e.g. systemd, supervisord, not sysV init) to re-spaw
On 26/09/20 4:32 am, Oscar Benjamin wrote:
annotations could be used to document in a statically
analysable way what the "expected" exceptions are. A type checker
could use those to check whether a caller is handling the *expected*
exceptions
But that would be inappropriate. Even if an exceptio
Depth-first-search for every callable, [property] descriptor, operator,
__getitem__
On Fri, Sep 25, 2020 at 4:36 PM Wes Turner wrote:
>
> LSP servers and clients: https://langserver.org/
> - https://github.com/microsoft/python-language-server
> -
> https://code.visualstudio.com/api/language-ex
On Sat, Sep 26, 2020 at 10:19 AM Wes Turner wrote:
>
>
>
> On Fri, Sep 25, 2020 at 8:09 PM Chris Angelico wrote:
>>
>> On Sat, Sep 26, 2020 at 8:17 AM Wes Turner wrote:
>> >
>> > What a worthless semantic distinction.
>> >
>> > You don't want to be executing code to determine why an Exception oc
On Fri, Sep 25, 2020 at 8:09 PM Chris Angelico wrote:
> On Sat, Sep 26, 2020 at 8:17 AM Wes Turner wrote:
> >
> > What a worthless semantic distinction.
> >
> > You don't want to be executing code to determine why an Exception
> occurred because you do not trust support devs to access all of the
On Sat, Sep 26, 2020 at 8:48 AM Oscar Benjamin
wrote:
>
> On Fri, 25 Sep 2020 at 22:05, Chris Angelico wrote:
> >
> > On Sat, Sep 26, 2020 at 6:56 AM Oscar Benjamin
> > wrote:
> > >
> > > There are many common bugs that arise as a result of exceptions that
> > > are overlooked. There are also of
On Sat, Sep 26, 2020 at 8:17 AM Wes Turner wrote:
>
> What a worthless semantic distinction.
>
> You don't want to be executing code to determine why an Exception occurred
> because you do not trust support devs to access all of the data in the
> production system.
>
> "Exceptions happen" is tru
On Fri, 25 Sep 2020 at 22:05, Chris Angelico wrote:
>
> On Sat, Sep 26, 2020 at 6:56 AM Oscar Benjamin
> wrote:
> >
> > There are many common bugs that arise as a result of exceptions that
> > are overlooked. There are also often simple ways to rewrite the code
> > so that it becomes exception fr
What a worthless semantic distinction.
You don't want to be executing code to determine why an Exception
occurred because you do not trust support devs to access all of the data in
the production system.
"Exceptions happen" is true, but that's not satisfactory in an organization
focused on qualit
On Sat, Sep 26, 2020 at 7:25 AM Wes Turner wrote:
>
> (Executing arbitrary code on a production server is debugging in production.
>
> Logging (additional information added to exceptions with 'raise _ from _`)
> may assist with root cause analysis and debugging on a different instance but
> IMHO
(Executing arbitrary code on a production server is debugging in production.
Logging (additional information added to exceptions with 'raise _ from _`)
may assist with root cause analysis and debugging on a different instance
but IMHO logging is not debugging.)
On Fri, Sep 25, 2020, 5:18 PM Chris
On Sat, Sep 26, 2020 at 7:05 AM Wes Turner wrote:
>> "Well, if I get an import error, I can add some more directories to
>> sys.path and try adding the values again, that might fix it..."
>>
>> Who does that? Not me. And I bet you don't either.
>
>
> "Defensive programming" / "Offensive programmin
On Sat, Sep 26, 2020 at 6:56 AM Oscar Benjamin
wrote:
>
> There are many common bugs that arise as a result of exceptions that
> are overlooked. There are also often simple ways to rewrite the code
> so that it becomes exception free. For example in sympy:
>
> if x.is_positive: # never raises
On Fri, Sep 25, 2020 at 1:43 PM Steven D'Aprano wrote:
> On Fri, Sep 25, 2020 at 11:14:01PM +1000, Chris Angelico wrote:
> > On Fri, Sep 25, 2020 at 7:59 PM Sergio Fenoll wrote:
>
> > > Surely there has to be a better way of programming than running stuff,
> > > watching it fail, and then keepin
On Fri, 25 Sep 2020 at 20:36, Chris Angelico wrote:
>
> On Sat, Sep 26, 2020 at 5:27 AM Oscar Benjamin
> wrote:
> >
> > On Fri, 25 Sep 2020 at 18:59, Chris Angelico wrote:
> > >
> > > On Sat, Sep 26, 2020 at 2:32 AM Oscar Benjamin
> > > wrote:
> > > > I do agree but maybe that suggests a differ
On Fri, Sep 25, 2020 at 3:03 PM Paul Moore wrote:
> On Fri, 25 Sep 2020 at 18:42, Steven D'Aprano wrote:
> > There may be practical difficulties in sticking exceptions into
> > annotations. Annotations already can be pretty long and bulky. But if
> > you are okay with functions documenting that
On Sat, Sep 26, 2020 at 5:27 AM Oscar Benjamin
wrote:
>
> On Fri, 25 Sep 2020 at 18:59, Chris Angelico wrote:
> >
> > On Sat, Sep 26, 2020 at 2:32 AM Oscar Benjamin
> > wrote:
> > > I do agree but maybe that suggests a different role for annotated
> > > exceptions in Python. Rather than attempti
On Fri, 25 Sep 2020 at 18:59, Chris Angelico wrote:
>
> On Sat, Sep 26, 2020 at 2:32 AM Oscar Benjamin
> wrote:
> > I do agree but maybe that suggests a different role for annotated
> > exceptions in Python. Rather than attempting to enumerate all possible
> > exceptions annotations could be used
On Fri, 25 Sep 2020 at 18:42, Steven D'Aprano wrote:
> There may be practical difficulties in sticking exceptions into
> annotations. Annotations already can be pretty long and bulky. But if
> you are okay with functions documenting that they might raise a certain
> exception, then *in principle*
On Fri, 25 Sep 2020 at 18:28, Samuel Colvin wrote:
>> There's also the problem that you've explicitly acknowledged, that
>> exception hints are *always* going to be inaccurate, in stark contrast
>> to type hints which are expected to be correct when used.
>
> We should draw a distinction between t
On Sat, Sep 26, 2020 at 3:42 AM Steven D'Aprano wrote:
> > In the list of all possible failures, will you include MemoryError?
>
> Sure, if I'm writing some sort of ultra-high availability server
> application that is expected to run 24/7 for months at a time.
>
> while memory_in_reserve():
>
On Sat, Sep 26, 2020 at 2:32 AM Oscar Benjamin
wrote:
> I do agree but maybe that suggests a different role for annotated
> exceptions in Python. Rather than attempting to enumerate all possible
> exceptions annotations could be used to document in a statically
> analysable way what the "expected"
On Fri, Sep 25, 2020 at 11:14:01PM +1000, Chris Angelico wrote:
> On Fri, Sep 25, 2020 at 7:59 PM Sergio Fenoll wrote:
> > Surely there has to be a better way of programming than running stuff,
> > watching it fail, and then keeping track of how it fails so you can
> > later handle that failure?
I strongly disagree that it's useless to document which Exceptions a
function could raise; even in Python (which, for a few reasons, is not a
language that's considered for safety-critical application).
In Python, it is common practice to - at a high level in the call stack -
trap Exceptions that
On Fri, 25 Sep 2020 at 15:57, Paul Moore wrote:
>
> On Fri, 25 Sep 2020 at 14:15, Chris Angelico wrote:
>
> > Why? Do you really think you can enumerate EVERY possible way that
> > something might fail?
>
> Rust does a surprisingly good job of that, actually. But the point is
> that Python is not
On Fri, 25 Sep 2020 at 14:44, Samuel Colvin wrote:
>
> Sorry I probably wasn't clear enough in what I was suggesting.
>
>>
>> The main question here is why using a hint or a decorator should be
>> better than a simple documentation.
>
>
> For the same reason type hints are better than documentatio
On Fri, 25 Sep 2020 at 14:15, Chris Angelico wrote:
> Why? Do you really think you can enumerate EVERY possible way that
> something might fail?
Rust does a surprisingly good job of that, actually. But the point is
that Python is not Rust, and the infrastructure Rust uses to allow it
to manage c
On Fri, 25 Sep 2020 at 13:46, Samuel Colvin wrote:
>
> Sorry I probably wasn't clear enough in what I was suggesting.
>
>>
>> The main question here is why using a hint or a decorator should be
>> better than a simple documentation.
>
>
> For the same reason type hints are better than documentatio
On Fri, Sep 25, 2020 at 7:59 PM Sergio Fenoll wrote:
>
> O 25/09/20 ás 11:52, Chris Angelico escribiu:
> > But requests.get() doesn't have a single raise statement anywhere in
> > it. And if you dig through the entire source code for the requests
> > package, you'll still only find a small number
On 2020-09-25 at 13:44:36 +0100,
Samuel Colvin wrote:
> 2. We should have some easy way to say "let this error propagate",
> rust uses very nice question mark at the end of a line syntax, python
> could use something similar one day, until then a magic comment,
> wrapper function or context funct
On Fri, Sep 25, 2020 at 01:23:01PM +0900, Stephen J. Turnbull wrote:
> Sergio Fenoll writes:
>
> > In the same vein as adding type annotations to code, I think it'd
> > be very useful to have exception "raises" annotations, i.e. a way
> > to annotate what exceptions a function raises.
>
> I th
Sorry I probably wasn't clear enough in what I was suggesting.
> The main question here is why using a hint or a decorator should be
> better than a simple documentation.
For the same reason type hints are better than documentation -
1. static analysis can catch a multitude of potential errors
On Fri, 25 Sep 2020 at 11:58, Samuel Colvin wrote:
> I first found myself wanting this when I came back to python
> having been writing rust. The Result type in rust is somewhat
> similar to what's being suggested here. See
> https://doc.rust-lang.org/std/result/
I do not know Rust and I'm not su
O 25/09/20 ás 11:52, Chris Angelico escribiu:
But requests.get() doesn't have a single raise statement anywhere in
it. And if you dig through the entire source code for the requests
package, you'll still only find a small number of the exceptions that
might be raised. Errors come from anywhere, a
>
> I think it'd be very useful to have exception "raises"
annotations, i.e. a way to annotate what exceptions
a function raises.
I personally think this would be wonderful, I've been meaning
to suggest it here for some time, but haven't got around to it.
I first found myself wanting this when
On Fri, Sep 25, 2020 at 7:46 PM Sergio Fenoll wrote:
> I'm really failing to see what part of my logic is faulty. I know that
> any exception that isn't handled can be raised. I know that is the
> expected behaviour. I don't expect every function to exhaustively
> document every single exception i
O 25/09/20 ás 11:34, Chris Angelico escribiu:
On Fri, Sep 25, 2020 at 7:19 PM Sergio Fenoll wrote:
O 25/09/20 ás 10:56, Chris Angelico escribiu:
There's the shallow "exceptions that I expect to raise", which is
those explicitly listed within the function as raise statements; but
that's not th
On Fri, Sep 25, 2020 at 7:19 PM Sergio Fenoll wrote:
>
> O 25/09/20 ás 10:56, Chris Angelico escribiu:
>
> > There's the shallow "exceptions that I expect to raise", which is
> > those explicitly listed within the function as raise statements; but
> > that's not the whole story, since exceptions c
O 25/09/20 ás 06:23, Stephen J. Turnbull escribiu:
Sergio Fenoll writes:
> In the same vein as adding type annotations to code, I think it'd
> be very useful to have exception "raises" annotations, i.e. a way
> to annotate what exceptions a function raises.
I think you need to explain th
O 25/09/20 ás 10:56, Chris Angelico escribiu:
There's the shallow "exceptions that I expect to raise", which is
those explicitly listed within the function as raise statements; but
that's not the whole story, since exceptions can be raised by anything
that the function calls. So, no, I don't thi
On Fri, Sep 25, 2020 at 6:14 PM Sergio Fenoll wrote:
> I see what you mean now, and I agree. But surely there's a fairly big
> overlap between
> "exceptions I expect to raise" (from the POV of the callee) and
> "exceptions I can handle"
> (from the POV of the caller). Wouldn't it still be useful t
O 25/09/20 ás 10:02, Chris Angelico escribiu:
On Fri, Sep 25, 2020 at 5:09 PM Sergio Fenoll wrote:
O 25/09/20 ás 08:41, Chris Angelico escribiu:
It would have to not only look at get(), but everything that it calls.
Either that, or you're back to the Java thing of "catch it or declare
it", an
On Fri, Sep 25, 2020 at 5:09 PM Sergio Fenoll wrote:
>
> O 25/09/20 ás 08:41, Chris Angelico escribiu:
>
> > It would have to not only look at get(), but everything that it calls.
> > Either that, or you're back to the Java thing of "catch it or declare
> > it", and we've seen from Java that that'
O 25/09/20 ás 09:12, Serhiy Storchaka escribiu:
Did not the experience of C++ show that exceptions declaration was a bad
idea? In C++ it was optional and is abandoned now. Java developers still
suffer from necessary to declare all raised exception, or just declare
the most general exception class
24.09.20 11:47, Sergio Fenoll пише:
> In the same vein as adding type annotations to code, I think it'd be
> very useful to have exception "raises" annotations, i.e. a way to
> annotate what exceptions a function raises. Again, like type
> annotations, it shouldn't be mandatory nor actually be enfo
O 25/09/20 ás 08:41, Chris Angelico escribiu:
On Fri, Sep 25, 2020 at 4:25 PM Sergio Fenoll wrote:
What I had in mind was that an IDE could use this information to show
autocomplete options when writing except blocks. The other day I was
writing some code like this:
import requests
try:
On Fri, Sep 25, 2020 at 4:25 PM Sergio Fenoll wrote:
> What I had in mind was that an IDE could use this information to show
> autocomplete options when writing except blocks. The other day I was
> writing some code like this:
>
> import requests
>
> try:
>
> requests.get('https://python.org'
O 25/09/20 ás 07:37, Steven D'Aprano escribiu:
I think that it's a truism that any function written in Python could
raise any exception :-)
In practice, though, I think it is reasonable to say that functions will
*typically* but not necessarily exclusively raise a certain set of
exceptions.
Wh
On Fri, Sep 25, 2020 at 3:38 PM Steven D'Aprano wrote:
> The last thing I want to see is people being encouraged to write code
> like this:
>
> def demo(arg)->Something:
> # Raises ValueError
> try:
> processing...
> except ValueError:
> raise
>
On Thu, Sep 24, 2020 at 10:47:21AM +0200, Sergio Fenoll wrote:
> Hi,
>
> I was wondering if the following idea would be a useful addition to the
> Python language and if it could use a new PEP.
> I personally find myself often looking into the documentation &
> implementation of libraries I use to
I like the idea.
In python 3.9 you could actually experiment with implementing something
like this yourself using the new Annotated type introduced in PEP 593:
https://docs.python.org/3.9/library/typing.html#typing.Annotated
https://www.python.org/dev/peps/pep-0593/
Maybe create a raises helper
64 matches
Mail list logo
