Interpolating/crossfading a stack of matrices
Hi, I want to interpolate (with quadratic splines) a stack of 2D-arrays/matrices y1, y2, y3, ... in a third dimension (which I call x) e.g. for crossfading images. I already have a working code which unfortunately still contains two explicit loops over the rows and colums of the matrices. Inside these loops I simply use 'interp1d' from scipy suitable for 1D-interpolations. Is anybody here aware of a better, more efficient solution of my problem? Maybe somewhere out there a compiled routine for my problem already exists in a python library... :-) My code: -- from scipy.interpolate import interp1d from numpy import array, empty_like, dstack x = [0.0, 0.25, 0.5, 0.75, 1.0] y1 = array([[1, 10, 100, 1000], [1, 10, 100, 1000]], float) y2 = array([[2, 20, 200, 2000], [2, 20, 200, 2000]], float) y3 = array([[3, 30, 300, 3000], [4, 40, 400, 4000]], float) y4 = array([[4, 40, 400, 4000], [8, 80, 800, 8000]], float) y5 = array([[5, 50, 500, 5000], [16, 160, 1600, 16000]], float) y = dstack((y1, y2, y3, y4, y5)) y_interpol = empty_like(y[:, :, 0]) i_range, j_range = y.shape[:2] for i in xrange(i_range): for j in xrange(j_range): # interpolated value for x = 0.2 y_interpol[i,j] = interp1d(x, y[i, j,:], kind='quadratic')(0.2) print y_interpol -====----- Cheers, Raphael -- http://mail.python.org/mailman/listinfo/python-list
Re: Interpolating/crossfading a stack of matrices
>> Hi, >> >> I want to interpolate (with quadratic splines) a stack of 2D-arrays/matrices >> y1, y2, y3, ... in a third dimension (which I call x) e.g. for crossfading >> images. I already have a working code which unfortunately still contains two >> explicit loops over the rows and colums of the matrices. Inside these loops >> I >> simply use 'interp1d' from scipy suitable for 1D-interpolations. Is anybody >> here aware of a better, more efficient solution of my problem? Maybe >> somewhere out there a compiled routine for my problem already exists in a >> python library... :-) > Since numpy arrays make it so easy to form linear combinations of > arrays without loops I would probably eliminate the loops and just > form the appropriate combinations of the image arrays. For example, to > use linear interpolation you could do: > > > > def interp_frames_linear(times, frames, t): > > '''times is a vector of floats > > frames is a 3D array whose nth page is the image for time t[n] > > t is the time to interpolate for > > ''' > > # Find the two frames to interpolate between > > # Probably a better way of doing this > > for n in range(len(t)-1): > > if times[n] <= t < times[n+1]: > > break > > else: > > raise OutOfBoundsError > > > > # Interpolate between the two images > > alpha = (t - times[n]) / (times[n+1] - times[n]) > > return (1 - alpha) * frames[:, :, n] + alpha * frames[:, :, n+1] > > > > I'm not really sure how quadratic interpolation is supposed to work > (I've only ever used linear and cubic) but you should be able to do > the same sort of thing. > > Oscar Indeed, the 'manual' reimplementation of the interpolation formula using numpy arrays significantly sped up the code. The numexpr package made it even faster. Thanks a lot for your advice! Raphael -- http://mail.python.org/mailman/listinfo/python-list
Re: splitting a long string into a list
What exactly seems to be the problem? "ronrsr" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I have a single long string - I'd like to split it into a list of > unique keywords. Sadly, the database wasn't designed to do this, so I > must do this in Python - I'm having some trouble using the .split() > function, it doesn't seem to do what I want it to - any ideas? > > thanks very much for your help. > > r-sr- -- http://mail.python.org/mailman/listinfo/python-list
Suggestion: Regex string specifier like r and f
Maybe something like re"" It should behave exactly like a raw string but would be useful for syntax highlighting and debugging. Perhaps also for type hinting expected regex input (don't know if this is feasible). -- https://mail.python.org/mailman/listinfo/python-list
Using distutils 2.4 for python 2.3
Hello, I want to distribute a package. It's compatible with Python 2.3. Is there a way to use distutils 2.4 feature package_data, while maintaining the distribution compatible with python 2.3 ? Thanks, Noam Raphael -- http://mail.python.org/mailman/listinfo/python-list
Re: Using distutils 2.4 for python 2.3
Fredrik Lundh wrote: > > you can enable new metadata fields in older versions by assigning to > the DistributionMetadata structure: > > try: > from distutils.dist import DistributionMetadata > DistributionMetadata.package_data = None > except: > pass > > setup( > ... > package_data=... > ) > > I tried this, but it made python2.4 behave like python2.3, and not install the package_data files. Did I do something wrong? -- http://mail.python.org/mailman/listinfo/python-list
How about "pure virtual methods"?
Hello, I thought about a new Python feature. Please tell me what you think about it. Say you want to write a base class with some unimplemented methods, that subclasses must implement (or maybe even just declare an interface, with no methods implemented). Right now, you don't really have a way to do it. You can leave the methods with a "pass", or raise a NotImplementedError, but even in the best solution that I know of, there's now way to check if a subclass has implemented all the required methods without running it and testing if it works. Another problem with the existing solutions is that raising NotImplementedError usually means "This method might be implemented some time", and not "you must implement this method when you subclass me". What I suggest is a new class, called notimplemented (you may suggest a better name). It would get a function in its constructor, and would just save a reference to it. The trick is that when a new type (a subclass of the default type object) is created, It will go over all its members and check to see if any of them is a notimplemented instance. If that is the case, it would not allow an instantiation of itself. What I want is that if I have this module: == class BaseClass(object): def __init__(self): ... @notimplemented def save_data(self, filename): """This method should save the internal state of the class to a file named filename. """ pass class RealClass(BaseClass): def save_data(self, filename): open(filename).write(self.data) == then if I try to instantiate BaseClass I would get an exception, but instantiating RealClass will be ok. Well, what do you say? Noam Raphael -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Thank you all, especially Alex for your enlightening discussion, and Scott for your implementation. I'm sorry that I can't be involved in a daily manner - but I did read all of the posts in this thread. They helped me understand the situation better, and convinced me that indeed this feature is needed. Let's see if I can convince you too. First, the actual situation in which I stood, which made me think, "I would like to declare a method as not implemented, so that subclasses would have to implement it." I wrote a system in which objects had to interact between themselves. In my design, all those objects had to implement a few methods for the interaction to work. So I wrote a base class for all those objects, with a few methods which the subclasses had to implement. I think it's good, for *me*, to have an explicit list of what should be implemented, so that when (in a function) I expect to get an object of this kind I know what I may and may not do with it. Then, I wrote the classes themselves. And I wrote unit tests for them. (Ok, I lie. I didn't. But I should have!) Afterwards, I decided that I needed all my objects of that kind to supply another method. So I added another "raise NotImplementedError" method to the base class. But what about the unit tests? They would have still reported a success - where of course they shouldn't have; my classes, in this stage, didn't do what they were expected to do. This problem might arise even when not changing the interface at all - it's quite easy to write a class which, by mistake, doesn't implement all the interface. Its successful unit tests may check every single line of code of that class, but a complete method was simply forgotten, and you wouldn't notice it until you try the class in the larger framework (and, as I understand, the point of unit testing is to test the class on its own, before integrating it). Ok. This was the practical reason why this is needed. Please note that I didn't use "isinstance" even once - all my functions used the *interface* of the objects they got. I needed the extra checking for myself - if someone wanted to implement a class that wouldn't inherit from my base class, but would nevertheless implement the required interface, he was free to do it, and it would have worked fine with the framework I wrote. Now for the "theoretical" reason why this is needed. My reasoning is based on the existence of "isinstance" in Python. Well, what is the purpose of isinstance? I claim that it doesn't test if an object *is* of a given type. If that would have been its purpose, it would have checked whether type(obj) == something. Rather, it checks whether an object is a subclass of a given type. Why should we want such a function? A subclass may do a completely different thing from what the original class did! The answer is that a subclass is guaranteed to have the same *interface* as the base class. And that's what matters. So I conclude that a subclass, in Python, must implement the interface of its parent class. Usually, this is obvious - there's no way for a subclass not to implement the interface of its parent class, simply because it can only override methods, but can't remove methods. But what shall we do if the some methods in the base class consist *only* of an interface? Can we implement only a part of the interface, and claim that instances of that class are instances of the original class, in the "isinstance" fashion? My answer is no. The whole point of "isinstance" is to check whether an instance implements an interface. If it doesn't - what is the meaning of the True that isinstance returns? So we should simply not allow instances of such classes. You might say that abstract classes at the base of the hierarchy are "not Pythonic". But they are in Python already - the class basestring is exactly that. It is an uninstantiable class, which is there only so that you would be able to do isinstance(x, basestring). Classes with "notimplemented" methods would behave in exactly the same way - you wouldn't be able to instantiate them, just to subclass them (and to check, using isinstance, whether they implement the required protocol, which I agree that wouldn't be Pythonic, probably). Ok. This is why I think this feature fits Python like a glove to a hand. Please post your comments on this! I apologize now - I may not be able to reply in the next few days. But I will read them at the end, and I will try to answer. Have a good day, Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Steve Holden wrote: Even if you can do it, how would you then implement a class hierarchy where the ultimate base class had virtual methods, and you wanted to derive from that class another class, to be used as a base class for usable classes, which implemented only a subset of the virtual methods, leaving the others to be implemented by the ultimate subclasses? What I suggest is that only *instantiation* would be forbidden. You are free to make a subclass which defines only some of the abstract methods, and to subclass the subclass and define the rest. You would only be able to make instances of the subclass of the subclass, but that's ok. See Scott's implementation - the test at the end does exactly this. I hope this helped, Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
My long post gives all the philosophy, but I'll give here the short answers. Mike Meyer wrote: +0 Python doesn't use classes for typing. As Alex Martelli puts it, Python uses protocols. So the client expecting a concrete subclass of your abstract class may get an instantiation of a class that doesn't inherit from the abstract class at all. That's right - this mechanism is useful mostly for he who implements that class, to make sure that he implemented all that is needed to be assigned the title "a subclass of that class". Or maybe the subclass is only going to use a subset of the features of the abstract class, and the author knows that sum deferred methods won't be invoked. The correct behavior in this case would be to allow the subclass to be instantiated, and then get a runtime error if one of the features the author thought he could skip was actually called. I disagree - my reasoning is that a subclass must implement the complete interface of its base class (see my long post). The author may implement a class which defines only a part of the interface, and give it to the function, and it may work and be great. But it must not be called "an instance of the abstract class". Finally, in a sufficiently complex class hierarchy, this still leaves you wondering through the hierarchy trying to find the appropriate parent class that tagged this method as unimplemented, and then figuring out which class should have implemented it - as possibly a parent of the class whose instantiation failed is the subclass that should have made this method concrete. You are right - but I needed this for a class hierarchy of only two levels (the base abstract class and the concrete subclasses), so there were not many classes to blame for a missing method. I hope this seems reasonable, Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Jeff Shannon wrote: Except that unit tests should be written to the *specification*, not the implementation. In other words, forgetting a complete method would require that you forget to write the method, *and* that you failed to translate the specification into unit tests *for that same method*. You are absolutely right - but when you are not that tidy, and don't have a written specification apart from the code, it would be natural to go over each method in the class definition, and write a test to check if it does what it should. I'm not saying that it's the ideal way, but it is not that bad, usually. In the context of changing an existing interface, a unit-testing scenario would mean that, instead of installing a "pure virtual" method on a base class, you'd change the unit-tests to follow the new specification, and then write code that would pass the unit tests. If you are subclassing from a common base, then you'd only need to change the unit test for that common base class (presuming that all derived classes would run those unit tests as well). The problem is that I couldn't write a general unit test, since the base class wasn't instantiable - there wasn't even any point in making it instantiable, since every subclass was constructed with different argument definition. They were just required to provide some methods (check whether they contain an object, for example) - I don't know how to write a unit test for such a base class, or what does it mean. (Well, it may mean: check whether all the required methods exist, but come on - that's exactly the idea of my suggestion. There's no point in having to write the list of required methods another time). Jeff Shannon Technician/Programmer Credit International Thanks for your comment. You're welcomed to reply if you don't agree. Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Scott David Daniels wrote: class Abstract(object): '''A class to stick anywhere in an inheritance chain''' __metaclass__ = MustImplement def notimplemented(method): '''A decorator for those who prefer the parameters declared.''' return NotImplemented I just wanted to say that I thought of notimplemented as a class, that would save a reference to the functions it got in the constructor. In that way pydoc and his friends would be able to find the arguments the method was expected to get, and its documentation string. But it's a great implementation. Noam Oh, and another thing - maybe "abstract" is a better name than "notimplemented"? notimplemented might suggest a method which doesn't have to be implemented - and raises NotImplementedError when it is called. What do you think? -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Jp Calderone wrote: This lets you avoid duplicate test code as well as easily test new concrete implementations. It's an ideal approach for frameworks which mandate application-level implementations of a particular interface and want to ease the application developer's task. Jp It's a great way for sharing tests between different subclasses of a class. Thank you for teaching me. However, I'm not sure if this solves my practical problem - testing whether all abstract methods were implemented. I think that usually, you can't write a test which checks whether an abstract method did what it should have, since different implementations do different things. I don't even know how you can test whether an abstract method was implemented - should you run it and see if it raises a NotImplementedError? But with what arguments? And even if you find a way to test whether a method was implemented, I still think that the duplication of code isn't very nice - you have both in your class definition and in your test suite a section which says only "method so-and-so should be implemented." I think that making abstract methods a different object really makes sense - they are just something else. Functions (and methods) define what the computer should do. Abstract methods define what the *programmer* should do. Again, thanks for enlightening me. Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Mike Meyer wrote: Noam Raphael <[EMAIL PROTECTED]> writes: The answer is that a subclass is guaranteed to have the same *interface* as the base class. And that's what matters. This is false. For instance: class A(object): def method(self, a): print a class B(A): def method(self, a, b): print a, b B implements a different interface than A. Statically typed OO languages either use multi-methods or disallow changing the signature of an overridden method. A tool to detect such cases would probably be almost as useful as the tool you've proposed. I agree that such a tool would be very useful. In fact, I think it exists - I'm sure pychecker checks for mistakes like that. I understand that it checks for not implementing functions which just raise an exception too, so you can say, "why all this mess? Run pychecker and everything will be good." However, I think that there is a difference between these two tests, which explains why one should be done by the language itself and one should be done by an analysis tool. The difference is that handling arguments, in Python, can be seen as a part of the *implementation*, not the interface. The reason is that you can write a method which simply gets a (*args, **kwargs), and raises a TypeError if the number of args isn't two, and it would be completely equivalent to a function which is defined using def f(a, b). Of course, even in statically typed languages, you can't enforce an implementation to do what it should (too bad - it would have made debugging so much easier...) So checking whether the argument list of a method of a subclass suits the argument list of the original implementation is nice, but should be left to external analysis tools, but checking whether a method is defined at all can be done easily by the language itself. Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Mike Meyer wrote: That's what DbC languages are for. You write the contracts first, then the code to fullfill them. And get exceptions when the implementation doesn't do what the contract claims it does. Can you give me a name of one of them? This is a very interesting thing - I should learn one of those sometime. However, I'm pretty sure that programming in them is hell, or at least, takes a very long time. Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Thank you very much for this answer! I learned from you about unit tests, and you convinced me that "testing oriented programming" is a great way to program. You made me understand that indeed, proper unit testing solves my practical problem - how to make sure that all the methods which should be implemented were implemented. However, I'm still convinced that this feature should be added to Python, for what may be called "aesthetic reasons" - I came to think that it fills a gap in Python's "logic", and is not really an additional, optional feature. And, of course, there are practical advantages to adding it. The reason why this feature is missing, is that Python supports building a class hierarchy. And, even in this dynamically-typed language, the fact that B is a subclass of A means that B is supposed to implement the interface of A. If you want to arrange in a class hierarchy a set of classes, which all implement the same interface but don't have a common concrete class, you reach the concept of an "abstract class", which can't be instantiated. And the basestring class is exactly that. The current Python doesn't really support this concept. You can write in the __new__ of such a class something like "if cls == MyAbstractClass: raise TypeError", but I consider this as a patch - for example, if you have a subclass of this class which is abstract too, you'll have to write this exception code again. Before introducing another problem, let me quote Alex: ... If you WANT the method in the ABC, for documentation purposes, well then, that's not duplication of code, it's documentation, which IS fine (just like it's quite OK to have some of the same info in a Tutorial document, in a Reference one, AND in a class's docstring!). If you don't want to have the duplication your unit tests become easier: you just getattr from the class (don't even have to bother instantiating it, ain't it great!), and check the result with inspect. That's actually right - listing a method which should be implemented by subclasses, in the class definition is mainly a matter of *documentation*. I like the idea that good documentation can be derived from my documented code automatically, and even if I provide an external documentation, the idea that the code should explain itself is a good one. The problem is, that the current convention is not a good documentation: def frambozzle(self): ''' must make the instance frambozzled ''' raise NotImplementedError The basic problem is that, if you take this basic structure, it already means another thing: This is a method, which takes no arguments and raises a NotImplementedError. This may mean, by convention, that this method must be implemented by subclasses, but it may also mean that this method *may* be implemented by subclasses. I claim that a declaration that a method must be implemented by subclass is simply not a method, and since Python's "logic" does lead to this kind of thing, it should supply this object (I think it should be the class "abstract"). Two of Python's principles are "explicit is better than implicit", and "there should be (only?) one obvious way to do it". Well, I think that this: @abstract def frambozzle(self): """Must make the instance frambozzled""" pass is better than the previous example, and from def frambozzle(self): raise NotImplementedError, "You must implemented this method, and it must make the instance frambozzled" and from def frambozzle(self): """Must make the instance frambozzled. PURE VIRTUAL """ pass and from maybe other possible conventions. Note also that making this explicit will help you write your tests, even if Python would allow instantiation of classes which contain abstract methods - you will be able to simple test "assert not isinstance(MyClass.frambozzle, abstract)". (I don't like the solution of not mentioning the method at all, which makes the test equally simple, because it doesn't document what the method should do in the class definition, and I do like in-code documentation.) To summarize, I think that this feature should be added to Python because currently, there's no proper way to write some code which fits the "Python way". As a bonus, it will help you find errors even when your unit tests are not sufficient. I plan to raise this issue in python-dev. If you have any additional comments, please post them here. (I will probably be able to reply only by the weekend.) Have a good day, Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: Non blocking read from stdin on windows.
You can always have a thread which continually reads stdin and stores it in a string, or better, in a cStringIO.StringIO object. Then in the main thread, you can check whether something new has arrived. This, of course will work on all platforms. I hope this helped a bit, Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Thanks for your suggestion, but it has several problems which the added class solves: * This is a very long code just to write "you must implement this method". Having a standard way to say that is better. * You can instantiate the base class, which doesn't make sense. * You must use testing to check whether a concrete class which you derived from the base class really implemented all the abstract methods. Testing is a good thing, but it seems to me that when the code specifies exactly what should happen, and it doesn't make sense for it not to happen, there's no point in having a separate test for it. About the possibility of implementing only a subset of the interface: You are perfectly welcomed to implement any part of the interface as you like. Function which use only what you've implemented should work fine with your classes. But you can't claim your classes to be instances of the base class - as I see it, subclasses, even in Python, guarantee to behave like their base classes. Have a good day, Noam -- http://mail.python.org/mailman/listinfo/python-list
Results of arpalert to json in python
Hello,
I'm trying to create a program who'll catch the mac address connections. For
this, I take the /var/log/arpalert.log and create a dict. with the results in
JSON. I'm a beginner in Python.
For now, I have the arpalert log to a file.txt. I take this file and create a
dictionary in an other file. I transform the result to JSON format. But the
problem is the "format" of my dictionary. In the Json format I have all the
informations of one connection in a key, and all the informations of another
connection in the value of the key.
But what I want is a key "mac" with the address in value, a key "ip" with the
address in value, etc...
This is my code for now :
from json import dumps, dump
from itertools import izip
def get_log(source, destination):
log = open(source, 'r')
fil_dest = open(destination, 'w')
txt = log.readline()
while txt:
fil_dest.write(txt)
txt = log.readline()
log.close()
fil_dest.close()
def to_json(source, destination):
fil_dest = open(destination, 'w')
with open(source, 'r') as lines:
txt = lines.readlines()
wanted_lines = txt[0:]
i = iter(wanted_lines)
dict_log = dict(izip(i, i))
dump(dict_log, fil_dest, sort_keys=True, indent=1)
lines.close()
fil_dest.close()
get_log('/var/log/arpalert.log', 'arpalert_strings.txt')
to_json('arpalert_strings.txt', 'json_conversion.txt')
and the result in JSON ("key": "value")
"Oct 8 14:45:52 arpalert: seq=2, mac=a2:e5:68:3c:16:f1, ip=192.168.1.19,
type=new, dev=p3p1, vendor=\"(null)\"\n": "Oct 8 14:45:52 arpalert: seq=3,
mac=04:e8:ca:a8:6f:b8, ip=192.168.1.19, type=new, dev=p3p1,
vendor=\"(null)\"\n",
"Oct 9 09:41:46 arpalert: Auto selected device: bluetooth0\n": "Oct 9
09:41:46 arpalert: [./capture.c 181] ioctl[19] : No such device\n",
Anybody can help me please ? I tried with regex but I'm lost and I losing my
mind !
--
https://mail.python.org/mailman/listinfo/python-list
matplotlib - removing text from a figure - a bug?
Does anyone know if the following error message is a matplotlib bug?
Is there an correct/alternative way to remove (or replace) text? Thank
you, Raphael
from matplotlib.figure import Figure
fig = Figure()
caption = fig.suptitle("test")
caption.remove()
Traceback (most recent call last):
File "", line 1, in
caption.remove()
File "C:\Programme\Python27\lib\site-packages\matplotlib\artist.py",
line 134, in remove
raise NotImplementedError('cannot remove artist')
NotImplementedError: cannot remove artist
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Mike Meyer wrote: > [EMAIL PROTECTED] writes: > >>try: >>return a == b >>except TypeError: >>return a is b > > > This isn't "easy". It's an ugly hack you have to use everytime you > want to iterate through a heterogenous set doing equality tests. I wouldn't define this as an "ugly hack". These are four simple line, which state clearly and precisely what you mean, and always work. I have seen ugly hacks in my life, and they don't look like this. > > You're replacing "false" with an "emphathetic false", that *all* > containers to change for the worse to deal with it. > I don't see how they change for the worse if they have exactly the same functionality and a few added lines of implementation. > >>Also, Mike said that you'll need an idlist object too - and I think >>he's right and that there's nothing wrong with it. > > > Except that we now need four versions of internal data structures, > instead of two: list, tuple, idlist, idtuple; set, idset, frozenset, > frozenidset, and so on. What's wrong with this is that it's ugly. Again, "ugly" is a personal definition. I may call this "explicitness". By the way, what's the "and so on" - I think that these are the only built-in containers. > > >>Note that while you >>can easily define the current == behaviour using the proposed >>behaviour, you can't define the proposed behaviour using the current >>behaviour. > > > Yes you can, and it's even easy. All you have to do is use custom > classes that raise an exception if they don't You can't create a general container with my proposed == behaviour. That's what I meant. > > >>Also note that using the current behaviour, you can't easily >>treat objects that do define a meaningful value comparison, by >>identity. > > > Yes you can. Just use the "is" operator. Sorry, I wasn't clear enough. In "treating" I meant how containers treat the objects they contain. For example, you can't easily map a value to a specific instance of a list - dict only lets you map a value to a specific *value* of a list. Another example - you can't search for a specific list object in another list. > > Note that this behavior also has the *highly* pecular behavior that a > doesn't necessarily equal a by default. Again, "peculiar" is your aesthethic sense. I would like to hear objections based on use cases that are objectively made more difficult. Anyway, I don't see why someone should even try checking if "a==a", and if someone does, the exception can say "this type doesn't support value comparison. Use the "is" operator". > > I will point out why your example usages aren't really usefull if > you'll repeat your post with newlines. > Here they are: * Things like "Decimal(3.0) == 3.0" will make more sense (raise an exception which explains that decimals should not be compared to floats, instead of returning False). * You won't be able to use objects as keys, expecting them to be compared by value, and causing a bug when they don't. I recently wrote a sort-of OCR program, which contains a mapping from a numarray array of bits to a character (the array is the pixel-image of the char). Everything seemed to work, but the program didn't recognize any characters. I discovered that the reason was that arrays are hashed according to their identity, which is a thing I had to guess. If default == operator were not defined, I would simply get a TypeError immediately. * It is more forward compatible - when it is discovered that two types can sensibly be compared, the comparison can be defined, without changing an existing behaviour which doesn't raise an exception. The third example applies to the Decimal==float use case, and for every type that currently has the default identity-based comparison and that may benefit from a value-based comparison. Take the class class Circle(object): def __init__(self, center, radius): self.center = center self.radius = radius Currently, it's equal only to itself. You may decide to define an equality operator which checks whether both the center and the radius are the same, but since you already have a default equality operator, that change would break backwards-compatibility. Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Mike Meyer wrote:
> Noam Raphael <[EMAIL PROTECTED]> writes:
>
>>>>Also note that using the current behaviour, you can't easily
>>>>treat objects that do define a meaningful value comparison, by
>>>>identity.
>>>
>>>Yes you can. Just use the "is" operator.
>>
>>Sorry, I wasn't clear enough. In "treating" I meant how containers
>>treat the objects they contain. For example, you can't easily map a
>>value to a specific instance of a list - dict only lets you map a
>>value to a specific *value* of a list.
>
>
> Wrong. All you have to do is create a list type that uses identity
> instead of value for equality testing. This is easier than mapping an
> exception to false.
>
You're suggesting a workaround, which requires me to subclass everything
that I want to lookup by identity (and don't think it's simple - I will
have to wrap a lot of methods that return a list to return a list with a
modified == operator).
I'm suggesting the use of another container class: iddict instead of
dict. That's all.
I don't think that mapping an exception to false is so hard (certainly
simpler than subclassing a list in that way), and the average user won't
have to do it, anyway - it's the list implementation that will do it.
>
>>Another example - you can't
>>search for a specific list object in another list.
>
>
> Your proposed == behavior doesn't change that at all.
It does - *use idlist*.
>
>
>>>I will point out why your example usages aren't really usefull if
>>>you'll repeat your post with newlines.
>>
>>Here they are:
>>* Things like "Decimal(3.0) == 3.0" will make more sense (raise an
>>exception which explains that decimals should not be compared to
>>floats, instead of returning False).
>
>
> While I agree that Decimal(3.0) == 3.0 returning false doesn't make
> sense, having it raise an exception doesn't make any more sense. This
> should be fixed, but changing == doesn't fix it.
>
No, it can't be fixed your way. It was decided on purpose that Decimal
shouldn't be comparable to float, to prevent precision errors. I'm
saying that raising an exception will make it clearer.
>
>>* You won't be able to use objects as keys, expecting them to be
>>compared by value, and causing a bug when they don't. I recently wrote
>>a sort-of OCR program, which contains a mapping from a numarray array
>>of bits to a character (the array is the pixel-image of the char).
>>Everything seemed to work, but the program didn't recognize any
>>characters. I discovered that the reason was that arrays are hashed
>>according to their identity, which is a thing I had to guess. If
>>default == operator were not defined, I would simply get a TypeError
>>immediately.
>
>
> This isn't a use case. You don't get correct code with either version
> of '=='. While there is some merit to doing things that make errors
> easier to find, Python in general rejects the idea of adding
> boilerplate to do so. Your proposal would generate lots of boilerplate
> for many practical situations.
>
I would say that there's a lot of merit to doing things that make errors
easier to find. That's what exceptions are for.
Please say what those practical situations are - that what I want.
(I understand. You think that added containers and a try...except fro
time to time aren't worth it. I think they are. Do you have any other
practical situations?)
>
>>* It is more forward compatible - when it is discovered that two types
>>can sensibly be compared, the comparison can be defined, without
>>changing an existing behaviour which doesn't raise an exception.
>
>
> Sorry, but that doesn't fly. If you have code that relies on the
> exception being raised when two types are compared, changing it to
> suddenly return a boolean will break that code.
>
You are right, but that's the case for every added language feature (if
you add a method, you break code that relies on an AttributeError...)
You are right that I'm suggesting a try...except when testing if a list
contains an object, but a case when you have a list with floats and
Decimals, and you rely on "Decimal("3.0") in list1" to find only
Decimals seems to me a little bit far-fetched. If you have another
example, please say it.
Noam
--
http://mail.python.org/mailman/listinfo/python-list
Understanding Unicode & encodings
Hello,
For my application, I would like to execute an SQL query like this:
self.dbCursor.execute("INSERT INTO track (name, nbr, idartist, idalbum,
path) VALUES ('%s', %s, %s, %s, '%s')" % (track, nbr, idartist,
idalbum, path))
where the different variables are returned by the libtagedit python
bindings as Unicode. Every time I execute this, I get an exception like
this:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xa1 in position
64: ordinal not in range(128)
I tried to encode the different variables in many different encodings
(latin1), but I always get an exception. Where does this ascii codec
error comes from? How can I simply build this query string?
Thanks in advance.
Best Regards,
Raphael
--
http://mail.python.org/mailman/listinfo/python-list
Problem comparing object graphs and trees
Dear all, I am trying to compare graphes of object through the use of the __cmp__ operator. Before managing the problem of recursive comparison, I have tried a simple test which result surprises me. Here is the simplest code I can write that presents my problem: $ cat cmp.py class A: def __init__(self, b): self.b = b def __cmp__(self, other): return self.b == other.b class B: pass if __name__ == '__main__': b = B() a1 = A(b) a2 = A(b) print a1 == a2 print a1 == a1 $ python cmp.py False False I swear I am not drunk, but why isn't a1 == a2 and worse why isn't a1 == a1? Does someone have a clue and can explain to me this suprising behavior? (python 2.4.3 on Ubuntu 6.06). Cheers, r. -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem comparing object graphs and trees
I am not drunk but should have rtfm. Sorry and Thanks. r. On Dec 15, 3:04 pm, Peter Otten <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > > > $ cat cmp.py > > > class A: > > def __init__(self, b): > > self.b = b > > def __cmp__(self, other): > > return self.b == other.b > > > class B: > > pass > > > if __name__ == '__main__': > > b = B() > > a1 = A(b) > > a2 = A(b) > > print a1 == a2 > > print a1 == a1 > > > $ python cmp.py > > False > > False > > > > > I swear I am not drunk, but why isn't a1 == a2 and worse why isn't a1 > > == a1? Does someone have a clue and can explain to me this suprising > > behavior? (python 2.4.3 on Ubuntu 6.06).__cmp__() must return 0 for equal > > objects: > > >>> 1 .__cmp__(0), 1 .__cmp__(1), 1 .__cmp__(2)(1, 0, -1) > > You might have a look at rich comparison before you proceed: > > >>> class A(object):... def __init__(self, b): > ... self.b = b > ... def __eq__(self, other): > ... return self.b == other.b > ...>>> A(1) == A(1) > True > >>> A(1) == A(42)False > > Peter -- http://mail.python.org/mailman/listinfo/python-list
Running in Release or Debug version of the python interpreter?
Hi I have to check wheter a .py script is run within the debug or the release version of an embedded python interpreter (in short, wheter python24_d.dll or python24.dll is in use). long version: I'm using ctypes to load my own dll. There exists 2 version of this dll - a debug and a release version (where one is linked against debug C runtime dll and the other to release C runtime dll). Now I have to change the name of the dll I want to be loaded by ctypes... But how can I find out which of the dll I have to load?! Thanks in advance! Raphael Zulliger -- http://mail.python.org/mailman/listinfo/python-list
Re: Running in Release or Debug version of the python interpreter?
Thanks for your answers!
I prefer the proposal of Thomas Heller by using a small helper function
like this:
def IsDebugVersionRunning():
import imp
for suffix in imp.get_suffixes():
if suffix[0] == '_d.pyd':
return True
return False
This works well for me. The
_ctypes.__file__
trick didn't work for me - I guess I've done something wrong...
One more question: Under linux this doesn't seam to work - as there is
always returned '.so' (not '_d.so') at least in my tests. Are there no
debug/release version issues like on windows? doesn't import the
python2.4-dbg (debian) binary different modules than python2.4?
Raphael Zulliger
Thomas Heller wrote:
> Raphael Zulliger schrieb:
>
>> Hi
>>
>> I have to check wheter a .py script is run within the debug or the
>> release version of an embedded python interpreter (in short, wheter
>> python24_d.dll or python24.dll is in use).
>>
>> long version: I'm using ctypes to load my own dll. There exists 2
>> version of this dll - a debug and a release version (where one is
>> linked against debug C runtime dll and the other to release C runtime
>> dll). Now
>> I have to change the name of the dll I want to be loaded by ctypes...
>> But how can I find out which of the dll I have to load?!
>>
>> Thanks in advance!
>> Raphael Zulliger
>
>
> You could use imp.get_suffixes(). In a release build the returned list
> will contain these entries
> ('.pyd', 'rb', 3), ('.dll', 'rb', 3)
> in a debug build that will be
> ('_d.pyd', 'rb', 3), ('_d.dll', 'rb', 3)
>
> Another way would be to look at the filename of any binary extension
> module. _ctypes.__file__, for example: '.\\_ctypes.pyd' vs.
> '\\_ctypes_d.pyd'.
>
> Thomas
--
http://mail.python.org/mailman/listinfo/python-list
Variable definition
Hello,
I'd like to define variables with some specific name that has a common
prefix.
Something like this:
varDic = {'red': 'a', 'green': 'b', 'blue': 'c'}
for key, value in varDic.iteritems():
'myPrefix' + key = value
I know this is illegal, but there must be a trick somewhere.
Thanks,
Raphael
--
http://mail.python.org/mailman/listinfo/python-list
Re: Variable definition
John Posner wrote:
On 2/26/2010 6:32 PM, Raphael Mayoraz wrote:
Hello,
I'd like to define variables with some specific name that has a common
prefix.
Something like this:
varDic = {'red': 'a', 'green': 'b', 'blue': 'c'}
for key, value in varDic.iteritems():
'myPrefix' + key = value
No trick, just swap a new key-value pair for each existing pair:
for key, value in varDic.iteritems():
varDic[myPrefix + key] = value
del varDict[key]
Just make sure that *myPrefix* isn't an empty string!
-John
Thanks for your answer.
However, your solution changes the key name in the dictionary.
That's not what I want I need to do. What I want is to define a new
variable which name is define as a string: 'myPrefx' + key. In the example
I give, I would get 3 variables:
myPrefixred = a
myPrefixgreen = b
myPrefixblue = c
Raphael
--
http://mail.python.org/mailman/listinfo/python-list
getopt question
Hello, I have some trouble to make getopt.getopt work and the way I want (and is described in the documentation). Attached is very small script to reproduce my problem. If running: > python testGetOpt.py -a junk1 -b junk2 everything is ok > python testGetOpt.py -c junk1 ok too: I get the 'Invalid option' error message now: > python testGetOpt.py -a junk1 -c junk2 I'm expecting this to also print the error message, as 'c' is not in the argument given in getopt.getopt, but it doesn't. What am I doing wrong ? Using python 2.6.4 on WindowXP. Thanks. Raphael -- http://mail.python.org/mailman/listinfo/python-list
getopt question
Ooops, forgot to attach the file in my first e-mail. Now, here it is. Hello, I have some trouble to make getopt.getopt work and the way I want (and is described in the documentation). Attached is very small script to reproduce my problem. If running: > python testGetOpt.py -a junk1 -b junk2 everything is ok > python testGetOpt.py -c junk1 ok too: I get the 'Invalid option' error message now: > python testGetOpt.py -a junk1 -c junk2 I'm expecting this to also print the error message, as 'c' is not in the argument given in getopt.getopt, but it doesn't. What am I doing wrong ? Using python 2.6.4 on WindowXP. Thanks. Raphael - #!/usr/bin/env python import sys import getopt try: opts, args = getopt.getopt(sys.argv[1:], 'ab') except getopt.error: print 'Invalid option' sys.exit(0) -- http://mail.python.org/mailman/listinfo/python-list
DreamPie - The Python shell you've always dreamed about!
I'm pleased to announce DreamPie 1.0 - a new graphical interactive Python shell! Some highlights: * Has whatever you would expect from a graphical Python shell - attribute completion, tooltips which show how to call functions, highlighting of matching parentheses, etc. * Fixes a lot of IDLE nuisances - in DreamPie interrupt always works, history recall and completion works as expected, etc. * Results are saved in the Result History. * Long output is automatically folded so you can focus on what's important. * Jython and IronPython support makes DreamPie a great tool for exploring Java and .NET classes. * You can copy any amount of code and immediately execute it, and you can also copy code you typed interactively into a new file, with the Copy Code Only command. No tabs are used! * Free software licensed under GPL version 3. Check it out at http://dreampie.sourceforge.net/ and tell me what you think! Have fun, Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: DreamPie - The Python shell you've always dreamed about!
Delete \Documents and Settings\\DreamPie and it should now
work.
Did you edit the colors using the configuration window or manually?
If you edited them using the configuration window, can you give
instructions on how to reproduce the bug?
Noam
On Feb 21, 3:06 pm, "Aage Andersen" wrote:
> I reinstalled and got this message:
>
> Traceback (most recent call last):
> File "dreampie.py", line 4, ()
> File "dreampielib\gui\__init__.pyc", line 972, main()
> File "dreampielib\gui\__init__.pyc", line 153,
> __init__(self=DreamPie(path..."window_main"),
> pyexec='C:\\Python26\\python.exe')
> File "dreampielib\gui\__init__.pyc", line 829,
> configure(self=DreamPie(path..."window_main"))
> File "dreampielib\gui\tags.pyc", line 224,
> apply_theme_text(textview=,
> textbuffer=, theme={('bracket-match', 'bg', 'color'):
> 'darkblue', ('bracket-match', 'bg', 'isset'): True, ('bracket-match', 'fg',
> 'color'): 'white', ('bracket-match', 'fg', 'isset'): False, ...})
> ValueError: unable to parse colour specification
>
> Aage
--
http://mail.python.org/mailman/listinfo/python-list
Re: DreamPie - The Python shell you've always dreamed about!
Thanks! I'm happy you like it! Thanks for the feedback too. Here are my replies. On Sun, Feb 21, 2010 at 7:13 PM, Chris Colbert wrote: > This is bloody fantastic! I must say, this fixes everything I hate about > Ipython and gives me the feature I wished it had (with a few minor > exceptions). > I confirm this working on Kubuntu 9.10 using the ppa listed on the sites > download page. Great. It's important to know. > I also confirm that it works interactively with PyQt4 and PyGtk (as to be > expected since these toolkits use the PyOS_inputhook for the mainloop). > However, it does not work interactively with wx (again, this is as expected > since wx doesn't use the PyOS_inputhook). In short, the gui toolkit support > is the same as in Ipython if you dont use any of the magic threading > switches, which are now deprecated anyway. Actually, currently DreamPie doesn't use PyOS_inputhook, but implements the GUI hooks by itself. So it should be possible to implement wx support if there's a way to handle events for a few milliseconds. I tried it a bit and didn't find how to do it - if you are interested in wx support and think you can help, please do. > Matplotlib does not work interactively for me. Is there a special switch > that needs to be used? or should a pick a non-wx backend? (i'm thinking the > latter is more likely) You should set "interactive:True" in your matplotlibrc file. The next DreamPie version will warn about this. > A couple of things I would like to see (and will help implement if I can > find the time): > 1) A shortcut to show the docstring of an object. Something like Ipython's > `?`. i.e. `object.foo?` translates to `help(object.foo)` I wrote this at http://wiki.python.org/moin/DreamPieFeatureRequests . I hope I will manage to implement this soon. > 2) How do I change the color of the blinking cursor at the bottom? I can't > see the damn thing! It should be in the color of the default text. If this is not the case, please file a bug! > 3) line numbers instead of the `>>>` prompt I know IPython does this, but I thought you needed it only if placing the cursor on top of the command doesn't do anything. Can you tell me why do you need this in the context of a graphical user interface? > 4) a plugin facility where we can define our own `magic` commands. I use > Ipython's %timeit ALL the time. Added it to the feature request page. > 5) Double-click to re-fold the output section as well. I don't think that's a good idea, because usually double-click selects the word, and I don't want to change that behavior for regular text. You can use ctrl-minus to fold the last output section! > Thanks for making this Thanks for the feedback! Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: DreamPie - The Python shell you've always dreamed about!
This is most probably a bug discovered in DreamPie 1.0 (See https://bugs.launchpad.net/dreampie/+bug/525652 ) Can you try to download DreamPie 1.0.1, and if it still happens, report a bug? Thanks! Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: DreamPie - The Python shell you've always dreamed about!
Can you try DreamPie 1.0.1 and say if it still happens? There's a bug report system at launchpad.net/dreampie. Thanks, Noam -- http://mail.python.org/mailman/listinfo/python-list
