[EMAIL PROTECTED] (Alex Martelli) wrote in news:1i27mku.1sc8l3x1dda3crN%
[EMAIL PROTECTED]:
> Bruno Desthuilliers <[EMAIL PROTECTED]>
> wrote:
>
>> Alex Popescu a écrit :
>
> [... snip ...]
>
>
> The mere check of whether an object possesses some important special
> method is best accomplished t
Alex Martelli a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]>
> wrote:
>
>> Alex Popescu a écrit :
>>> Bruno Desthuilliers <[EMAIL PROTECTED]> wrote in
>>> news:[EMAIL PROTECTED]:
>> (snip)
if hasattr(obj, '__call__'):
# it's a callable
but I don't find it so Pythonic t
Bruno Desthuilliers <[EMAIL PROTECTED]>
wrote:
> Alex Popescu a écrit :
> > Bruno Desthuilliers <[EMAIL PROTECTED]> wrote in
> > news:[EMAIL PROTECTED]:
> (snip)
> >> if hasattr(obj, '__call__'):
> >># it's a callable
> >>
> >> but I don't find it so Pythonic to have to check for a __magic__
Alex Popescu a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
(snip)
>> if hasattr(obj, '__call__'):
>># it's a callable
>>
>> but I don't find it so Pythonic to have to check for a __magic__
>> method.
>
> It looks like Python devs have decided it is Py
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Steven D'Aprano a écrit :
> (snip)
>
>> Instead of doing:
>
>> if callable(function): function()
>>
>> you should do:
>>
>> try:
>> function()
>> except TypeError:
>> pass
>
> There are time where you may want
Steven D'Aprano a écrit :
(snip)
> Instead of doing:
>
>
> if callable(function): function()
>
> you should do:
>
> try:
> function()
> except TypeError:
> pass
There are time where you may want to know if you have a callable without
calling it...
> That should work for most uses of
John J. Lee a écrit :
> Alex Popescu <[EMAIL PROTECTED]> writes:
>
>
>>Zentrader <[EMAIL PROTECTED]> wrote in news:1185041243.323915.161230
>>@x40g2000prg.googlegroups.com:
>>
>>
>>>On Jul 21, 7:48 am, Duncan Booth <[EMAIL PROTECTED]> wrote:
>>>
>>>[snip...]
>>>
>>>
From the 2.6 PEP #361 (loo
On 7/28/07, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Sat, 28 Jul 2007 11:52:48 +, Alex Popescu wrote:
>
> > [EMAIL PROTECTED] (John J. Lee) wrote in news:[EMAIL PROTECTED]:
> >
> >> Alex Popescu <[EMAIL PROTECTED]> writes:
> >>
> >>> Zentrader <[EMAIL PROTECTED]> wrote in
> >>> news:1185
Steve Holden <[EMAIL PROTECTED]> writes:
[...]
> Yup. Anyway there's a trivial translation for uses of apply.
>
> apply(f, *args, **kw) => f(*args, **kw)
[...]
Steve means:
apply(f, args, kw) => f(*args, **kw)
John
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, 30 Jul 2007 07:37:05 +, Duncan Booth wrote:
> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
>>
>> Instead of doing:
>>
>>
>> if callable(function): function()
>>
>> you should do:
>>
>> try:
>> function()
>> except TypeError:
>> pass
>>
>>
>> That should work for most us
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
> Instead of doing:
>
>
> if callable(function): function()
>
> you should do:
>
> try:
> function()
> except TypeError:
> pass
>
>
> That should work for most uses of callable(), but isn't quite the
> same. (What if function() has side-e
On Sat, 28 Jul 2007 11:52:48 +, Alex Popescu wrote:
> [EMAIL PROTECTED] (John J. Lee) wrote in news:[EMAIL PROTECTED]:
>
>> Alex Popescu <[EMAIL PROTECTED]> writes:
>>
>>> Zentrader <[EMAIL PROTECTED]> wrote in
>>> news:1185041243.323915.161230 @x40g2000prg.googlegroups.com:
>>>
On Jul
Alex Popescu wrote:
> [EMAIL PROTECTED] (John J. Lee) wrote in news:[EMAIL PROTECTED]:
>
>> Alex Popescu <[EMAIL PROTECTED]> writes:
>>
>>> Zentrader <[EMAIL PROTECTED]> wrote in
>>> news:1185041243.323915.161230 @x40g2000prg.googlegroups.com:
>>>
On Jul 21, 7:48 am, Duncan Booth <[EMAIL PROT
[EMAIL PROTECTED] (John J. Lee) wrote in news:[EMAIL PROTECTED]:
> Alex Popescu <[EMAIL PROTECTED]> writes:
>
>> Zentrader <[EMAIL PROTECTED]> wrote in
>> news:1185041243.323915.161230 @x40g2000prg.googlegroups.com:
>>
>>> On Jul 21, 7:48 am, Duncan Booth <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>> [
Alex Popescu <[EMAIL PROTECTED]> writes:
> Zentrader <[EMAIL PROTECTED]> wrote in news:1185041243.323915.161230
> @x40g2000prg.googlegroups.com:
>
>> On Jul 21, 7:48 am, Duncan Booth <[EMAIL PROTECTED]> wrote:
>>
>> [snip...]
>>
>>
>>>From the 2.6 PEP #361 (looks like dict.has_key is deprecated)
Zentrader <[EMAIL PROTECTED]> wrote in news:1185041243.323915.161230
@x40g2000prg.googlegroups.com:
> On Jul 21, 7:48 am, Duncan Booth <[EMAIL PROTECTED]> wrote:
>
> [snip...]
>
>
>>From the 2.6 PEP #361 (looks like dict.has_key is deprecated)
> Python 3.0 compatability: ['compatibility'-->someon
On Sat, 21 Jul 2007 16:20:37 -0700, genro wrote:
> On Jul 19, 6:29 am, Bruno Desthuilliers
> <[EMAIL PROTECTED]> wrote:
>> No "surprise" here, but it can indeed be suboptimal if instanciating
>> myobject is costly.
>
> What about this way ?
>
> my_obj = my_dict.get(key) or my_dict.setdefault(key
On Jul 19, 6:29 am, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
>
> Myobject will be instanciated each time, yes.
>
> > and so if the initialization is expensive you
> > will probably see surprises.
>
> No "surprise" here, but it can indeed be suboptimal if instanciating
> myobject is costly.
On Jul 21, 7:48 am, Duncan Booth <[EMAIL PROTECTED]> wrote:
> "Rustom Mody" <[EMAIL PROTECTED]> wrote:
> > Can someone who knows about python internals throw some light on why
> x in dic
> > is cheaper than
> dic.has_key(x)
>
> > ??
>
>From the 2.6 PEP #361 (looks like dict.has_key is de
"Rustom Mody" <[EMAIL PROTECTED]> wrote:
> Can someone who knows about python internals throw some light on why
x in dic
> is cheaper than
dic.has_key(x)
>
> ??
>
Some special methods are optimised by having a reserved slot in the data
structure used to implement a class. The 'in' ope
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Alex Popescu a écrit :
>> Jakub Stolarski <[EMAIL PROTECTED]> wrote in
>
>
> [snip...]
>
>
> d = dict()
> answer = d.get('answer', 42)
> answer in d
> => False
>
Thanks. I think to make the 3rd approach completely eq
Carsten Haese <[EMAIL PROTECTED]> wrote:
> On Sat, 21 Jul 2007 09:22:32 +0530, Rustom Mody wrote
> > Can someone who knows about python internals throw some light on why
> > >>> x in dic
> > is cheaper than
> > >>> dic.has_key(x)
> >
> > ??
>
> I won't claim to know Python internals, but compili
Alex Popescu a écrit :
> Jakub Stolarski <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
>
>>Version 1 and 2 do different thing than version 3. The latter doesn't
>>add value to dict.
>>
>>As it was mentioned before, use:
>>1 - if you expect that there's no key in dict
>>2 - if you expe
Alex Popescu a écrit :
> Hi all!
>
> I am pretty sure this has been asked a couple of times, but I don't seem
> to find it on the archives (Google seems to have a couple of problems
> lately).
>
> I am wondering what is the most pythonic way of dealing with missing
> keys and default values.
>
On Sat, 21 Jul 2007 09:22:32 +0530, Rustom Mody wrote
> Can someone who knows about python internals throw some light on why
> >>> x in dic
> is cheaper than
> >>> dic.has_key(x)
>
> ??
I won't claim to know Python internals, but compiling and disassembling the
expressions in question reveals the
Can someone who knows about python internals throw some light on why
>>> x in dic
is cheaper than
>>> dic.has_key(x)
??
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, 20 Jul 2007 19:08:57 +, Alex Popescu wrote:
> I am wondering what is the most pythonic way of dealing with missing
> keys and default values.
[snip three versions]
Others have already mentioned the collections.defaultdict type, however it
seems people have forgotten about the setdef
Jakub Stolarski <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Version 1 and 2 do different thing than version 3. The latter doesn't
> add value to dict.
>
> As it was mentioned before, use:
> 1 - if you expect that there's no key in dict
> 2 - if you expect that there is key in dict
>
On Fri, 2007-07-20 at 19:39 +, Alex Popescu wrote:
> Neil Cerutti <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > On 2007-07-20, Alex Popescu <[EMAIL PROTECTED]> wrote:
> >> Hi all!
> >>
> >> I am pretty sure this has been asked a couple of times, but I
> >> don't seem to find it
On Fri, 2007-07-20 at 20:10 +, Alex Popescu wrote:
> Carsten Haese <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > On Fri, 2007-07-20 at 19:08 +, Alex Popescu wrote:
> >> Hi all!
> >>
>
> >
> > [snip...]
> >
> >
> > This is called "Look before you leap." Note that "if key
Version 1 and 2 do different thing than version 3. The latter doesn't
add value to dict.
As it was mentioned before, use:
1 - if you expect that there's no key in dict
2 - if you expect that there is key in dict
--
http://mail.python.org/mailman/listinfo/python-list
Neil Cerutti <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> On 2007-07-20, Alex Popescu <[EMAIL PROTECTED]> wrote:
>> Hi all!
>>
>> I am pretty sure this has been asked a couple of times, but I
>> don't seem to find it on the archives (Google seems to have a
>> couple of problems lately).
On Fri, 2007-07-20 at 19:08 +, Alex Popescu wrote:
> Hi all!
>
> I am pretty sure this has been asked a couple of times, but I don't seem
> to find it on the archives (Google seems to have a couple of problems
> lately).
>
> I am wondering what is the most pythonic way of dealing with missi
On 2007-07-20, Alex Popescu <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> I am pretty sure this has been asked a couple of times, but I
> don't seem to find it on the archives (Google seems to have a
> couple of problems lately).
>
> I am wondering what is the most pythonic way of dealing with missing
Hi all!
I am pretty sure this has been asked a couple of times, but I don't seem
to find it on the archives (Google seems to have a couple of problems
lately).
I am wondering what is the most pythonic way of dealing with missing
keys and default values.
According to my readings one can take t
35 matches
Mail list logo
