Re: Why has __new__ been implemented as a static method?
Steven D'Aprano wrote: If it were a class method, you would call it by MyBaseClass.__new__() rather than explicitly providing the cls argument. But that wouldn't be any good, because the base __new__ needs to receive the actual class being instantiated, not the class that the __new__ method belongs to. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Bug in Decimal??
On Tue, 29 Apr 2014 19:37:17 -0700, pleasedontspam wrote: > Hello, I believe I found a bug in the Decimal library. The natural logarithm > results seem to be off in a certain range, as compared with Wolfram Alpha. I had a quick look: this isn't a bug - it's just the result of propagation of the error in "partial" to "final". In more detail: we've got a working precision of 2016 significant figures. For any small x, we have (1 + x) / (1 - x) = 1 + 2x + 2x^2 + 2x^3 + For your value of x, `Decimal('1e-1007'), we've got enough precision to store 1 + 2x + 2x^2 exactly, but that's all. So partial has an absolute error of around 2x^3, or 2e-3021. And since the derivative of the natural log function is almost exactly 1 at the point we're interested in, we expect the absolute error in the output to be close to 2e-3021, too. And that's *precisely* what you're seeing: the Decimal module is giving you a result that's exactly `Decimal('2e-1007') - Decimal('1.3e-3021')`, while the result you were expecting is `Decimal('2e-1007') + Decimal('0.7e-3021')`. A difference of exactly `Decimal('2e-3021')`, as expected. -- Mark -- https://mail.python.org/mailman/listinfo/python-list
Re: tkinter: invisible PanedWindow "sashes" on OS X
Hi to all, I have a similar problem. I have a PanedWindow with a lot of checkboxes in it and i want to make the checkboxes non-resizable.How can i achieve this? -- https://mail.python.org/mailman/listinfo/python-list
Re:Python Image Registration and Cropping?
mikejohnrya...@gmail.com Wrote in message: > Hello, > > Is there a Python tool or function that can register two images together > (line them up visually), and then crop them to the common overlap area? I'm > assuming this can probably be done with Python Imaging Library but I'm not > very familiar with it yet. > > Any help or advice is appreciated! > > Thanks! > Without some context I'd call the problem intractable. I've done such things using Photoshop to insert elements of one image into another. But even describing an algorithm is difficult, never mind trying to code it. If I had such a challenge, I'd probably use Pillow, but not till I knew what subset I was solving. 1) you had an image, saved in lossless tiff, and it was copied twice, each was edited and cropped, and the original lost. Analyze the two remaining tiff, and try to reconstruct the largest common subset. 2) You have two faxes from filled in versions of the same original form, and you're trying to extract just the handwriting portions of each. Very tricky, because not only exposure differences, but registration will vary over the surface, because of moisture and irregular feed from multiple rollers. 3) You have two jpegs, created from same master, but one has been scaled, rotated, cropped, and color corrected. Even without color correction, one was saved at a different quality setting, or prepared with a different raw converter. 4) You have two images taken with the same camera, on a tripod, within a minute of each other, with no visible difference of cloud cover, with camera set on full manual, without auto focus. The were converted with the same raw converter, ... etc. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why has __new__ been implemented as a static method?
On Sun, 04 May 2014 20:03:35 +1200, Gregory Ewing wrote: > Steven D'Aprano wrote: >> If it were a class method, you would call it by MyBaseClass.__new__() >> rather than explicitly providing the cls argument. > > But that wouldn't be any good, because the base __new__ needs to receive > the actual class being instantiated, not the class that the __new__ > method belongs to. Which is exactly what method descriptors -- whether instance methods or class descriptors -- can do. Here's an example, using Python 2.7: class MyDict(dict): @classmethod def fromkeys(cls, *args, **kwargs): print "Called from", cls return super(MyDict, cls).fromkeys(*args, **kwargs) class AnotherDict(MyDict): pass And in use: py> MyDict.fromkeys('abc') Called from {'a': None, 'c': None, 'b': None} py> AnotherDict().fromkeys('xyz') Called from {'y': None, 'x': None, 'z': None} In both cases, MyDict's __new__ method receives the class doing the calling, not the class where the method is defined. Whatever the difficulty is with __new__, it isn't something obvious. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Image Registration and Cropping?
On Sun, May 4, 2014 at 7:24 AM, Dave Angel wrote: > mikejohnrya...@gmail.com Wrote in message: >> Hello, >> >> Is there a Python tool or function that can register two images together >> (line them up visually), and then crop them to the common overlap area? I'm >> assuming this can probably be done with Python Imaging Library but I'm not >> very familiar with it yet. >> >> Any help or advice is appreciated! >> >> Thanks! >> > > Without some context I'd call the problem intractable. I've done > such things using Photoshop to insert elements of one image into > another. But even describing an algorithm is difficult, never > mind trying to code it. Well, fortunately there are known algorithms already: http://en.wikipedia.org/wiki/Image_registration > If I had such a challenge, I'd probably use Pillow, but not till > I knew what subset I was solving. I don't think Pillow has any support for registration. I'd probably start by looking for Python bindings of a library that does handle it, like ITK. Searching for "itk python" turns up a number of results. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why has __new__ been implemented as a static method?
On 04/05/2014 15:16, Steven D'Aprano wrote: On Sun, 04 May 2014 20:03:35 +1200, Gregory Ewing wrote: Steven D'Aprano wrote: If it were a class method, you would call it by MyBaseClass.__new__() rather than explicitly providing the cls argument. But that wouldn't be any good, because the base __new__ needs to receive the actual class being instantiated, not the class that the __new__ method belongs to. Which is exactly what method descriptors -- whether instance methods or class descriptors -- can do. Here's an example, using Python 2.7: class MyDict(dict): @classmethod def fromkeys(cls, *args, **kwargs): print "Called from", cls return super(MyDict, cls).fromkeys(*args, **kwargs) class AnotherDict(MyDict): pass And in use: py> MyDict.fromkeys('abc') Called from {'a': None, 'c': None, 'b': None} py> AnotherDict().fromkeys('xyz') Called from {'y': None, 'x': None, 'z': None} In both cases, MyDict's __new__ method receives the class doing the calling, not the class where the method is defined. Yes, when a classmethod bound to a subclass or an instance is called. But this is irrelevant to Gregory's point: On 04/05/2014 04:37, Steven D'Aprano wrote: On Sun, 04 May 2014 11:21:53 +1200, Gregory Ewing wrote: Steven D'Aprano wrote: I'm not entirely sure what he means by "upcalls", but I believe it means to call the method further up (that is, closer to the base) of the inheritance tree. I think it means this: def __new__(cls): MyBaseClass.__new__(cls) which wouldn't work with a class method, because MyBaseClass.__new__ would give a *bound* method rather than an unbound one. If it were a class method, you would call it by MyBaseClass.__new__() rather than explicitly providing the cls argument. The relevant behaviour is this: >>> class C: @classmethod def m(cls): print("Called from", cls) >>> class D(C): @classmethod def m(cls): C.m() >>> C.m() Called from >>> D.m() Called from If __new__ were a classmethod, then a call to MyBaseClass.__new__() within the body of MySubClass.__new__ would pass MyBaseClass to the underlying function, not the MySubClass. This means that class MySubClass(MyBaseClass): def __new__(cls): return MyBaseClass.__new__() would fail, since it would return an instance of MyBaseClass rather than MySubClass. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why has __new__ been implemented as a static method?
On Sun, May 4, 2014 at 8:16 AM, Steven D'Aprano wrote: > On Sun, 04 May 2014 20:03:35 +1200, Gregory Ewing wrote: > >> Steven D'Aprano wrote: >>> If it were a class method, you would call it by MyBaseClass.__new__() >>> rather than explicitly providing the cls argument. >> >> But that wouldn't be any good, because the base __new__ needs to receive >> the actual class being instantiated, not the class that the __new__ >> method belongs to. > > > Which is exactly what method descriptors -- whether instance methods or > class descriptors -- can do. Here's an example, using Python 2.7: > > class MyDict(dict): > @classmethod > def fromkeys(cls, *args, **kwargs): > print "Called from", cls > return super(MyDict, cls).fromkeys(*args, **kwargs) > > class AnotherDict(MyDict): > pass > > > And in use: > > py> MyDict.fromkeys('abc') > Called from > {'a': None, 'c': None, 'b': None} > py> AnotherDict().fromkeys('xyz') > Called from > {'y': None, 'x': None, 'z': None} > > > In both cases, MyDict's __new__ method receives the class doing the > calling, not the class where the method is defined. > > Whatever the difficulty is with __new__, it isn't something obvious. You cheated on two counts here. First, you're using super; I think Guido's comment about "upcalls" in the link you posted earlier was in reference to calls that explicitly name the name parent class, i.e. "dict.fromkeys()", not "super(MyDict, cls).fromkeys()". Second, you didn't override the method in AnotherDict, so "MyDict.fromkeys" and "AnotherDict.fromkeys" refer to the same method, the only difference being in which class is passed to the descriptor when it is accessed. Compare to this: class MyDict(dict): @classmethod def fromkeys(cls, *args, **kwargs): print "MyDict Called from", cls return dict.fromkeys(*args, **kwargs) class AnotherDict(MyDict): @classmethod def fromkeys(cls, *args, **kwargs): print "AnotherDict Called from", cls return MyDict.fromkeys(*args, **kwargs) >>> MyDict.fromkeys('abc') MyDict Called from {'a': None, 'c': None, 'b': None} >>> AnotherDict.fromkeys('abc') AnotherDict Called from MyDict Called from {'a': None, 'c': None, 'b': None} -- https://mail.python.org/mailman/listinfo/python-list
Re: Glade on Windows using Python
On Tuesday, April 22, 2014 7:08:29 PM UTC-4, mbg...@planetmail.com wrote: > Using Windows 8.1 Update. > > I've loaded ActiveState python (version 2.7) --- installed OK. > > I don't need Glade, but I do want to use some Glade XML and run the python > application. > > To run a Glade application this needs: > > > > from gi.repository import Gtk > > > > gi.repository is not available to import. > > > > Where can I find gi.repository?all searches to date have come up empty! > > > > Mary So...it turns out that Glade support for Python 2.7 is pretty difficult. I ended up rewriting the whole thing using Tkinter and ttk.Treeview. It would have been good to reuse the Glade XML...less code, better looking, etc. etc. Ah well. Mary -- https://mail.python.org/mailman/listinfo/python-list
Re: Glade on Windows using Python
On 05/04/2014 01:51 PM, mbg1...@planetmail.com wrote: > So...it turns out that Glade support for Python 2.7 is pretty difficult. > I ended up rewriting the whole thing using Tkinter and ttk.Treeview. > It would have been good to reuse the Glade XML...less code, better looking, > etc. etc. Both Gtk2 and Gtk3 are available for Windows. Glade XML is typically used on Gtk2 by the GtkBuilder class (http://www.pygtk.org/pygtk2reference/class-gtkbuilder.html). Gtk3 uses http://python-gtk-3-tutorial.readthedocs.org/en/latest/builder.html. The code you had in your OP was for Gtk3. There are up-to-date packages of Gtk3 bindings for Python on Windows here: http://sourceforge.net/projects/pygobjectwin32/files/ I didn't see your original post a couple of weeks ago, which is too bad. I'm not sure Gtk is better-looking on Windows. It's always been the ugly step-child there compared to Linux. Tkinter has a Windows native look and feel, so there's no reason to not use Tkinter if it suits your project: https://docs.python.org/3/library/tkinter.ttk.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Image Registration and Cropping?
On Sunday, May 4, 2014 11:51:00 AM UTC-4, Ian wrote: > On Sun, May 4, 2014 at 7:24 AM, Dave Angel wrote: > > > mikejohnrya...@gmail.com Wrote in message: > > >> Hello, > > >> > > >> Is there a Python tool or function that can register two images together > >> (line them up visually), and then crop them to the common overlap area? > >> I'm assuming this can probably be done with Python Imaging Library but I'm > >> not very familiar with it yet. > > >> > > >> Any help or advice is appreciated! > > >> > > >> Thanks! > > >> > > > > > > Without some context I'd call the problem intractable. I've done > > > such things using Photoshop to insert elements of one image into > > > another. But even describing an algorithm is difficult, never > > > mind trying to code it. > > > > Well, fortunately there are known algorithms already: > > http://en.wikipedia.org/wiki/Image_registration > > > > > If I had such a challenge, I'd probably use Pillow, but not till > > > I knew what subset I was solving. > > > > I don't think Pillow has any support for registration. I'd probably > > start by looking for Python bindings of a library that does handle it, > > like ITK. Searching for "itk python" turns up a number of results. Thanks for the responses. More specifically, my scenario is that I have many aerial image stereo-pairs, and need to register each pair together and crop them to their overlapping area. The output should produce two images with the same field-of-view; and the only difference will be the perspective. Still searching for a suitable module that can easily do this sort of thing. -- https://mail.python.org/mailman/listinfo/python-list