Re: Most efficient way to pre-grow a list?
Quoting Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr: Another situation where one may want to do this is if one needs to initialize a non-sparse array in a non-sequential order, Then use a dict. Ok, he has a dict. Now what? He needs a non-sparse array. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: id( ) function question
It's believable if id({}) does the following:
1. Construct an empty dict
2. Take the id of the dict
3. Reduce the reference-count on the now-unneeded dict.
It's not too hard for the second empty dict to get allocated in the same
memory that the first one (now dereferenced and deallocated) used, so
CPython gives it the same id value.
Wow, I never thought about it, but at least in my system, it seems to work like
that:
In [6]: id({1:2}) == id({3:4})
Out[6]: True
Interesting...
(only as a curiosity, though... One shouldn't rely on that)
--
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie
--
Participe en Universidad 2010, del 8 al 12 de febrero de 2010
La Habana, Cuba
http://www.universidad2010.cu
--
http://mail.python.org/mailman/listinfo/python-list
Re: Subclass dynamically
Quoting Robert Dailey rcdai...@gmail.com: Hey, I have a class that I want to have a different base class depending on a parameter that I pass to its __init__method. For example (pseudocode): 1- Are you sure that you want that behavior? Given that in python, a class is just a particular case of invocable object, you could just write a function instead, and the code may be more robust. 2- If you are /sure/ that is the behavior you want, take a look at the __new__ method. The __new__ can decide which instance to return (you could even define a new class inside of it, instantiate it, and return the instance). 3- You may want to take a look at metaclasses. But without more details about why you want it, I can't give you more precise answers. Regards, -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: initializing with empty list as default causes freaky problems
Quoting Reckoner recko...@gmail.com: Hi, Observe the following: In [202]: class Foo(): .: def __init__(self,h=[]): .: self.h=h [...] In [207]: f.h.append(10) In [208]: f.h Out[208]: [10] In [209]: g.h Out[209]: [10] The question is: why is g.h updated when I append to f.h? Shouldn't g.h stay []? What you are seeing is basically the same that happens here: === In [1]: def f(l=[]): ...: l.append(1) ...: print l ...: In [2]: f() [1] In [3]: f() [1, 1] In [4]: f() [1, 1, 1] === The problem is that the default value [] is evaluated only once, at function creation time, and not at invocation. Thus, every call to the function shares the same default object. That is consistent with python's function type: the def construct just creates a function object and initializes it with the code, argument list and default values. That means that the default value are part of the function object itself, regardless of when/if it is called: === In [5]: f.func_defaults Out[5]: ([1, 1, 1],) === The recommended way of dealing with this case (mutable default arguments) is: def f(l = None): if l is None: l = [] # the code goes here. (in your case, your g.__init__ and f.__init__ methods share the same Foo.__init__ function, and thus, share the same default value []) That is a very common python gotcha, and I think it is well documented in the standard doc (but I can't find it right now, sorry). Unfortunately, it doesn't become intuitive until you've spent a while understanding python's execution model (and then you suddenly realize that it just makes sense). [And now I wonder... how other languages do it? I've spent so much time with python that reevaluating the default argument on invocation feels clumsy, but I'm obviously tainted now...] Regards, -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: Help understanding the decisions *behind* python?
Quoting Inky 788 inky...@gmail.com:
The good reason is the immutability, which lets you use
a tuple as a dict key.
Thanks for the reply Hendrik (and Steven (other reply)). Perhaps I'm
just not sophisticated enough, but I've never wanted to use a list/
tuple as a dict key. This sounds like obscure usage, and a bit
contrived as a reason for having *both* lists and tuples.
I don't seem to understand your definition of obscure and contrived. It seems
that you got late to this thread, and you missed the examples. I'd suggest you
to go back on this thread and look at them.
heights = {}
heights[1,2] = 5
heights[1,3] = 7
heights[3,5] = 1
addresses[lastname, firstname] = my_home_address
census[location, age] = census.get((location, age), 0) + 1
All those are using tuples as dict keys.
Regards,
--
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie
--
Participe en Universidad 2010, del 8 al 12 de febrero de 2010
La Habana, Cuba
http://www.universidad2010.cu
--
http://mail.python.org/mailman/listinfo/python-list
Re: missing 'xor' Boolean operator
Quoting Jean-Michel Pichavant jeanmic...@sequans.com: Emile van Sebille wrote: On 7/16/2009 7:04 AM Unknown said... On 2009-07-16, Emile van Sebille em...@fenx.com wrote: daysInAdvance = int(inputVar) or 25 I don't get it. That doesn't work right when inputVar == 0. Aah, but you didn't get to define right. :) For that particular example 0 is not a valid response. When I was talking about such error prone form of boolean operations, I didn't expect to be right so quickly :p What do you mean by being right so quickly, and error prone in this context? I would also ask Unknown why he believes that int(intputVar) or 25 doesn't work right when inputVar == 0. The only false value that int() may return is zero, so the or 25 clause is there only for that case. I can't see then how you think that is an error. I'm not sure it makes sens anyway. I mean, I could easily argue that the number 0 is something. In the end I wonder if I shouldn't just acknowledge the python mechanism Then look it another way. The Empty/Nothing is just standard practice, there is nothing in python that forces you to be false if you are empty, or true otherwise. Instead, answer this: why do you need a /boolean/ value? Is there any case where you need to be certain that the object's type is 'bool'? If you think the answer is yes, you may want to get more familiar with the duck typing concept. (That doesn't mean that there are no legitimate cases where duck typing is inappropriate, but that there are many cases where people, specially if they come from statically typed languages, may believe that it is inappropriate when it isn't). In the python world, one should care more about how an object /behaves/ than from what clase it came. If something quacks like a duck, then assume that it is a duck, at least for the quacking part. Most python objects carry a truth value. Sometimes it feels natural (None is false, boolean True and False are true and false, empty containers are expected to be false, 0 and '' are false). Sometimes, it is everything but natural, but that's a problem with the object's implementation (datetime.time comes to mind). So, you shouldn't care if you have a bool instance - it should be enough that it behaves like a bool (though, if you need a bool, you can always construct one). The True or False expression could return Giraffes, as long as Giraffes behave like the bool True in boolean context. If you care about the class of the result, you can ask for its truth value, and if you don't care about it, you can just ignore it, and use it as you would use a bool. And then, if you can return any object as long as it behaves properly, what would be better to return? A new bool? Why not new Giraffe, if they will have the same behaviour? Guido chose to return the a value that will say more about the result of the operation than just a boolean. It acts as a boolean - if you don't need anything else, treat it as such -, but it will be, whenever is possible, one of the objects in the sequence, in case you need more info. without trying to find any intuitive/natural/obvious logic in it, knowing that sometimes the Truth lies far away from the Evidence. Don't do that. Many of python's decisions are very well thought. You may disagree with them, as I do with some, but they are rarely taken lightly. And this is one that I find very agreeable and in line with the rest of python's philosophy. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: Exotic Logics
Quoting Lie Ryan lie.1...@gmail.com: pdpi wrote: On Jun 17, 5:37 pm, Lie Ryan lie.1...@gmail.com wrote: Steven D'Aprano wrote: On Tue, 16 Jun 2009 22:46:14 -0700, William Clifford wrote: I was staring at a logic table the other day, and I asked myself, what if one wanted to play with exotic logics; how might one do it? This might be useful for you, and if not useful, at least it might blow your mind like it did mine. (This is not original to me -- I didn't create it. However, I can't find the original source.) Imagine for a moment that there are no boolean values. There are no numbers. They were never invented. There are no classes. There are no objects. There are only functions. Could you define functions that act like boolean values? And could you define other functions to operate on them? [basic lambda calculus definitions] [...] What I meant was: if you can pass a function as an argument to another function, that means either: 1) you must use function pointer (numbers) or 2) function is a first-class object. Both violates the restriction (no number and no object respectively). Even after abandoning the semantics of functions in python, going to function as in purely mathematical sense, I still am not convinced (warning: I don't know lambda calculus, although I program in heavily functional style). You are confusing semantics with implementation. At some point, of course one would need to use real object (at the lowest level, the computer I'm typing this in is a physical object). But the interesting part is that you can define the whole logic system using nothing but functions. You may need to implement it using objects, or maybe you could devise a machine that will behave like that using only sticks on the floor, but that doesn't matter. From the user's perspective, there would be only functions: no strings, no objects, no numbers. That reminds me of my last class (disclaimer: I teach discrete math). I told my students well, let's assume that numbers exist, and I wasn't making fun of them... I found that topic easier to understand (computability, primitive recursion) if one ignores the numbers, even if one obviously has to write them somewhere at some point. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding a Par construct to Python?
Quoting Carl Banks pavlovevide...@gmail.com: I don't have any reply to this post except for the following excerpts: On May 20, 8:10 pm, Luis Alberto Zarrabeitia Gomez ky...@uh.cu wrote: 2- in [almost] every other language, _you_ have to be aware of the critical sections when multithreading. [snip] That's not what I said. We are not talking about the _language_, but about one very specific implementation detail. Not even that, I'm talking about one of the reasons presented in favor of that specific implementation detail (while agreeing with the others). [...] No other languages have nesting by indentation (while still being reasonablyt successful) etc Comparisons to other languages are useless here. In many cases Python does things differently from most other languages and usually it's better off for it. You seem to have missed that I'm not talking about the language but about a specific implementation detail of CPython. I thought that my poor choice of words in that sentence was completely clarified by the paragraphs that followed, but apparently it wasn't. In my 2- point, maybe I should've said instead: in [almost] every language, INCLUDING (proper) PYTHON, you have to be aware of critcal sections when multithreading. The fact that other languages do something differently doesn't mean that other way's better, in fact it really doesn't mean anything at all. No, it doesn't mean that it's better, and I didn't say it was. But it _does_ show that it is _possible_. For an argument about how hard could be to write native extensions in there was no GIL, the fact that there are many other GIL-less platforms[1] where is not painful to write native extensions is a valid counter-example. And that, in all those languages and platforms (including python), the only one where I hear that explicit, granular locking is too hard or whatever[2], is CPython's /native/ extensions, is what I found weird. Regards, Luis [1] Including the python implementations for .net and java. [2] Really, this is was my question and nothing more. I was not comparing, I was trying to understand what was that whatever that made it so hard for CPython. And your footnote in the previous message gave me a reasonable explanation. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding a Par construct to Python?
Quoting Carl Banks pavlovevide...@gmail.com: On May 20, 4:07 pm, Luis Zarrabeitia ky...@uh.cu wrote: On Wednesday 20 May 2009 06:16:39 pm Aahz wrote: The designers of Python made a design decision(**) that extension writers would not have to take care of locking. They could have made a different decision, they just didn't. Well, then, maybe that's the only python's decision so far I may not agree with. And I'm not criticizing it... but I'm questioning it, because I honestly don't understand it. There must be another reason (i.e, the refcounts) to argue _for_ the GIL, Why? 1- refcounts is a _very_ strong reason to argue for the GIL. Add to that simplifying CPython implementation, and you don't really need another one on top of that, at least not to convince me, but 2- in [almost] every other language, _you_ have to be aware of the critical sections when multithreading. Even in pure python, you have use locks. Don't you find at least a bit odd the argument that in the particular case you are writing a C extension from python, you should be relieved of the burden of locking? because this one just seems to be just an attempt to fix unsafe code when called from python. I think you are being unfair in calling it unsafe. I think I was unfair calling it a fix. It sounds like it was broken, my bad. I should have used 'not multithread-ready'. Suppose if I were to call PyList_Append from a C extension. It's not necessary for me to guard the list I'm calling it on with a lock, because only the GIL thread is allowed to call most Python API or otherwise access objects. But you seem to be suggesting that since I didn't guard the list with a lock it is unsafe, even though the GIL is sufficient? Certainly not. If you program under the assumption that you have a GIL, of course it is not unsafe. Not your code, anyway. But, why is PyList_Append not multithread-ready? (or rather, why does PyList_Append would requiere a _global_ lock to be multithread ready, instead of a more local lock?) Of course, given that the GIL exists, to use it is the easier solution, but for this particular case, it feels like discarding multithreading just to avoid locking. No, I totally disagree. The code is not unsafe and the GIL doesn't fix it. The code is jsut [I think there was a word missing from that sentence...) And that was my point. Refcounts + interpreter simplicity seem to imply the need for a GIL, but to make unsafe code safe without fixing said code (or even thinking about it) is a weird goal... Why? Do you seriously not see the benefit of simplifying the work of extention writers and core maintainers? You don't have to agree that it's a good trade-off but it's a perfectly reasonable goal. I do agree that, at least for the core maintainers, it is a good trade-off and a reasonable goal to keep CPython simple. And if that has, as a positive side efect for extensions writers, that their code becomes easier, so be it. What I don't agree - rather, what I don't understand, is why it is presented in the opposite direction. I highly suspect Aahz here would argue for a GIL even without the refcount issue, and even though I wouldn't agree, there's nothing weird or unreasonable about the argument, it's just a different viewpoint. I consider it weird, at least. If I were to say that python should not allow multithreading to simplify the lives of pure-python programmers, I hope I would be shot down and ignored. But somehow I must consider perfectly natural the idea of not allowing[1] multithreading when building C extensions, to simplify the lives of extension programmers. specially if it became the only reason for a GIL. After all, one could argue for that goal in almost all languages. B-B-B-But other languages do it that way! is not a big factor in language decisions in Python. That's not what I said. We are not talking about the _language_, but about one very specific implementation detail. Not even that, I'm talking about one of the reasons presented in favor of that specific implementation detail (while agreeing with the others). The fact that the reason I'm having trouble with is valid for almost any other language, and none of them have a GIL-like construct (while still being successful, and not being exceptionally hard to build native modules for) just suggests that _that_ particular reason for that particular implementation detail is not a very strong one, even if all other reasons are. (**) - To be fair, Python didn't originally support threads, so there was a lot of code that would have become unsafe had threading been added without the GIL, and that probably influenced the decision to use a GIL, but I'm sure that wasn't only reason. Would Python have a GIL if threading had been there from the start? Who knows. (This is a very good remmark. Maybe here lies the whole answer to my question. We may be dragging the heavy chain of backward compatibility
Re: pushback iterator
Quoting Mike Kazantsev mk.frag...@gmail.com: And if you're pushing back the data for later use you might just as well push it to dict with the right indexing, so the next pop won't have to roam thru all the values again but instantly get the right one from the cache, or just get on with that iterable until it depletes. What real-world scenario am I missing here? Other than one he described in his message? Neither of your proposed solutions solves the OP's problem. He doesn't have a list (he /could/ build a list, and thus defeat the purpose of having an iterator). He /could/ use alternative data structures, like the dictionary you are suggesting... and he is, he is using his pushback iterator, but he has to include it over and over. Currently there is no good pythonic way of building a functions that decide to stop consuming from an iterator when the first invalid input is encountered: that last, invalid input is lost from the iterator. You can't just abstract the whole logic inside the function, something must leak. Consider, for instance, the itertools.dropwhile (and takewhile). You can't just use it like i = iter(something) itertools.dropwhile(condition, i) # now consume the rest Instead, you have to do this: i = iter(something) i = itertools.dropwhile(condition, i) # and now i contains _another_ iterator # and the first one still exists[*], but shouldn't be used # [*] (assume it was a parameter instead of the iter construct) For parsing files, for instance (similar to the OP's example), it could be nice to do: f = file(something) lines = iter(f) parse_headers(lines) parse_body(lines) parse_footer(lines) which is currently impossible. To the OP: if you don't mind doing instead: f = file(something) rest = parse_headers(f) rest = parse_body(rest) rest = parse_footer(rest) you could return itertools.chain([pushed_back], iterator) from your parsing functions. Unfortunately, this way will add another layer of itertools.chain on top of the iterator, you will have to hope this will not cause a performace/memory penalty. Cheers, -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: Self function
Quoting Rhodri James rho...@wildebst.demon.co.uk: I'm sorry, but while I'm mildly positive towards the proposal (and more so towards Aaron's decorator), I don't buy this argument at all. What is broken about your editor's global search-and-replace function that makes it usually useless for making these name changes? It happened to me sometimes. If a module defines some functions, and it doesn't *use* them, why should I use a global search-and-replace to rename something? Modifying the def line should be enough - unless the function happens to be recursive. So the answer to my question would be nothing? Indeed, there is nothing broken with the search and replace feature of his editor. When he is copying a non-recursive function, it is _useless_ to do a search and replace. When he is copying a recursive function, it is _required_ to do a search and replace. So, the very same task requires you to either perform a task that will almost always be useless (or even dangerous), or to read the source code to find out if the function is recursive, so that you can use the search and replace only then. (I know that the problem is present in almost all programming languages... but that's not what is being discussed. Bearophile's concerns seem legitimate, and you should not dismiss them so lightly just because there are ways to do more work and hopefully avoid the problems. I'd say that the problem is even aggravated in python, where the dynamic nature of the language makes it near to impossible to build good refactoring tools) -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: Self function
Quoting Steven D'Aprano ste...@remove.this.cybersource.com.au: But regardless, everyone is missing the most important point: why are you copying and pasting code in the first place? That is surely very close to the top of the list of Worst Ever Anti-Patterns, and it should be avoided whenever possible. [btw, I took this long before jumping into this thread for this precise reason... Copy/paste is an evil anti-pattern. In Python, we can avoid much copy-and-paste coding with decorators. Given one function, we can create as many variants as we want, differing in pre- processing of arguments and post-processing of results, by using decorators. This is a powerful ability to have, but it's crippled for many recursive functions, because recursive functions in Python don't actually call themselves, they call whatever happens to be bound to their name at runtime. A bit offtopic: a while ago I think I saw a recipe for a decorator that, via bytecode hacks, would bind otherwise global names to the local namespace of the function. Can anyone remember it/point me to it? An @bind decorator that would 'localize' all the global names, including the still unexistent but already know function name, would guarantee that at least recursion calls the same function instead of whatever happens to be bound to their name at runtime. If it wasn't a hack, anyway. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiprocessing.Queue - I want to end.
Quoting Cameron Simpson c...@zip.com.au: | And as it happens I have an IterableQueue class right here which does | _exact_ what was just described. You're welcome to it if you like. | Added bonus is that, as the name suggests, you can use the class as | an iterator: | for item in iterq: | ... | The producer calls iterq.close() when it's done. Someone asked, so code appended below. [...] Thank you!. I tested it, and it seems to work... and having the queue be an iterable is a plus. Thank you, Cameron MRAB! -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiprocessing.Queue - I want to end.
Quoting Hendrik van Rooyen m...@microcorp.co.za: Luis Zarrabeitia akaky...@uh.cu wrote: 8 ---explanation and example of one producer, 8 ---more consumers and one queue As you can see, I'm sending one 'None' per consumer, and hoping that no consumer will read more than one None. While this particular implementation You don't have to hope. You can write the consumers that way to guarantee it. I did. But that solution is not very reusable (I _must_ remember that implementation detail every time) and most important, i'll have to remember it in a few months with I'm updating the code. ensures that, it is very fragile. Is there any way to signal the consumers? Signalling is not easy - you can signal a process, but I doubt if it is possible to signal a thread in a process. (or better yet, the queue itself, as it is shared by all consumers?) Should close work for this? (raise the exception when the queue is exhausted, not when it is closed by the producer). I haven't the foggiest if this will work, and it seems to me to be kind of involved compared to passing a sentinel or sentinels. Well, that would be a vaild signal. Too bad I have to pass it by hand, instead of the queue class taking care of it for me. I have always wondered why people do the one queue many getters thing. Given that the stuff you pass is homogenous in that it will require a similar amount of effort to process, is there not a case to be made to have as many queues as consumers, and to round robin the work? Abstraction. This problem is modeled nicely as a producer-consumer (it would be in fact a classic producer-consumer). I could take care of the scheduling myself, but there are already good scheduling algorithms written for my OS, that take into account both the available CPU and IO. A solution may not be a queue (in my case, I don't care the order in which the elements are processed, only that they are), but ideally I would just be 'yielding' results on my producer(s), and receiving them on my consumer(s), leaving the IPC mechanism to deal with how to move the data from producers to consumers (and to which consumers). And if the stuff you pass around needs disparate effort to consume, it seems to me that you can more easily balance the load by having specialised consumers, instead of instances of one humungous I can eat anything consumer. Not necessarily. The load may depend on the size of the data that was sent. The consumers are receiving the same kind of data, only the sizes are different (non-predictable different). Again, I could try to implement some heuristics to try and guess what processor has lower load, but I'd rather delegate that to the OS. I also think that having a queue per consumer thread makes it easier to replace the threads with processes and the queues with pipes or sockets if you need to do serious scaling later. This is already multiprocess. It could be nice to extend it to multi-computers later, but the complexity is not worth it right now. In fact I happen to believe that anything that does any work needs one and only one input queue and nothing else, but I am peculiar that way. Well, I also need some output. In my case, the outputs are files with the result of the processing, that can be summarized later (hence the need to 'join' the processes, to know when I can summarize them). Thank you. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: Multiprocessing.Queue - I want to end.
Quoting Dennis Lee Bieber wlfr...@ix.netcom.com: I'm not familiar with the multiprocessing module and its queues but, presuming it behaves similar to the threading module AND that you have design control over the consumers (as you did in the sample) make a minor change. queue.put(None) ONCE in the producer Then, in the consumer, after it sees the None and begins shutdown processing, have the consumer ALSO do queue.put(None) Thank you. I went with this idea, only that instead of modifying the consumer, I modified the queue itself... Well, Cameron Simpson did :D. It's working nicely now. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: sorting two corresponding lists?
Quoting Esmail ebo...@hotmail.com: items = [apple, car, town, phone] values = [5, 2, 7, 1] I would like to sort the 'items' list based on the 'values' list so that I end up with the following two list: items = [town, apple, car, phone] values = [7, 5, 2, 1] I've used this sometimes: === [untested] === sorted_pairs = sorted(zip(values,items)) values = [value for value, _ in sorted_pairs] items = [item for _, item in sorted_pairs] === You could also do something like this, if you don't mind the extra indirection: === [also untested] === indices = sorted(range(len(values)), key = lambda i: values[i]) # and then access the values as print first value, values[indices[0]] print first item, items[indices[0]] === Keep in mind that both cases keep the original lists unsorted. I guess you could use values[:] = instead of values = on the first option to simulate a sort_in_place. I usually prefer the first form. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: any(), all() and empty iterable
Quoting John O'Hagan resea...@johnohagan.com: An exception, or at least a specific mention of the case of empty iterables in the docs (as Tim Chase suggested), would have baffled me less than my program telling me that the same items were both ubiquitous and entirely absent from a list of sets! Well, they _were_ both ubiquitous and entirely absent from your list of sets: both propositions are true. Vacuous truth doesn't mean that the answer is incorrect, just that it is meaningless. The problem was not in the answer, but in the question you asked. Of course, it's possible people out there depend on the present behaviour. It's more than that. Python's following the rules here. Maybe it could be documented better, for those without a background in logic/discrete mathematics, but not changed. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: Imports in python are static, any solution?
Quoting Ravi ra.ravi@gmail.com: This is problematic. Well I want i to change with foo.fi() . You can't. i and foo.i are _different_ variables that just happen to share the same value initially. What you are observing is no different than i = 10 j = i i = 99 print i # prints 99 print j # print 10 May I ask, why is it problematic? You should be avoiding the use of global variables anyway. -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: any(), all() and empty iterable
Quoting John O'Hagan m...@johnohagan.com: Hi, I was getting some surprising false positives as a result of not expecting this: all(element in item for item in iterable) to return True when 'iterable' is empty. [...] any(element in item for item in iterable) which returns False when 'iterable' is empty. The any and all functions for python2.5 mirror the existential[1] and uiniversal[2] quantifiers from predicate logic. In layman terms, any returns true if there exists at least one element in the collection for which the predicate (element in item in your case) is true. If the collection is empty, there are no elements, and in particular, there can be no elements that satisfy your predicate (returns false). This function/quantifier is well defined on an empty set. all returns true if for every element in the collection, the predicate holds. If you have an empty set, there is no way that the predicate could evaluate to false, thus, it return true. While this may seem arbitrary at first, keep in mind that one expects the phrase all this values in this set are true to mean the same as there are no false values in this set, i.e, all(x for x in list) == not any(not x for x in list). So, the universal quantifier/python's all function may be easier to understand as: returns true if there is no element in the set that for which the predicate is false. These would be any and all implementations in pure python: def any(elements): for element in elements: if element: return True return False def all(elements): for element in elements: if not element: return False return True You may also want to look at [3] K. P.S: Forgive my english. I'm falling asleep... I hope I made sense. [1] http://en.wikipedia.org/wiki/Existential_quantification [2] http://en.wikipedia.org/wiki/Universal_quantification [3] http://en.wikipedia.org/wiki/Vacuous_truth -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: nested looping
Quoting PK superp...@gmail.com: So I'm trying to see whats the cleanest way to do this: I have a checklist = [ax, bx, by, cy ..] (a combination of a,b,c with x and y, either both on one) allist = [a,b,c,] xlist = [x, y, ..] [...] now the problem is I want to include alpha in missing list only if none of the combinations from xlist with alpha are in checklist. This is untested: for alpha in alist: for xy in xlist: if alpha+xy in checklist: break else: missing.append(alpha) (note that the else is for the for, not the if) You could also try the any/all functions from python2.5: for alpha in alist: if not any(alpha + xy in checklist for xy in xlist): missing.append(alpha) Or the really not recommended one-liner: missing = [alpha for alpha in alist if not any(alpha + xy in checklist for xy in xlist)] (remember, all of this is untested) -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: python needs leaning stuff from other language
Quoting online.serv...@ymail.com: python's list needs a thing list.clear() like c# arraylist It has: l[:] = [] python needs a writeline() method Now, that could be useful, a writeline method that knew the EOL convention for the OS and were not as deceiving as the current .writelines(). BTW, check out the print statement from python2, and the print function in python3: print fileobj, this will print with an eol # python2 print(this will print with an eol, file=fileobj) -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
Re: python needs leaning stuff from other language
Quoting Esmail ebo...@hotmail.com: Diez B. Roggisch wrote: some_list[:] = [] I agree that this is nice and clear, Not very intuitive, though, until you learn the syntax. (but, slice accessing and slice assignment are among the first few things one learns about python anyway, and once you learn it, it seems more than natural) but as a relative newbie wouldn't some_list = [] be also acceptable (and pythonic?)? Pythonic, yes. Acceptable, it may not be (depending on the problem). And I would adventure that if someone needs to clear a list instead of creating an empty one, its likely that someone is facing one of those problems (i.e: clearing a list that you got as a function argument, or playing with os.walk). -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- Participe en Universidad 2010, del 8 al 12 de febrero de 2010 La Habana, Cuba http://www.universidad2010.cu -- http://mail.python.org/mailman/listinfo/python-list
distutils, No module named numpy.distutils.fcompiler.conv_template
I'm trying to compile the wrappers for ANN (Approximate Nearest Neighbor) from
http://scipy.org/scipy/scikits/wiki/AnnWrapper, either the main one (scikits) or
the attachment in the main page.
However, the command python setup.py build produces the exception:
ImportError: No module named numpy.distutils.fcompiler.conv_template
There is no conv_template in numpy.distutils.fcompiler, but there is one at
numpy.distutils. Grepping for conv_template at /usr/lib/python2.5/distutils/
produces no results, and grepping for it at
/usr/lib/python2.5/site-packages/numpy/ returns only
==
/[...]/numpy/distutils/command/build_src.py:from numpy.distutils.conv_template
import process_file as process_c_file
/[...]/numpy/distutils/command/build_src.py:
log.info(conv_template: %s % (target_file))
==
i.e, it is being imported from distutils and not from fcompiler.
What's going on here? It is an ubuntu bug? (intrepid) Am I missing some
packages? This happens regardless of if the ANN library exists or not.
If I try to softlink the distutils/conv_template.py module to the fcompiler
directory, I start getting the same symptoms with other modules:
numpy_distribution, extension, interactive.
K.
P.S: Traceback follows.
ky...@home:~/downloads/ann$ python setup.py build
running build
running scons
customize UnixCCompiler
Found executable /usr/bin/gcc
Traceback (most recent call last):
File setup.py, line 41, in module
classifiers = filter(None, classifiers.split(\n)),
File /usr/lib/python2.5/site-packages/numpy/distutils/core.py, line 184, in
setup
return old_setup(**new_attr)
File /usr/lib/python2.5/distutils/core.py, line 151, in setup
dist.run_commands()
File /usr/lib/python2.5/distutils/dist.py, line 974, in run_commands
self.run_command(cmd)
File /usr/lib/python2.5/distutils/dist.py, line 994, in run_command
cmd_obj.run()
File /usr/lib/python2.5/site-packages/numpy/distutils/command/build.py, line
38, in run
self.run_command('scons')
File /usr/lib/python2.5/distutils/cmd.py, line 333, in run_command
self.distribution.run_command(command)
File /usr/lib/python2.5/distutils/dist.py, line 993, in run_command
cmd_obj.ensure_finalized()
File /usr/lib/python2.5/distutils/cmd.py, line 117, in ensure_finalized
self.finalize_options()
File /usr/lib/python2.5/site-packages/numpy/distutils/command/scons.py, line
310, in finalize_options
force = self.force)
File /usr/lib/python2.5/site-packages/numpy/distutils/fcompiler/__init__.py,
line 804, in new_fcompiler
load_all_fcompiler_classes()
File /usr/lib/python2.5/site-packages/numpy/distutils/fcompiler/__init__.py,
line 715, in load_all_fcompiler_classes
__import__ (module_name)
File /usr/lib/python2.5/ihooks.py, line 405, in import_module
m = self.load_tail(q, tail)
File /usr/lib/python2.5/ihooks.py, line 458, in load_tail
raise ImportError, No module named + mname
ImportError: No module named numpy.distutils.fcompiler.conv_template
--
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie
--
Participe en Universidad 2010, del 8 al 12 de febrero de 2010
La Habana, Cuba
http://www.universidad2010.cu
--
http://mail.python.org/mailman/listinfo/python-list
