473,543 Members | 2,488 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Missing exceptions in PEP 3107

I'm just reading PEP 3107 (function annotations) and wonder why
exceptions are not mentioned there. I think it would be helpful if one
could specify which exceptions can be raised by a function, similarly to
how it is possible in C++ using the "throw" clause. The syntax would be
something like this:

def foo(a: expr, b: expr = 5) raises expr -expr:

The expr in that "raises" clause should be a list of Exceptions.

Having the list of possible exceptions as annotation alone would be
already helpful. Of course it could be also discussed whether Python
should check that the function really raises only these exceptions (as
in C++), or we could even have checked exceptions (as in Java, but this
seems to be a controversial issue).

Has this already been discussed, or is it in a different PEP?

-- Christoph
Aug 9 '08 #1
17 1724
On Aug 9, 9:08*am, Christoph Zwerschke <c...@online.de wrote:
I'm just reading PEP 3107 (function annotations) and wonder why
exceptions are not mentioned there. I think it would be helpful if one
could specify which exceptions can be raised by a function, similarly to
how it is possible in C++ using the "throw" clause. The syntax would be
something like this:

def foo(a: expr, b: expr = 5) raises expr -expr:

The expr in that "raises" clause should be a list of Exceptions.

Having the list of possible exceptions as annotation alone would be
already helpful. Of course it could be also discussed whether Python
should check that the function really raises only these exceptions (as
in C++), or we could even have checked exceptions (as in Java, but this
seems to be a controversial issue).

Has this already been discussed, or is it in a different PEP?

-- Christoph
Keep in mind that annotations are just a way of associating some
information with the parameters or a function. There is a special
parameter called `return` to help associate information with the
return value. Whether that information is used to describe the types
of the function parameters, how they are used, or something completely
different is up to the application that uses them.

When you say:
The expr in that "raises" clause should be a list of Exceptions.
You are clearly confusing the annotation feature with a possible
application of the annotation feature. Annotation could be used for
many different applications besides type safety.

Annotation simply creates a dictionary. The name `return` was chosen
for the return value because it _is_ a keyword and therefore could not
conflict with the name of any of the parameters. Using "raises" would
mean that we would have to introduce the name "raises" as a new
keyword. It would be better just to use they existing keyword "raise".

With all of that being said, a package or application that uses
annotation could simply use the data-structure associated with
"return" to also contain exception information. That might not seem
intuitive, but keep in mind that the value associated with "return" in
the associations dictionary is going to be a special case anyway.

def foo(a: "a info", b: "b info") -"return info", "exception info":
return "hello world"

Matt
Aug 9 '08 #2
Matimus schrieb:
>The expr in that "raises" clause should be a list of Exceptions.

You are clearly confusing the annotation feature with a possible
application of the annotation feature. Annotation could be used for
many different applications besides type safety.
Sorry, I wanted to say "*could* be a list of Exceptions". Though this is
the most obvious application. In the end, the annotations need to be
given a semantical meaning anyway.
Annotation simply creates a dictionary. The name `return` was chosen
for the return value because it _is_ a keyword and therefore could not
conflict with the name of any of the parameters. Using "raises" would
mean that we would have to introduce the name "raises" as a new
keyword. It would be better just to use they existing keyword "raise".
Yes, it later also occured to me that it ought to be an existing
keyword, i.e. "raise" (or maybe "except"). That's porbably the reason
why it is "throw" in C++, and not "throws".
With all of that being said, a package or application that uses
annotation could simply use the data-structure associated with
"return" to also contain exception information. That might not seem
intuitive, but keep in mind that the value associated with "return" in
the associations dictionary is going to be a special case anyway.

def foo(a: "a info", b: "b info") -"return info", "exception info":
return "hello world"
That would be possible. But I still think it makes sense to separate
them, like so:

def foo(a: "a info", b: "b info") -"ret info" raise "exc info":
return "hello world"

And then the annotation dictionary would contain another key "raise"
containing the exc info. This cannot conflict with the name of any other
parameter either.

Maybe the following syntax would be even more intuitive:

def foo(a: "a info", b: "b info") return "ret info" raise "exc info":
return "hello world"

I don't know how determined the "->" syntax is already.

-- Christoph

Aug 10 '08 #3
Christoph Zwerschke <ci**@online.de wrote:
That would be possible. But I still think it makes sense to separate
them, like so:

def foo(a: "a info", b: "b info") -"ret info" raise "exc info":
return "hello world"

And then the annotation dictionary would contain another key "raise"
containing the exc info. This cannot conflict with the name of any other
parameter either.
If you really want this then you can use a decorator to insert a 'raise'
key into the annotations:

@raises("exc info")
def foo(a: "a info", b: "b info") -"ret info":
return "hello world"

I don't know how determined the "->" syntax is already.
Consider the syntax set in concrete. The meaning of the annotations on the
other hand is completely up for grabs.
Aug 10 '08 #4
Duncan Booth wrote:
If you really want this then you can use a decorator to insert a 'raise'
key into the annotations:
Well, yes, but wasn't the whole point of PEP 3107 to get rid of such
decorators and provide a single standard way of specifying this kind of
info instead?
>I don't know how determined the "->" syntax is already.

Consider the syntax set in concrete. The meaning of the annotations on the
other hand is completely up for grabs.
Yes, as far as I understand this is an experiment how people are using
the annotations, and then later this may get standardized as well.

But maybe the PEP should then at least mention what's the currently
recommended way to make annotations about thrown exceptions.

-- Christoph
Aug 10 '08 #5
Christoph Zwerschke <ci**@online.de wrote:
But maybe the PEP should then at least mention what's the currently
recommended way to make annotations about thrown exceptions.
There is no currently recommended way to make such annotations, so how
could the PEP mention it?

I think the problem you are going to face is that almost any function could
potentially throw almost any exception. That may mean it is a good idea to
document what exceptions you expect to be thrown, but it also means you
cannot expect those annotations to be anything other than documentation.
Aug 10 '08 #6
Duncan Booth schrieb:
There is no currently recommended way to make such annotations, so how
could the PEP mention it?
Then it could mention the fact that there is currently no recommended
way (and maybe make some suggestions, like those given by you).
Aug 10 '08 #7
On Aug 10, 6:42*pm, Christoph Zwerschke <c...@online.de wrote:
Duncan Booth schrieb:
There is no currently recommended way to make such annotations, so how
could the PEP mention it?

Then it could mention the fact that there is currently no recommended
way (and maybe make some suggestions, like those given by you).

I think you're missing the point here. PEP 3017 is policy-neutral: it
describes a mechanism to annotate functions and arguments, and that's
it.

IOW, there is currently no recommended way to do *anything* with
annotations(**) . That is entirely left up to users and third-party
packages, and the PEP goes out of its way to disclaim all authority on
policy. The following quote from the PEP sums it up well:

"Following from point 2, this PEP makes no attempt to introduce any
kind of standard semantics, even for the built-in types. This work
will be left to third-party libraries."

Your concern is misplaced; it just doesn't belong in the PEP.
"So", you might ask, "where does it belong then?"

The answer is probably "nowhere". Since annotations are intended to
be used by third party packages, those packages will define the
semantics of the annotations, and the recommendations would only be
applicable to users of that package, and not to Python users in
general.

It might come to pass that someday a different PEP will be written to
standarize stuff like this, but that usually only happens after the
community has had time to explore the problem domain for awhile (cf.
WSGI).
Carl Banks

(**) - Actually there is a minor policy recommendation: that the pydoc
and inspect module learn to understand and display the annotations.
Aug 11 '08 #8
Maybe the following syntax would be even more intuitive:
>
def foo(a: "a info", b: "b info") return "ret info" raise "exc info":
* * * * return "hello world"

I don't know how determined the "->" syntax is already.
That seems much more intuitive and extensible. The "->" syntax has
always bothered me. The main issue I see with it though is that it
might be confusing. Consider:

def foo(a, b) return 0:

return a + b

A person reading the code might be tempted to read the annotation and
think that it is the body. Maybe not a huge problem, but definitely
something that will come up occasionally.
Consider the syntax set in concrete.
Why? Python syntax is always changing. If we can think of a better way
to do something, then there is no better time than today to bring it
up.

