[Tutor] How to implement function like this?

[Yinghe Chen]

Hello gurus,

I have a question, a function like below, it is implemented by me, :)

def funcA(tarray):
   a = [2,3,4]
if len(tarray) >=3:
 return a[0],a[1], a[2]
elif len(tarray) == 2:
return a[0],a[1], funcB(1)[0]
elif len(tarray) == 1:
   return a[0], funcB(2)[0], funcB(2)[1]
else:
return funcB(3)[0], funcB(3)[1], funcB(3)[2]


The return of funcA is always 3 values, but depending on the length of
tarray, I need to return different values accordingly.  if tarray lenght is
2, I need to get another one value from funcB, if tarray length is 0, I need
to get all three values from funcB.


Is there a brief way to achieve it?

Thanks,
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] How to implement function like this?

[Alan Gauld]

"Yinghe Chen" <[EMAIL PROTECTED]> wrote

> def funcA(tarray):
>   a = [2,3,4]
>if len(tarray) >=3:
> return a[0],a[1], a[2]
>elif len(tarray) == 2:
>return a[0],a[1], funcB(1)[0]
>elif len(tarray) == 1:
>   return a[0], funcB(2)[0], funcB(2)[1]
>else:
>return funcB(3)[0], funcB(3)[1], funcB(3)[2]
> 
> 
> Is there a brief way to achieve it?

It looks fairly brief to me. There are a couple of things I 
might consider changing.

def funcA(tArray, defs = (2,3,4), func = funcB):
 if len(tArray) >= 3:
 return defs
 elif len(tArray) == 2:
  return defs[0],defs[1], func(2)[1]
 elif

By making defs a tuple you can return it directly and by 
making it a defaulted parameter you can change the 
values if needed without changing the funcA code.
Similarly by making funcB a default parameter you 
have the flexibility to change the algorithm used 
without changing funcA. But because they are default 
parameters you can still call it with just tArray as 
an argument.

A small change but may significantly improve the 
flexibility and possible reuse capability of funcA

HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] How to implement function like this?

[Kent Johnson]

Yinghe Chen wrote:
> Hello gurus,
> 
> I have a question, a function like below, it is implemented by me, :)
> 
> def funcA(tarray):
>a = [2,3,4]
> if len(tarray) >=3:
>  return a[0],a[1], a[2]
> elif len(tarray) == 2:
> return a[0],a[1], funcB(1)[0]
> elif len(tarray) == 1:
>return a[0], funcB(2)[0], funcB(2)[1]
> else:
> return funcB(3)[0], funcB(3)[1], funcB(3)[2]
> 
> 
> The return of funcA is always 3 values, but depending on the length of 
> tarray, I need to return different values accordingly.  if tarray lenght 
> is 2, I need to get another one value from funcB, if tarray length is 0, 
> I need to get all three values from funcB.

I think this works; not sure if it is better. The list() calls are not 
needed if tarray and the result of funcB are already lists; the tuple 
calls may not be needed either:

def funcA(tarray):
   a = [2,3,4]
   if len(tarray) >=3:
 return tuple(a)
   result = list(tarray) + list(funcB(3-len(tarray)))
   return tuple(result[:3])

Kent
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] How to implement function like this?

[Ricardo Aráoz]

Yinghe Chen wrote:
> Hello gurus,
> 
> I have a question, a function like below, it is implemented by me, :)
> 
> def funcA(tarray):
>a = [2,3,4]
> if len(tarray) >=3:
>  return a[0],a[1], a[2]
> elif len(tarray) == 2:
> return a[0],a[1], funcB(1)[0]
> elif len(tarray) == 1:
>return a[0], funcB(2)[0], funcB(2)[1]
> else:
> return funcB(3)[0], funcB(3)[1], funcB(3)[2]
> 
> 
> The return of funcA is always 3 values, but depending on the length of
> tarray, I need to return different values accordingly.  if tarray lenght
> is 2, I need to get another one value from funcB, if tarray length is 0,
> I need to get all three values from funcB.
> 
> 
> Is there a brief way to achieve it?
> 



def funcA(tArray) :
a = [2,3,4]
L = min(len(tArray), 3)
return tuple(i for n, i in enumerate(a) if n < L)+tuple(funcB(len(a)-L))




___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] calling a variable name

[Ricardo Aráoz]

