> > If you do need to avoid accidentally launching missiles then you need
> > to do some type checking - although ideally using isinstance() instead
> > of type(). But in the majority of cases some sensible documentation
> > and Python's culture that we are all adults here usually means you
>
"Roelof Wobben" wrote
Because I follow this book "Thinking like a computer scientist" and
I have only read the chapters about strings. lists and tuples.
And that book tries to use Python to teach a general Computing
Science degree 101 course. So it teaches you what are classically
considered g
> To: tutor@python.org
> From: alan.ga...@btinternet.com
> Date: Sun, 12 Sep 2010 20:52:06 +0100
> Subject: Re: [Tutor] recursive problem
>
> "Roelof Wobben" wrote
>
>>>> I guess the question to ask/consi
"Roelof Wobben" wrote
I guess the question to ask/consider is: How can be establish
whether a
particular object supports a particular interface/set of
behaviours
In general we "try" it and handle the exceptions
that we require? E.g. how do we most pythonically check whether
some
object "wa
> From: rwob...@hotmail.com
> To: st...@pearwood.info
> Subject: RE: [Tutor] recursive problem
> Date: Sun, 12 Sep 2010 07:58:48 +
>
>
>
>
>
>> From: st...@pearwood.info
>
On Sun, 12 Sep 2010 09:03:49 am Walter Prins wrote:
> So, perhaps it's an idea to call dir() on a given object and see
> whether the object provides the necessary methods to function, e.g.
> __iter__, __delitem__, __setitem__ and friends?
There's no need to do this:
attributes = dir(obj)
if '__i
Just a quick contribution for what it's worth: One of the subjects being
implicitly talked about here is "introspection" -- you may want to google
that and see else you can find. That said, a nice article covering some of
Python's introspection features is presented here on IBM's site:
http://www.i
> From: rwob...@hotmail.com
> To: st...@pearwood.info
> Subject: RE: [Tutor] recursive problem
> Date: Sat, 11 Sep 2010 18:39:31 +
>
>
>
>
>
>> From: st...@pearwood.info
>
On 09/12/10 03:18, Steven D'Aprano wrote:
> Or you could do this:
>
> if do_this_will_succeed() and do_that_will_succeed() \
> and do_something_else_will_succeed():
> do_this()
> do_that()
> do_something_else()
> else:
> do_error()
>
> But that hasn't done anything to prevent race
On Sun, 12 Sep 2010 04:09:20 am Roelof Wobben wrote:
> > On Sun, 12 Sep 2010 03:40:38 am Roelof Wobben wrote:
> >> But why is type checking then wrong.
> >> Lets says I want a module who must work on strings, tuple and
> >> lists.
> >
> > It's not *always* wrong, but let me ask you... why do you w
On Sun, 12 Sep 2010 04:01:39 am Walter Prins wrote:
> I guess the question to ask/consider is: How can be establish whether
> a particular object supports a particular interface/set of behaviours
> that we require? E.g. how do we most pythonically check whether some
> object "walks like a list" a
> From: st...@pearwood.info
> To: tutor@python.org
> Date: Sun, 12 Sep 2010 04:03:43 +1000
> Subject: Re: [Tutor] recursive problem
>
> On Sun, 12 Sep 2010 03:40:38 am Roelof Wobben wrote:
>
>> But why is type checking then w
On 09/12/10 04:01, Walter Prins wrote:
> I guess the question to ask/consider is: How can be establish whether a
> particular object supports a particular interface/set of behaviours that
> we require? E.g. how do we most pythonically check whether some object
> "walks like a list" and "quacks lik
> From: rwob...@hotmail.com
> To: wpr...@gmail.com
> Subject: RE: [Tutor] recursive problem
> Date: Sat, 11 Sep 2010 18:05:12 +
>
>
>
>
>
>> Date: Sat, 11 Sep 2010 19:01:39 +0100
On Sun, 12 Sep 2010 03:40:38 am Roelof Wobben wrote:
> But why is type checking then wrong.
> Lets says I want a module who must work on strings, tuple and lists.
It's not *always* wrong, but let me ask you... why do you want to
*limit* the function to work on ONLY strings, tuples and lists?
Th
> That's the whole point! You don't WANT to know what type it is. You want to
> just use it how you want, an if it behaves properly, who cares what type it
> is?
>
> See when you type check you are forcing the user to use those types. What
> if they want to derive a subclass from list? Is there rea
On Sep 11, 2010, at 12:40 PM, Roelof Wobben wrote:
>
>
>
>
>> From: st...@pearwood.info
>> To: tutor@python.org
>> Date: Sun, 12 Sep 2010 03:27:42 +1000
>> Subject: Re: [Tutor] recursive problem
>>
>>
> From: st...@pearwood.info
> To: tutor@python.org
> Date: Sun, 12 Sep 2010 03:27:42 +1000
> Subject: Re: [Tutor] recursive problem
>
> On Sun, 12 Sep 2010 03:18:19 am Steven D'Aprano wrote:
>
>> But that hasn't don
On Sun, 12 Sep 2010 03:18:19 am Steven D'Aprano wrote:
> But that hasn't done anything to prevent race conditions. So the real
> reason people use LBYL is that they're too lazy to write hideously
> ugly, but reliable, code, and they're just hoping that they will
> never expose the race condition.
> From: st...@pearwood.info
> To: tutor@python.org
> Date: Sun, 12 Sep 2010 03:18:19 +1000
> Subject: Re: [Tutor] recursive problem
>
> On Fri, 10 Sep 2010 09:30:23 pm Ewald Horn wrote:
>
>> While EAFP is great, it's not
&
On Fri, 10 Sep 2010 09:30:23 pm Ewald Horn wrote:
> While EAFP is great, it's not
> always the best way to proceed.
That, at least, is correct. But what you say next is not:
> Sometimes you want programs to be
> very robust and secure, this is where LBYL comes in - it is quite
> often used in
On 10 September 2010 13:14, Roelof Wobben wrote:
> Hello ,
>
> So my book teach me the wrong principle.
> But can everything programmed on Eafp.
>
> If you dont know if something is a list, a tuple or a string, you can get a
> lot of nested try except think.
>
> Roelof
>
Hi Roelof,
I don't thi
Hello ,
So my book teach me the wrong principle.
But can everything programmed on Eafp.
If you dont know if something is a list, a tuple or a string, you can get a lot
of nested try except think.
Roelof
Subject: Re: [Tutor] recursive problem
From: rabidpoob...@gmail.com
Date
Nope Joel, that's what I meant. Remember EAFP over LBYL! I'm not sure the best
way to make sure the object is iterable though.
Sent from my iPhone
On Sep 9, 2010, at 11:41 AM, Joel Goldstick wrote:
>
>
> On Thu, Sep 9, 2010 at 12:07 PM, Steven D'Aprano wrote:
> On Fri, 10 Sep 2010 01:05:22
On Thu, Sep 9, 2010 at 12:07 PM, Steven D'Aprano wrote:
> On Fri, 10 Sep 2010 01:05:22 am Joel Goldstick wrote:
> > On Thu, Sep 9, 2010 at 10:26 AM, Luke Paireepinart
> >
> > wrote:
> > > Shouldn't there be a way to do this without type checking? Duck
> > > typing!
> > >
> > > Your post got me thi
On Fri, 10 Sep 2010 01:05:22 am Joel Goldstick wrote:
> On Thu, Sep 9, 2010 at 10:26 AM, Luke Paireepinart
>
> wrote:
> > Shouldn't there be a way to do this without type checking? Duck
> > typing!
> >
> > Your post got me thinking. Maybe better to test if the object can
> > return
> an iter metho
On 09/09/2010 17.05, Joel Goldstick wrote:
On Thu, Sep 9, 2010 at 10:26 AM, Luke Paireepinart
mailto:rabidpoob...@gmail.com>> wrote:
Shouldn't there be a way to do this without type checking? Duck typing!
Your post got me thinking. Maybe better to test if the object can
return an iter me
On Thu, Sep 9, 2010 at 10:26 AM, Luke Paireepinart
wrote:
> Shouldn't there be a way to do this without type checking? Duck typing!
>
> Your post got me thinking. Maybe better to test if the object can return
an iter method. If it throws an error, then look at its value. If it
doesn't, then its
bben wrote:
>
>
> From: anand.shash...@gmail.com
> Date: Thu, 9 Sep 2010 15:08:10 +0530
> Subject: Re: [Tutor] recursive problem
> To: rwob...@hotmail.com
> CC: tutor@python.org
>
>
>
> On Thu, Sep 9, 2010 at 2:21 PM, Roelof Wobben wrote:
> Hello,
>
On Thu, Sep 9, 2010 at 7:59 AM, Shashwat Anand wrote:
>
>
> On Thu, Sep 9, 2010 at 3:11 PM, Roelof Wobben wrote:
>
>>
>>
>> --
>> From: anand.shash...@gmail.com
>> Date: Thu, 9 Sep 2010 15:08:10 +0530
>> Su
On 9 September 2010 12:59, Shashwat Anand wrote:
>
> Let's say n, l = 2, [2, 9, [2, 1, 13, 2], 8, [2, 6]]
> Simply Flatten the list l, which will be then be; flatten(l) = [ 2, [2, 9,
> 2, 1,13, 2, 8, 2, 6 ]
> Now count for n; flatten.count(n)
>
>
This is fine except that the excercise probably ha
On Thu, Sep 9, 2010 at 3:11 PM, Roelof Wobben wrote:
>
>
> --
> From: anand.shash...@gmail.com
> Date: Thu, 9 Sep 2010 15:08:10 +0530
> Subject: Re: [Tutor] recursive problem
> To: rwob...@hotmail.com
> CC: tutor@python.org
>
>
>
From: anand.shash...@gmail.com
Date: Thu, 9 Sep 2010 15:08:10 +0530
Subject: Re: [Tutor] recursive problem
To: rwob...@hotmail.com
CC: tutor@python.org
On Thu, Sep 9, 2010 at 2:21 PM, Roelof Wobben wrote:
Hello,
I have this :
def recursive_count(target, nested_num_list
On Thu, Sep 9, 2010 at 2:21 PM, Roelof Wobben wrote:
> Hello,
>
> I have this :
>
> def recursive_count(target, nested_num_list):
> """
> >>> recursive_count(2, [2, 9, [2, 1, 13, 2], 8, [2, 6]])
> 4
> >>> recursive_count(7, [[9, [7, 1, 13, 2], 8], [7, 6]])
> 2
>
Hello,
I have this :
def recursive_count(target, nested_num_list):
"""
>>> recursive_count(2, [2, 9, [2, 1, 13, 2], 8, [2, 6]])
4
>>> recursive_count(7, [[9, [7, 1, 13, 2], 8], [7, 6]])
2
>>> recursive_count(15, [[9, [7, 1, 13, 2], 8], [2, 6]])
0
35 matches
Mail list logo
