P.J. Eby wrote:
At 08:50 PM 9/1/2009 -0400, Terry Reedy wrote:
Greg Ewing wrote:
Benjamin Peterson wrote:
It depends on whether you're keeping the "callable" object around or
not. Somebody could add a __call__ method later.
Good point. Removing the check sounds like the
right thing to do, th
At 08:50 PM 9/1/2009 -0400, Terry Reedy wrote:
Greg Ewing wrote:
Benjamin Peterson wrote:
It depends on whether you're keeping the "callable" object around or
not. Somebody could add a __call__ method later.
Good point. Removing the check sounds like the
right thing to do, then.
Both classm
Greg Ewing wrote:
Benjamin Peterson wrote:
It depends on whether you're keeping the "callable" object around or
not. Somebody could add a __call__ method later.
Good point. Removing the check sounds like the
right thing to do, then.
Both classmethod & staticmethod are documented as having a
On Sep 1, 2009, at 2:54 PM, Benjamin Peterson wrote:
2009/9/1 Brett Cannon :
On Tue, Sep 1, 2009 at 07:21, Benjamin
Peterson wrote:
2009/8/31 xiaobing jiang :
My idea is: here, the two functions (or maybe classes) should
have the
same behavior).
so is this a bug or something I missing ?
Benjamin Peterson wrote:
It depends on whether you're keeping the "callable" object around or
not. Somebody could add a __call__ method later.
Good point. Removing the check sounds like the
right thing to do, then.
--
Greg
___
Python-Dev mailing lis
2009/9/1 Greg Ewing :
> Brett Cannon wrote:
>>
>> It isn't like it is checking
>> explicitly for a function or method, just that it can be called which
>> seems reasonable to me (unless PyCallable_Check() is as off as
>> callable() was).
>
> I think it just checks that there's something in the
> tp
Brett Cannon wrote:
It isn't like it is checking
explicitly for a function or method, just that it can be called which
seems reasonable to me (unless PyCallable_Check() is as off as
callable() was).
I think it just checks that there's something in the
tp_call slot, which is reasonable -- if it'
Reid Kleckner wrote:
On one hand, you may not want to call the user's atexit handlers
multiple times from different processes if they have externally
visible effects. On the other hand, people seem to assume that
Py_Finalize will be called at process exit to do various cleanups. On
the third h
On Tue, Sep 1, 2009 at 14:54, Benjamin Peterson wrote:
> 2009/9/1 Brett Cannon :
>> On Tue, Sep 1, 2009 at 07:21, Benjamin Peterson wrote:
>>> 2009/8/31 xiaobing jiang :
My idea is: here, the two functions (or maybe classes) should have the
same behavior).
so is this a bug or somethi
Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit :
"We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly.
IIRC, the default return value of a Smalltalk method is
self, not the last thing evaluated.
(And no, that's not going to happen in Python either --
the BDFL has rej
Xavier Morel wrote:
I fail to grasp the unpredictability of "the last expression evaluated
in the body of a function is its return value".
It's unpredictable in the sense that if you're writing
a function that's not intended to return a value, you're
not thinking about what the last call you
2009/9/1 Brett Cannon :
> On Tue, Sep 1, 2009 at 07:21, Benjamin Peterson wrote:
>> 2009/8/31 xiaobing jiang :
>>> My idea is: here, the two functions (or maybe classes) should have the
>>> same behavior).
>>> so is this a bug or something I missing ?
>>
>> I think they should both not check their
>> Standard POSIX fork semantics should be a guidance. IIUC, termination
>> of the last thread is equivalent to calling exit(0) (although return
>> from main() still means that exit is invoked right away, and the return
>> value of main is the exit code - right?). Calling exit means to call
>> all
On Tue, Sep 1, 2009 at 2:58 PM, "Martin v. Löwis" wrote:
>> On one hand, you may not want to call the user's atexit handlers
>> multiple times from different processes if they have externally
>> visible effects. On the other hand, people seem to assume that
>> Py_Finalize will be called at process
> On one hand, you may not want to call the user's atexit handlers
> multiple times from different processes if they have externally
> visible effects. On the other hand, people seem to assume that
> Py_Finalize will be called at process exit to do various cleanups. On
> the third hand, maybe Pyt
On Tue, Sep 1, 2009 at 07:21, Benjamin Peterson wrote:
> 2009/8/31 xiaobing jiang :
>> My idea is: here, the two functions (or maybe classes) should have the
>> same behavior).
>> so is this a bug or something I missing ?
>
> I think they should both not check their arguments in __init__ to
> allow
Hi all,
I'm working on http://bugs.python.org/issue6642 for unladen swallow
(because it happens to bite us in a weird way), and Jeff Yasskin told
me to ask python-dev what the proper behavior should be at exit from
the child process of a fork from a spawned thread.
Right now, it seems that there
On Mon, Aug 31, 2009 at 5:01 PM, Greg Ewing wrote:
> Antoine Pitrou wrote:
>
> Did your coworker run any timings instead of basing his assumptions on
>> bytecode
>> size?
>>
>
> In any case, what are you suggesting -- that the last value
> returned by a function call in the body should be the
> d
On 1 Sep 2009, at 15:25 , Antoine Pitrou wrote:
Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit :
"We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly.
Well, feel free to prefer an unreadable language if you want :)
Smalltalk or Haskell are hardly inherently unreadable.
I fail to understand this crude logic.
If a function contains any looping (C or otherwise) or does much in
the way of meaningful work, then it's unlikely that the single POP_TOP
associated with an implied "return None" is taking much of the total
runtime.
Raymond
2009/8/31 xiaobing jiang :
> My idea is: here, the two functions (or maybe classes) should have the
> same behavior).
> so is this a bug or something I missing ?
I think they should both not check their arguments in __init__ to
allow for duck typing.
--
Regards,
Benjamin
__
On 1 Sep 2009, at 02:01 , Greg Ewing wrote:
I don't think the unpredictability that would introduce
would be a good idea.
I fail to grasp the unpredictability of "the last expression evaluated
in the body of a function is its return value".
It couldn't work in Python because statements aren't
On 1 Sep 2009, at 03:03 , Gregory P. Smith wrote:
On Mon, Aug 31, 2009 at 5:01 PM, Greg Ewing >wrote:
Antoine Pitrou wrote:
Did your coworker run any timings instead of basing his assumptions
on
bytecode
size?
In any case, what are you suggesting -- that the last value
returned by a fu
Le mardi 01 septembre 2009 à 15:09 +0200, Xavier Morel a écrit :
> "We" are not Erlang, Smalltalk, OCaml or Haskell either, sadly.
Well, feel free to prefer an unreadable language if you want :)
Having implicit return values is certainly not something which follows
Python's design principles. Even
On Tue, 1 Sep 2009 05:51:49 pm Scott Dial wrote:
> Raymond Hettinger wrote:
> >> I was just wondering if a bytecode for a superinstruction of the
> >> common sequence:
> >>
> >> 6 POP_TOP
> >> 7 LOAD_CONST 0 (None)
> >> 10 RETURN_VALUE
> >>
> >> might be worth it.
> >
> > [Collin Winter]
> >
> >> I
Raymond Hettinger wrote:
>> I was just wondering if a bytecode for a superinstruction of the common
>> sequence:
>>
>> 6 POP_TOP
>> 7 LOAD_CONST 0 (None)
>> 10 RETURN_VALUE
>>
>> might be worth it.
>
> [Collin Winter]
>> I doubt it. You'd save a bit of stack manipulation, but since this
>> will on
Brett Cannon wrote:
> On Mon, Aug 31, 2009 at 06:36, Nick Coghlan wrote:
>> That said, while actually ditching the C code might cause an argument,
>> expanding runpy with Python equivalents of the C level functionality
>> (i.e. run script by name, run directory/zipfile by name, '-c' switch,
>> and
Fred Drake wrote:
> Every time I've been bitten by the wrong co_filename values (usually
> from tracebacks), changing the way marshal creates code objects to use a
> values passed in has been the thing that made the most sense to me.
>
> The feature request that's involved here, getting correct co
Raymond Hettinger wrote:
>> I was just wondering if a bytecode for a superinstruction of the common
>> sequence:
>>
>> 6 POP_TOP
>> 7 LOAD_CONST 0 (None)
>> 10 RETURN_VALUE
>>
>> might be worth it.
>
> [Collin Winter]
>> I doubt it. You'd save a bit of stack manipulation, but since this
>> will on
29 matches
Mail list logo