Kent Johnson wrote:
> Bryan Fodness wrote:
>> Thank you.  This works well.  I am still trying to figure out the pros 
>> and cons of using an array, dictionary or list.
> 
> Array is specialized, you probably want list or dict.
> 
> Use list when you want a sequence of items indexed by sequential integers.
> Lists
> - preserve order
> - are fast for indexed lookup
> - are relatively slow (O(n)) for adding, deleting and searching (though 
> for small lists this should not be a consideration)

Are you sure they take O(n) for adding? I would have thought it would
take O(1).


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

[Tutor] A new Kent essay: A Brief Introduction to Beautiful Soup

[Dick Moores]

Dick Moores

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] A new Kent essay: A Brief Introduction to Beautiful Soup

[Eric Walstad]

Dick Moores wrote:
> 

That looks like a very nice, concise tutorial that should help soup
noobs like me to get up and running quickly.  I like the added value of
comments like: "Under the hood, attribute access is actually a search
for the first tag of the correct type, so soup.title will also access
the first  tag."

I haven't needed BeautifulSoup yet, but I know I will some day.

Thanks for sharing, Kent.

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] A new Kent essay: A Brief Introduction to Beautiful Soup

[Ted Roche]

On 10/23/07, Dick Moores <[EMAIL PROTECTED]> wrote:
> 

And if you're in the Manchester, New Hampshire, USA area, perhaps you
can stop by Thursday night and witness Kent himself presenting his
essay and a follow-on scrum using Beautiful Soup to parse out a couple
of web pages:

http://dlslug.org/pipermail/python-talk/2007-October/000639.html

-- 
Ted Roche
Ted Roche & Associates, LLC
http://www.tedroche.com
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] A new Kent essay: A Brief Introduction to Beautiful Soup

[Eric Brunson]

That's funny.  Knowing Alan is from the UK, when I saw Kent was from 
Manchester I thought he was Alan's countrymate.

You know the British (at least my cousins) make fun of us for always 
having to say our state.  "Paris, Texas", "Boston, Mass", "Tampa, FL".  
But, we just have so many more towns, everyone started reusing the 
names, not to mention that most of the names we didn't steal from the 
natives, we jacked from the old world.  ;-)

Ted Roche wrote:
> On 10/23/07, Dick Moores <[EMAIL PROTECTED]> wrote:
>   
>> 
>> 
>
> And if you're in the Manchester, New Hampshire, USA area, perhaps you
> can stop by Thursday night and witness Kent himself presenting his
> essay and a follow-on scrum using Beautiful Soup to parse out a couple
> of web pages:
>
> http://dlslug.org/pipermail/python-talk/2007-October/000639.html
>
>   

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

[Tutor] Logging in Linux

[wormwood_3]

Hello tutors,

I have become familiar with the basic use of the logging module. I have a 
program that prints out warning messages as well as info messages as it runs, 
merely dumping them into stdout. When I make such a script into a cron job, I 
simply redirect this output to /dev/null.

Now, what I would like to do is instead send this output to one or more of the 
standard linux log files. First though, I am wondering, what is the standard 
procedure in a case like this? Is it more appropriate to make a totally 
separate log file for all user-added scripts (or one a piece), and put them in 
/var/log or elsewhere? Where have you all found to be helpful places to log 
messages from automated scripts on Linux systems? The end goal is simply to 
have a place that I can check to see that the script is running as expected, or 
troubleshoot issues if need arise.

Thanks for any help or tips,
Sam


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] calling a variable name

[Kent Johnson]

Ricardo Aráoz wrote:
> Kent Johnson wrote:
>> Use list when you want a sequence of items indexed by sequential integers.
>> Lists
>> - preserve order
>> - are fast for indexed lookup
>> - are relatively slow (O(n)) for adding, deleting and searching (though 
>> for small lists this should not be a consideration)
> 
> Are you sure they take O(n) for adding? I would have thought it would
> take O(1).

Perhaps I was a bit hasty.

Lists are implemented as arrays of references. I believe they are
- amortized O(1) for append - occasionally the list must be reallocated 
and copied
- O(1) for delete from the end ?
- O(n) for insert and delete not at the end - the values above the 
insert/delete must be copied
- O(n) for search which is sequential search

Kent
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] How to implement function like this?

[Kent Johnson]

Ricardo Aráoz wrote:
> Yinghe Chen wrote:
>> Hello gurus,
>>
>> I have a question, a function like below, it is implemented by me, :)
>>
>> def funcA(tarray):
>>a = [2,3,4]
>> if len(tarray) >=3:
>>  return a[0],a[1], a[2]
>> elif len(tarray) == 2:
>> return a[0],a[1], funcB(1)[0]
>> elif len(tarray) == 1:
>>return a[0], funcB(2)[0], funcB(2)[1]
>> else:
>> return funcB(3)[0], funcB(3)[1], funcB(3)[2]

