Re: Python 2.6 Deprecation Warnings with __new__ — Can someone explain why?
On Oct 25, 9:04 pm, rh0dium steven.kl...@gmail.com wrote:
On Oct 22, 9:05 pm, Carl Banks pavlovevide...@gmail.com wrote:
This should suffice for you:
class Borg(object):
__shared_state = {}
def __init__(self, noSend=False,reportLevel=30,
reportMethods=BaseReport,
contacts=None):
self.__dict__ = self.__shared_state
self.noSend = noSend
self.reportLevel = reportLevel
self.reportMethods = reportMethods
self.contacts = contacts
This (as well as your class) will update the shared state for all Borg
objects whenever you instantiate a new Borg object. That might be
what you want, but be aware.
Now the real question I have on this is scalability. The real
advantage to using *args and **kwargs is that down the road (through
inheritance/polymorphism) I may not know what I'm being given (isn't
that the essence of duck-typing).
No, duck-typing means you don't necessarily know the types of
arguments you're getting. Not knowing the number, pattern, or usage
of the arguments you're getting is something else.
My long standing belief is that by
using *args and **kwargs I plan for future additions with minimal
changes to my code. So doesn't restricting this just defeat the
purpose?
If that's your intended purpose down the road, feel free to do it.
(Not sure why you would do that with a singleton, but that's your
business.)
Personally, I wouldn't recommend replacing regular arguments with
*args and **kwargs unless there was a specific reason to believe that
this class would be used in a heirarchy where it's expected to pass on
arguments it doesn't know about. If it just might someday be used
that way, I'd say it's a lot of unnecessary caution.
One place I do recommend using *args and **kwargs is with mixin
classes, because mixins usually are required to pass along unknown
arguments, not just might be someday.
The fact is, object.__new__ does nothing at all with the args and
kwargs arguments, it just ignores them. So, when calling
object.__new__, don't pass them to it.
So what is the point of using __new__?
It's mostly for types written in C, or for subclassing types written
in C. Advanced programmers can take advantage of it to do some
interesting things, but most of the time __init__ suffices.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6 Deprecation Warnings with __new__ — Can someone explain why?
Carl,
First off - Thanks your post was exactly the kind of informative
example driven learnings that help — Thanks!!
On Oct 22, 9:05 pm, Carl Banks pavlovevide...@gmail.com wrote:
Before we get into object semantics, I'm not sure why you'd need to
override __new__ for Borg pattern, unless they're working around some
edge cases or something.
For that matter you shouldn't need args and kwargs either, you know
what the arguments to your function are.
Good point — admitadly I blindly followed Alex M's advice. I am still
working my way through this. Point taken.
This should suffice for you:
class Borg(object):
__shared_state = {}
def __init__(self, noSend=False,reportLevel=30,
reportMethods=BaseReport,
contacts=None):
self.__dict__ = self.__shared_state
self.noSend = noSend
self.reportLevel = reportLevel
self.reportMethods = reportMethods
self.contacts = contacts
This (as well as your class) will update the shared state for all Borg
objects whenever you instantiate a new Borg object. That might be
what you want, but be aware.
Now the real question I have on this is scalability. The real
advantage to using *args and **kwargs is that down the road (through
inheritance/polymorphism) I may not know what I'm being given (isn't
that the essence of duck-typing). My long standing belief is that by
using *args and **kwargs I plan for future additions with minimal
changes to my code. So doesn't restricting this just defeat the
purpose?
In my case the args that it dumps them into a black hold is simply not
true.
Actually it is.
I want an unknown set of args and kwargs to simply be forwarded
onto init. So what's the problem with this??
The problem is that __new__ doesn't forward the arguments to
__init__. Look at what happens when you call this class:
class X(object):
def __new__(cls,*args,**kwargs):
return object.__new__(cls)
def __init__(self,*args,**kwargs):
print args, kwargs
X(1,2,q=3,g=4)
Note that *args and **kwargs are not passed to object.__new__, but
nevertheless __init__ is still called with them.
What's actually happens is that the type object's __call__ method
passes the same arguments to both __new__ and __init__.
The fact is, object.__new__ does nothing at all with the args and
kwargs arguments, it just ignores them. So, when calling
object.__new__, don't pass them to it.
So what is the point of using __new__? After a bit of reading
http://docs.python.org/reference/datamodel.html 3.4.1 and I think I
understand. More to the point you made above. The whole necessity of
__new__ above makes most of this moot ;)
Once again thanks Carl for your great response!!
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6 Deprecation Warnings with __new__ Can someone explain why?
Terry Reedy tjre...@udel.edu writes on Fri, 23 Oct 2009 03:04:41 -0400: Consider this: def blackhole(*args, **kwds): pass The fact that it accept args that it ignores could be considered misleading or even a bug. Maybe, it could. But, it is by no means necessary. In mathematics, there is a set of important functions which behave precisely as described above (there ignore their arguments); they are called constant functions -- http://mail.python.org/mailman/listinfo/python-list
Python 2.6 Deprecation Warnings with __new__ — Can someone explain why?
Hi all,
I have a basic Monostate with Python 2.6.
class Borg(object):
__shared_state = {}
def __new__(cls, *args, **kwargs):
self = object.__new__(cls, *args, **kwargs)
self.__dict__ = cls.__shared_state
return self
def __init__(self, *args, **kwargs):
noSend = kwargs.get(noSend, False)
reportLevel = kwargs.get(reportLevel, 30)
reportMethods = kwargs.get(reportMethods, BaseReport)
contacts= kwargs.get(contacts, None)
a = Borg(contacts=Foo, noSend=Bar, )
Which happily gives me the following Deprecation warning..
untitled:4: DeprecationWarning: object.__new__() takes no parameters
self = object.__new__(cls, *args, **kwargs)
After a bit of googling I find this is attached to Bug #1683368. What
I can't figure out is what Guidos answer means. FWIW - It's
complaining about the following line
self = object.__new__(cls, *args, **kwargs)
Which appears (to me) to be OK. Can someone explain in laymens terms
why this is a problem. I understand that this is inconsistent with
other built-ins, like list but I'm not sure I understand why. Would
someone explain this show me the right way to do it? I have read
Guido's answer on this but I guess I just don't understand his
reasoning. In short Guido said the following:
The message means just what it says. :-) There's no point in
calling object.new() with more than a class parameter, and any code
that did so was just dumping those args into a black hole.
The only time when it makes sense for object.new() to ignore extra
arguments is when it's not being overridden, but init is being
overridden -- then you have a completely default new and the checking
of constructor arguments is relegated to init.
In my case the args that it dumps them into a black hold is simply not
true. I want an unknown set of args and kwargs to simply be forwarded
onto init. So what's the problem with this??
Thanks
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6 Deprecation Warnings with __new__ — Can someone explain why?
On Thu, Oct 22, 2009 at 8:12 PM, rh0dium steven.kl...@gmail.com wrote:
In my case the args that it dumps them into a black hold is simply not
true. I want an unknown set of args and kwargs to simply be forwarded
onto init. So what's the problem with this??
There is no problem with doing that-- the deprecation warning is just that
object.__new__ takes no arguments besides the class itself.
Within __new__ you do not need to do anything to forward the arguments to
__init__. Python calls first __new__, then __init__ with the arguments you
pass. You don't have to forward from one method to another.
Observe:
class myclass(object):
... def __new__(cls, *args, **kwargs):
... print args
... print kwargs
... self = object.__new__(cls)
... return self
... def __init__(self, *args, **kwargs):
... print args
... print kwargs
...
A = a()
()
{}
()
{}
A = a(1,2,3)
(1, 2, 3)
{}
(1, 2, 3)
{}
HTH,
--S
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6 Deprecation Warnings with __new__ — Can someone explain why?
On Oct 22, 8:12 pm, rh0dium steven.kl...@gmail.com wrote:
Hi all,
I have a basic Monostate with Python 2.6.
class Borg(object):
__shared_state = {}
def __new__(cls, *args, **kwargs):
self = object.__new__(cls, *args, **kwargs)
self.__dict__ = cls.__shared_state
return self
def __init__(self, *args, **kwargs):
noSend = kwargs.get(noSend, False)
reportLevel = kwargs.get(reportLevel, 30)
reportMethods = kwargs.get(reportMethods, BaseReport)
contacts= kwargs.get(contacts, None)
a = Borg(contacts=Foo, noSend=Bar, )
Before we get into object semantics, I'm not sure why you'd need to
override __new__ for Borg pattern, unless they're working around some
edge cases or something.
For that matter you shouldn't need args and kwargs either, you know
what the arguments to your function are.
This should suffice for you:
class Borg(object):
__shared_state = {}
def __init__(self, noSend=False,reportLevel=30,
reportMethods=BaseReport,
contacts=None):
self.__dict__ = self.__shared_state
self.noSend = noSend
self.reportLevel = reportLevel
self.reportMethods = reportMethods
self.contacts = contacts
This (as well as your class) will update the shared state for all Borg
objects whenever you instantiate a new Borg object. That might be
what you want, but be aware.
Which happily gives me the following Deprecation warning..
untitled:4: DeprecationWarning: object.__new__() takes no parameters
self = object.__new__(cls, *args, **kwargs)
After a bit of googling I find this is attached to Bug #1683368. What
I can't figure out is what Guidos answer means. FWIW - It's
complaining about the following line
self = object.__new__(cls, *args, **kwargs)
Which appears (to me) to be OK. Can someone explain in laymens terms
why this is a problem.
I don't mean to be flippant, but the reason you're seeing this error
is because object.__new__() takes no parameters.
There's not much more to it than that.
I'll explain below.
I understand that this is inconsistent with
other built-ins, like list but I'm not sure I understand why. Would
someone explain this show me the right way to do it?
object.__new__(cls)
I have read
Guido's answer on this but I guess I just don't understand his
reasoning. In short Guido said the following:
The message means just what it says. :-) There's no point in
calling object.new() with more than a class parameter, and any code
that did so was just dumping those args into a black hole.
The only time when it makes sense for object.new() to ignore extra
arguments is when it's not being overridden, but init is being
overridden -- then you have a completely default new and the checking
of constructor arguments is relegated to init.
In my case the args that it dumps them into a black hold is simply not
true.
Actually it is.
I want an unknown set of args and kwargs to simply be forwarded
onto init. So what's the problem with this??
The problem is that __new__ doesn't forward the arguments to
__init__. Look at what happens when you call this class:
class X(object):
def __new__(cls,*args,**kwargs):
return object.__new__(cls)
def __init__(self,*args,**kwargs):
print args, kwargs
X(1,2,q=3,g=4)
Note that *args and **kwargs are not passed to object.__new__, but
nevertheless __init__ is still called with them.
What's actually happens is that the type object's __call__ method
passes the same arguments to both __new__ and __init__.
The fact is, object.__new__ does nothing at all with the args and
kwargs arguments, it just ignores them. So, when calling
object.__new__, don't pass them to it.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6 Deprecation Warnings with __new__ — Can someone explain why?
On Thu, Oct 22, 2009 at 9:09 PM, Stephen Hansen apt.shan...@gmail.comwrote:
class myclass(object):
... def __new__(cls, *args, **kwargs):
... print args
... print kwargs
... self = object.__new__(cls)
... return self
... def __init__(self, *args, **kwargs):
... print args
... print kwargs
...
A = a()
()
{}
()
{}
A = a(1,2,3)
(1, 2, 3)
{}
(1, 2, 3)
{}
Sigh, as I try to correct stupid in-interactive-interpreter demonstration
code's really bad naming scheme in email but do it half-assed; obviously
those calls are supposed to be like a = myclass() and a =
myclass(1,2,3)
HTH,
--S
--
Stephen Hansen
Development
Advanced Prepress Technology
shan...@advpubtech.com
(818) 748-9282
--
http://mail.python.org/mailman/listinfo/python-list
can someone explain why this happens- newbie question
Hi can someone tell me why it prints the high score table multiple times? #high scores program scores =[] choice = None while choice != 0: print high Score Table 0 - exit 1 - show Scores 2 - add a score 3 - delete a score 4 - sort scores choice = input(what would you like to do?) if choice == 0: print goodbye elif choice == 1: for score in scores: print scores elif choice == 2: score = input(add a score) scores.append(score) elif choice == 3: score = input(what score would you like to delete ?) if score in scores: scores.remove(score) else: print that score is not listed elif choice == 4: scores.sort() scores.reverse() print scores, highest score first -- http://mail.python.org/mailman/listinfo/python-list
Re: can someone explain why this happens- newbie question
change: for score in scores: print scores to: for score in scores: print score that should do the trick :) Almar 2008/9/30 garywood [EMAIL PROTECTED] Hi can someone tell me why it prints the high score table multiple times? #high scores program scores =[] choice = None while choice != 0: print high Score Table 0 - exit 1 - show Scores 2 - add a score 3 - delete a score 4 - sort scores choice = input(what would you like to do?) if choice == 0: print goodbye elif choice == 1: for score in scores: print scores elif choice == 2: score = input(add a score) scores.append(score) elif choice == 3: score = input(what score would you like to delete ?) if score in scores: scores.remove(score) else: print that score is not listed elif choice == 4: scores.sort() scores.reverse() print scores, highest score first -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
can someone explain why ..
I don't understand what is the difference between commented lines 1 and 2 with 1 uncommented and 2 commented it works as expected with 1 commented and 2 uncommented the picture doesn't appear here is my code #!/usr/bin/env python from Tkinter import * from Tkconstants import * root = None class Main: def __init__(self): global root root = Tk(className = Zeitrechner) root.config(borderwidth = 5, relief = GROOVE) root.geometry(0x0+100+50) #self.im = image = PhotoImage(file = ./flower1.gif) #1 image = PhotoImage(file = ./flower1.gif) #2 frame1 = Frame(master = root, borderwidth = 3, relief = SUNKEN) imageLabel = Label(master = frame1, image = image) root.minsize(width = image.width(), height = image.height()) root.maxsize(width = 2*image.width(), height = image.height()) imageLabel.pack() frame1.pack(side = LEFT) def mainloop(self): root.mainloop() main = Main() main.mainloop() -- http://mail.python.org/mailman/listinfo/python-list
Re: can someone explain why ..
Schüle Daniel wrote: I don't understand what is the difference between commented lines 1 and 2 with 1 uncommented and 2 commented it works as expected with 1 commented and 2 uncommented the picture doesn't appear I'm not familiar with Tkinter, but it seems as thought with 2, the image variable is garbage collected after the constructor of Main is called. With 1, you save a reference to the image, so it does not get garbage collected. -Farshid -- http://mail.python.org/mailman/listinfo/python-list
Re: can someone explain why ..
Farshid Lashkari schrieb: Schüle Daniel wrote: I don't understand what is the difference between commented lines 1 and 2 with 1 uncommented and 2 commented it works as expected with 1 commented and 2 uncommented the picture doesn't appear I'm not familiar with Tkinter, but it seems as thought with 2, the image variable is garbage collected after the constructor of Main is called. With 1, you save a reference to the image, so it does not get garbage collected. thx for quick reply :) image is local variable of imageLabel I would expect that in case imageLabel lives, it should hold alife objects bound to its local variables I am just curious *why* reference to image is not hold by imageLabel which on his part is hold by frame1 .. which is hold by global root Regards, Daniel -- http://mail.python.org/mailman/listinfo/python-list
Re: can someone explain why ..
Schüle Daniel wrote: thx for quick reply :) image is local variable of imageLabel I would expect that in case imageLabel lives, it should hold alife objects bound to its local variables I am just curious *why* reference to image is not hold by imageLabel which on his part is hold by frame1 .. which is hold by global root These are the only lines of code that reference imageLabel: imageLabel = Label(master = frame1, image = image) imageLabel.pack() Unless the constructor of Label adds a reference of itself to frame1, imageLabel will also become garbage collected at the end of the constructor. Are you sure this is the case? -Farshid -- http://mail.python.org/mailman/listinfo/python-list
Re: can someone explain why ..
[..] These are the only lines of code that reference imageLabel: imageLabel = Label(master = frame1, image = image) imageLabel.pack() Unless the constructor of Label adds a reference of itself to frame1, imageLabel will also become garbage collected at the end of the constructor. Are you sure this is the case? yes, now i see it even can frame1 be dead after __init__ it binds itself too root with frame1 = Frame(master = root) frame1.pack(side = LEFT) frame1.pack may append frame1 to root's list of all widgets, we cannot see it, but it also may not do it Thx -- http://mail.python.org/mailman/listinfo/python-list
Re: can someone explain why ..
On 2006-04-25, Farshid Lashkari [EMAIL PROTECTED] wrote: Schüle Daniel wrote: I don't understand what is the difference between commented lines 1 and 2 with 1 uncommented and 2 commented it works as expected with 1 commented and 2 uncommented the picture doesn't appear I'm not familiar with Tkinter, but it seems as thought with 2, the image variable is garbage collected after the constructor of Main is called. With 1, you save a reference to the image, so it does not get garbage collected. Yes. That's exactly correct. It's sort of a FAQ. See the highlighted note at the bottom of http://effbot.org/tkinterbook/bitmapimage.htm -- Grant Edwards grante Yow! LOU GRANT froze at my ASSETS!! visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: can someone explain why ..
On 2006-04-25, Schüle Daniel [EMAIL PROTECTED] wrote: I'm not familiar with Tkinter, but it seems as thought with 2, the image variable is garbage collected after the constructor of Main is called. With 1, you save a reference to the image, so it does not get garbage collected. Correct. image is local variable of imageLabel Actually it's a parameter to the constructor that was called to create the imageLabel object. I would expect that in case imageLabel lives, it should hold alife objects bound to its local variables It would. Therefore the image object apparently isn't bound to a local variable in the object imageLabel. I am just curious *why* reference to image is not hold by imageLabel which on his part is hold by frame1... Good question. Untold millions of programmers have tripped over that bug. Well, would you believe untold dozens? I know I did. It's a common enough problem that it's given special mention in a couple books on Tkinter. My _guess_ is that this is one of the misfeatures resulting from the way Tkinter is implimented: it's not a real binding of Python to the tk library. It's a Python wrapper around a TCL interpreter which is bound to the tk library (or something like that). This results in some counter-intuitive (non-pythonic) behaviors like the one you discovered with bitmap images and labels. -- Grant Edwards grante Yow! I feel like I'm at in a Toilet Bowl with a visi.comthumbtack in my forehead!! -- http://mail.python.org/mailman/listinfo/python-list
