[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Passing a callable object to Thread

skawaii@gmail.com

2/16/2008 12:15:00 AM

I'm trying to execute a function in its own thread, due to this method
taking a very long time to complete. I really don't see the need to
inherit the Thread class, as basically every online example shows (at
least the ones I found), nor do I want to. I want to pass the method
into the Thread constructor and let it go wild.

The function I'm trying to execute is in a modulate called tribalwars
and has the following signature:

def populate_all_tribes(data_dir)

Below is the error I'm getting after initializing the thread:

>>> t = th.Thread(target=tribalwars.populate_all_tribes, args=("data/w7/"))
>>> t.start()
Exception in thread Thread-1:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/threading.py", line 462, in __bootstrap
self.run()
File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/threading.py", line 442, in run
self.__target(*self.__args, **self.__kwargs)
TypeError: populate_all_tribes() takes exactly 1 argument (8 given)

Can anybody clue me in on what I'm doing wrong? Does my function need
to have a different signature (i.e. *args, **kwargs) in order for this
to work?

Thanks,
skawaii
24 Answers

Paul Rubin

2/16/2008 12:24:00 AM

0

skawaii <skawaii@gmail.com> writes:
> >>> t = th.Thread(target=tribalwars.populate_all_tribes, args=("data/w7/"))
> TypeError: populate_all_tribes() takes exactly 1 argument (8 given)
>
> Can anybody clue me in on what I'm doing wrong? Does my function need
> to have a different signature (i.e. *args, **kwargs) in order for this
> to work?

Thread expects args to be a tuple or list or arguments. You passed it
a list of 8 characters (what we sometimes call a string). You wanted
a tuple containing that list:

t = th.Thread(target=tribalwars.populate_all_tribes, args=("data/w7/",))

skawaii@gmail.com

2/16/2008 12:51:00 AM

0

On Feb 15, 7:23 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> t = th.Thread(target=tribalwars.populate_all_tribes, args=("data/w7/",))

Thanks, that did it. After playing around in the interpreter a bit, I
realize now that args=("data/w7/") doesn't create a tuple, like I
thought it would. I have to say, though, having to add a comma at the
end is hideous syntax....

Steve Holden

2/16/2008 3:03:00 AM

0

skawaii wrote:
> On Feb 15, 7:23 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>> t = th.Thread(target=tribalwars.populate_all_tribes, args=("data/w7/",))
>
> Thanks, that did it. After playing around in the interpreter a bit, I
> realize now that args=("data/w7/") doesn't create a tuple, like I
> thought it would. I have to say, though, having to add a comma at the
> end is hideous syntax....

Assuming you're right, what alternative would you suggest? Would it
allow parenthesized expressions to retain their customary meaning?

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.hold...

Benjamin

2/16/2008 3:22:00 AM

0

On Feb 15, 6:51 pm, skawaii <skaw...@gmail.com> wrote:
> On Feb 15, 7:23 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
>
> > t = th.Thread(target=tribalwars.populate_all_tribes, args=("data/w7/",))
>
> Thanks, that did it. After playing around in the interpreter a bit, I
> realize now that args=("data/w7/") doesn't create a tuple, like I
> thought it would. I have to say, though, having to add a comma at the
> end is hideous syntax....

You could type args=tuple("data/w7/").

Carsten Haese

2/16/2008 3:32:00 AM

0

On Fri, 2008-02-15 at 19:21 -0800, Benjamin wrote:
> You could type args=tuple("data/w7/").

That will produce an 8-tuple containing single-character strings, not a
1-tuple containing one string.

--
Carsten Haese
http://informixdb.sourc...

Paul Rubin

2/16/2008 3:40:00 AM

0

Steve Holden <steve@holdenweb.com> writes:
> Assuming you're right, what alternative would you suggest? Would it
> allow parenthesized expressions to retain their customary meaning?

It is kind of weird that there is even such a thing as a 1-tuple.

Steve Holden

2/16/2008 3:53:00 AM

0

Paul Rubin wrote:
> Steve Holden <steve@holdenweb.com> writes:
>> Assuming you're right, what alternative would you suggest? Would it
>> allow parenthesized expressions to retain their customary meaning?
>
> It is kind of weird that there is even such a thing as a 1-tuple.

I agree that zero-length and singleton tuples don't make a great deal of
sense semantically. But by now there's been enough tuple-abuse that the
general wish is to have tuples behave exactly like lists.

Of course the singleton tuple was more or less bound to exist once the
DB API started returning result rows as tuples, and I suspect that them
empty tuple is an acceptable generalization.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.hold...

Jeff Schwab

2/16/2008 5:09:00 AM

0

Steve Holden wrote:
> Paul Rubin wrote:
>> Steve Holden <steve@holdenweb.com> writes:
>>> Assuming you're right, what alternative would you suggest? Would it
>>> allow parenthesized expressions to retain their customary meaning?
>>
>> It is kind of weird that there is even such a thing as a 1-tuple.
>
> I agree that zero-length and singleton tuples don't make a great deal of
> sense semantically.

Why not? They seem intuitive to me. I would find it weird if you
couldn't have 0-tuple, and even weirder if you couldn't have a 1-tuple.
Maybe my brain has been warped by too much C++ code.

In C++, it's very common to define data structures that have no members;
the moral equivalent of an empty tuple:

struct S { };

I recently did this in C, and was surprised to see this message from gcc:

main.c:1: warning: struct has no members

It's also common in C++ to treat a stand-alone object as an array of
length 1. This is useful because any function defined to take a
sequence of input can easily be given a single element instead:

int proto = 5;
std::vector<int> v(&proto, &proto + 1);

It strikes me that 1-tuples could serve the same purpose. It's common
now for functions to be defined to take single elements, with client
code using loops to process sequences:

for item in sequence:
process(item)

If functions were instead defined to take sequences, then client code
would be simplified, especially for common tasks like processing lines
of input.

process(sequence)

On occasions when only a single item were to be processed, a 1-tuple
would serve as a nice syntactic adapter:

process((item,))

Paul Rubin

2/16/2008 5:16:00 AM

0

Jeff Schwab <jeff@schwabcenter.com> writes:
> Why not? They seem intuitive to me. I would find it weird if you
> couldn't have 0-tuple, and even weirder if you couldn't have a
> 1-tuple. Maybe my brain has been warped by too much C++ code.

The idea is that a 2-tuple (of numbers, say) is a pair of numbers, a
3-tuple is three numbers, and a 1-tuple is one number. That would
mean a number and a 1-tuple of numbers are the same thing, not
separate types. This is how most type systems treat tuples.

Python does it a bit differently, treating tuples as something like
frozen lists, so they support subscripting, iterator interfaces and so
forth. There are practical advantages to doing it that way, but it
also leads to corners of oddness like the (a,) notation.

Jeff Schwab

2/16/2008 5:29:00 AM

0

Paul Rubin wrote:
> Jeff Schwab <jeff@schwabcenter.com> writes:
>> Why not? They seem intuitive to me. I would find it weird if you
>> couldn't have 0-tuple, and even weirder if you couldn't have a
>> 1-tuple. Maybe my brain has been warped by too much C++ code.
>
> The idea is that a 2-tuple (of numbers, say) is a pair of numbers, a
> 3-tuple is three numbers, and a 1-tuple is one number. That would
> mean a number and a 1-tuple of numbers are the same thing, not
> separate types.

No, that doesn't follow. A set with one element is not the same thing
as that element, a sequence of one element is not the same thing as that
element, and a tuple with one element is not the same thing as that element.

> This is how most type systems treat tuples.

I take it you have particular systems in mind, but I've never used a
programming language that works that way.

> Python does it a bit differently, treating tuples as something like
> frozen lists, so they support subscripting, iterator interfaces and so
> forth. There are practical advantages to doing it that way, but it
> also leads to corners of oddness like the (a,) notation.

That "oddness" has nothing to do with tuples-of-one being strange, nor
does it imply that tuples are fundamentally different from other
collection types. It is a historical accident of the fact that
parentheses were already used to represent grouping for precedence by
the time they were overloaded to represent tuples. If bare-paren tuples
had not been allowed (as bare sets are not allowed), then there would be
no ambiguity, and no need for the (a,) notation.