On Aug 17, 7:25 pm, Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
> Carl Banks wrote:
> > If it bothers you that much, go file a bug report. Someone might even
> > change it. But it's nothing but needless pedantry.
>
> Has my "de" domain inspired you to rant about "pedantry"?
Actually, no.
Ca
Carl Banks wrote:
If it bothers you that much, go file a bug report. Someone might even
change it. But it's nothing but needless pedantry.
Has my "de" domain inspired you to rant about "pedantry"? No, it does
not bother me that much. I just thought the PEP could be clearer here
and explicit
On Aug 17, 9:34 am, Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
> Carl Banks schrieb:
>
> > You are free to use it for other things. For example, the following
> > usage is obvious and sensible (insofar as listing exceptions is
> > sensible):
>
> > def f(x : int) -> int, raises(TypeError)
>
> >
Terry Reedy wrote:
> I would agree... but...
> The problem is that code that uses a function hardly cares whether an
> exception that replaces the normal return is raised explicitly, by a
> syntax operation (and these are not yet completely documented, though
> perhaps they should be), or by a fun
Carl Banks schrieb:
You are free to use it for other things. For example, the following
usage is obvious and sensible (insofar as listing exceptions is
sensible):
def f(x : int) -> int, raises(TypeError)
Think of the return value annotation as more of a function outcome
annotation.
That's fi
On Aug 15, 3:42 pm, Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
> Carl Banks wrote:
> > 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 author
Christoph Zwerschke wrote:
That's not quite true: PEP 3017 describes a mechanism for annotating
function parameters *and return values*, and my point was why it does
not provide a mechanism for annotating thrown exceptions, since I see
info on thrown exceptions in the same category as info o
Carl Banks wrote:
> 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.
That's not quite true: PEP 3017 describes a mechanism for annotating
function parameters *and return values*, and my point was w
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
> 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
On Aug 10, 6:42 pm, Christoph Zwerschke <[EMAIL PROTECTED]> 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
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).
--
http://mail.python.org/mailman/listin
Christoph Zwerschke <[EMAIL PROTECTED]> 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 pro
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
Christoph Zwerschke <[EMAIL PROTECTED]> 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 k
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 "*coul
On Aug 9, 9:08 am, Christoph Zwerschke <[EMAIL PROTECTED]> 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 possibl
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
18 matches
Mail list logo
