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?
[email protected] 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: > [email protected] 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, [email protected] 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, [email protected] 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: > > > [email protected] 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