Having said that, I like the decorator idea too:
@raises("exc info")
def foo(a: "a info", b: "b info") -"ret info":
return "hello world"
And to this:
Well, yes, but wasn't the whole point of PEP 3107 to get rid of such
decorators and provide a single standard way of specifying this kind of
info instead?
Maybe, but I think it also does two more things: 1. creates a standard
location for storing annotations, and 2. Keeps you from violating DRY
(http://en.wikipedia.org/wiki/DRY).

For instance:

@parameters(a=" a info", b="b info")
@raises("except ion info")
@returns("retur n info")
def foo(a, b):
pass

a and b are mentioned in both the definition and the "parameters "
decorator. This violates DRY since a change to the definition will
also require a change to the parameters decorator call. One could
argue that you could make the parameters decorator inspect the
function and apply the annotations positionally. That doesn't really
eliminate the problem, just muddles it. Moving or changing parameters
is still going to result in the need to change code in multiple
locations. The positional case is almost worse in that it will usually
result in the same amount of work, while being less explicit.

Using a single decorator for exception info (or even return info) does
not violate either of the two stated benefits. The exception
information would go into the standard annotations dictionary. The
raises decorator does not violate DRY any more or less than it would
if added to the language syntax.

Matt
Aug 11 '08 #9
Matimus wrote:
Christoph wrote:
>Maybe the following syntax would be even more intuitive:

def foo(a: "a info", b: "b info") return "ret info" raise "exc info":
return "hello world"

That seems much more intuitive and extensible. The "->" syntax has
always bothered me. The main issue I see with it though is that it
might be confusing. Consider:

def foo(a, b) return 0:

return a + b

A person reading the code might be tempted to read the annotation and
think that it is the body. Maybe not a huge problem, but definitely
something that will come up occasionally.
Yes, that's a drawback; and the same problem for a "raise" clause.
>Well, yes, but wasn't the whole point of PEP 3107 to get rid of such
decorators and provide a single standard way of specifying this kind of
info instead?

Maybe, but I think it also does two more things: 1. creates a standard
location for storing annotations, and 2. Keeps you from violating DRY
(http://en.wikipedia.org/wiki/DRY).
Using a single decorator for exception info (or even return info) does
not violate either of the two stated benefits. The exception
information would go into the standard annotations dictionary. The
raises decorator does not violate DRY any more or less than it would
if added to the language syntax.
That's a valid point, but as you already mentioned, the same applies to
the return value. In my opinion it is desirable that either both return
value and exceptions get a special syntax, or both must be described
using decorators.

-- Christoph
Aug 15 '08 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
1529
by: Dan Bishop | last post by:
I installed Python on the HP 3000 at work today. The interpreter itself appears to be working fine, but "import math", "import datetime", etc. fail with "ImportError: No module named ". (However, os and system can be imported successfully.) I used help('modules') to print a list of available modules and there were only 14 (__builtin__,...
0
1125
by: Grady Nash | last post by:
All of my web servers are running win2000 and .NET 1.1 SP1. On one of my test web servers when I open Perfmon and add a new counter, aspnet_wp is missing. For example I want to see how many exceptions are thown per second by the aspnet_wp - so I pick the ".NET CLR Exceptions" performance object, then select "# of Excepts Thrown / sec" and in...
11
34775
by: vijaynats | last post by:
Why isn't there a 'throws' keyword in C# like java - i would like to declare a function and say - public int addup(int a, int b) throws ArithmeticExceptio, DivideByZeroException { ... ... }
11
1883
by: BoloBaby | last post by:
OK, check this out... I have a form with a panel control and button on it (outside the panel control). I have two event handlers - one handles the click event of the button on the form. The other handles a custom "CardInserted" event for a class I wrote that watches for smart cards to be inserted into an attached smart card reader.
42
2449
by: redefined.horizons | last post by:
I'm coming from a Java background, so please don't stone me... I see that Python is missing "interfaces". The concept of an interface is a key to good programming design in Java, but I've read that they aren't really necessary in Python. I am wondering what technique I can use in Python to get the same benefits to a program design that I...
1
2371
by: Anonieko | last post by:
Understanding and Using Exceptions (this is a really long post...only read it if you (a) don't know what try/catch is OR (b) actually write catch(Exception ex) or catch{ }) The first thing I look for when evaluating someone's code is a try/catch block. While it isn't a perfect indicator, exception handling is one of the few things that...
4
2482
by: Tony Lownds | last post by:
(Note: PEPs in the 3xxx number range are intended for Python 3000) PEP: 3107 Title: Function Annotations Version: $Revision: 53169 $ Last-Modified: $Date: 2006-12-27 20:59:16 -0800 (Wed, 27 Dec 2006) $ Author: Collin Winter <collinw@gmail.com>, Tony Lownds <tony@lownds.com> Status: Draft Type: Standards Track
20
2761
by: mc | last post by:
I may be opening a can of worms and don't want to start a religious war, but... What features of Java do Java programmers miss when working in C#? Other than, of course, great portability. C# has more limited cross-platform portability (Mono). I'm thinking more about data structures and ways to express algorithms.
1
1092
by: =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?= | last post by:
Well -- I generally use the web-base Microsoft newsgroup app, and all I see is the text of your message. I don't remember ever seeing a "handled" property of the exception dialog, at least not in C#, which is where you are posting. Can you be a bit more specific? -- Peter To be a success, arm yourself with the tools you need and learn how to...
0
7349
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
1
7347
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
7688
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
4895
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3391
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3391
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
1817
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
1
968
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
636
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.