Guido> My point is that it's futile to use callable() -- even if it
Guido> passes, you have no assurance that you actually have a valid
Guido> callback. So why bother with it at all? It's counter to the
Guido> spirit of Python. If someone passes you a bad callback, they will
Gu
On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> I have no problems with Python being untyped. But I want that error
> stack traces provide some useful information as possible with reasonable
> effort and that errors happen as early as possible. In particular, stack
> trace should mention
On 4/8/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> > > Guido van Rossum wrote:
> > > > What if someone passes a callable that doesn't have the expected
> > > > signature?
> > >
> > > Well,
At 08:01 PM 4/8/2007 +0400, Alexey Borzenkov wrote:
>On 4/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> > > Guido van Rossum wrote:
> > > > What if someone passes a callable that doesn't have the expected
> signature?
> > > Well, I do
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > What if someone passes a callable that doesn't have the expected
> > > signature?
> >
> > Well, I don't know a way to catch such situations now, so removing
> >
Guido van Rossum wrote:
> On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > What if someone passes a callable that doesn't have the expected
> > > signature?
> >
> > Well, I don't know a way to catch such situations now, so removing
> > callable() will not mak
On 4/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > What if someone passes a callable that doesn't have the expected
> > > signature?
> > Well, I don't know a way to catch such situations now, so removing
On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> > assert hasattr(x, '__call__')
> >
> > I note that callable() was introduced before all callable objects had
> > a __call__ attribute. This is no longer the case, so it's not needed.
> I just didn't think about that possibility. If that work
On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > What if someone passes a callable that doesn't have the expected signature?
>
> Well, I don't know a way to catch such situations now, so removing
> callable() will not make it worse (even if you don't know about ha
Guido van Rossum wrote:
> On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> > Additionally consider something like
> >
> > something.set_callback (x)
> >
> > Assume that set_callback() wants to check if `x' is callable at
> > all, to raise exception early and make error tracking easie
On 4/8/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
> I have seen in PEP 3100 that callable() function is planned to be
> removed in Python 3000 with this replacement: "just call the object
> and catch the exception???". For one, the object (if it is
> callable) can raise exception itself, so yo
> I have seen in PEP 3100 that callable() function is planned to be
> removed in Python 3000 with this replacement: "just call the object
> and catch the exception???". For one, the object (if it is
> callable) can raise exception itself, so you need to somehow to
> differentiate between exception
Hi,
I have seen in PEP 3100 that callable() function is planned to be
removed in Python 3000 with this replacement: "just call the object
and catch the exception???". For one, the object (if it is
callable) can raise exception itself, so you need to somehow to
differentiate between exception rais
13 matches
Mail list logo