> def funcA(tArray) :
> a = [2,3,4]
> L = min(len(tArray), 3)
> return tuple(i for n, i in enumerate(a) if n < L)+tuple(funcB(len(a)-L))

tuple(i for n, i in enumerate(a) if n < L) can be written
tuple(a[:L])

funcB(len(a)-L) does not do what the OP requested. For example if len(a) 
is 10, L will be 3 and you will call funcB(7).

Kent
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

[Tutor] Complexity of list operations

[Danny Yoo]

>> Use list when you want a sequence of items indexed by sequential 
>> integers. Lists
>> - preserve order
>> - are fast for indexed lookup
>> - are relatively slow (O(n)) for adding, deleting and searching (though
>> for small lists this should not be a consideration)
>
> Are you sure they take O(n) for adding? I would have thought it would 
> take O(1).


One thing to be careful of: Python "lists" are not linked lists: they 
really are sequential array-like things that auto-expand.  That means 
inserts can be potentially expensive depending on where we do the insert.


The worst case scenario for Python's list operations (insert, delete) 
happens when we're applying those operations to the very head of the list. 
The reasoning is because inserting an element forces us to move all the 
other elements all up by one place: they've got to make room for their new 
neighbor!  By the same reasoning, deletes from the front can also be a 
linear-time operation because it forces the remainder of the elements to 
fill in the gap.


(For the math heads out there: if it takes some constant 'k' time to move 
an element, and if we start with an empty list and spam it with N inserts 
at the front, then the total amount of time it takes to do those N
operations will be 0 + 1*k + 2*k + ... + (N-1)*k, and that's a "Gauss sum" 
that collapses to (N*(N-1)/2)*k.  That is, in this worst case scenario, it 
takes time quadratic in the number of elements to insert N elements!)


That being said, if all our operations are applied only at the end of the 
list, the time complexity of those two operations look better.  We can 
argue for O(1) behavior under that particular restriction.  But I think 
Kent was considering the worst-case behavior, since it's an upper bound on 
how bad things can get.
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Complexity of list operations

[Dave Kuhlman]

On Tue, Oct 23, 2007 at 08:17:33PM -0400, Danny Yoo wrote:

[helpful explanation snipped]

> 
> That being said, if all our operations are applied only at the end of the 
> list, the time complexity of those two operations look better.  We can 
> argue for O(1) behavior under that particular restriction.  But I think 
> Kent was considering the worst-case behavior, since it's an upper bound on 
> how bad things can get.

Danny -

Thanks for this explanation.  I've wondered about the costs of
using a list as a FIFO data structure (first in, first out), and
doing, for example:

lst.insert(0, obj)

and:

obj = lst.pop()

Also, this is probably a good place to mention deque
(http://docs.python.org/lib/deque-objects.html), which attempts to
reduce those costs.

Dave

-- 
Dave Kuhlman
http://www.rexx.com/~dkuhlman
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] calling a variable name

[Dave Kuhlman]

On Tue, Oct 23, 2007 at 10:10:24PM -0400, Kent Johnson wrote:

[snip]

> 
> Perhaps I was a bit hasty.
> 
> Lists are implemented as arrays of references. I believe they are
> - amortized O(1) for append - occasionally the list must be reallocated 
> and copied

OK. I'm groping here.  Wikipedia tells me that O(1) means constant
increase.  So, what does "amortized O(1)" mean.

My understanding is that appending in lists is optimized in the
sense that when more space is needed, Python allocates space for
additional elements so that allocation does not need to happen at
every append.  Here is a comment from the Python source code
(Python-2.5.1/Objects/listobject.c):

/* This over-allocates proportional to the list size, making room
 * for additional growth.  The over-allocation is mild, but is
 * enough to give linear-time amortized behavior over a long
 * sequence of appends() in the presence of a poorly-performing
 * system realloc().
 * The growth pattern is:  0, 4, 8, 16, 25, 35, 46, 58, 72, 88, ...
 */

Hmmm.  There is that "amortized" thing again.  Very suspicious. 
For a non-math and non-financial type like me, is it sort of like
saying that the costs are averaged out over a sequence of appends?

Dave

-- 
Dave Kuhlman
http://www.rexx.com/~dkuhlman
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor