Re: Instances as dictionary key, __hash__ and __eq__

2013-02-19 Thread Jean-Michel Pichavant
> > Additionally, If I'm making things much more complicated than they > > need to be, let me know. > > You are. There are ways to achieve what you want, but it requires a > lot more setup and discipline. The simplest way is probably to have > a _equal_fields() method that subclasses override, r

Re: Instances as dictionary key, __hash__ and __eq__

2013-02-18 Thread Terry Reedy
On 2/18/2013 2:51 PM, Jean-Michel Pichavant wrote: Greetings, I opened something like a month ago a thread about hash functions and how I could write classes which instances can be safely used as dictionary keys. I though I had it but when I read back my code, I think I wrote yet another bug.

Re: Instances as dictionary key, __hash__ and __eq__

2013-02-18 Thread Tim Delaney
On 19 February 2013 06:51, Jean-Michel Pichavant wrote: > Greetings, > > I opened something like a month ago a thread about hash functions and how > I could write classes which instances can be safely used as dictionary keys. > I though I had it but when I read back my code, I think I wrote yet >

Re: Instances' __setitem__ methods

2011-06-20 Thread Chris Rebert
On Mon, Jun 20, 2011 at 6:42 PM, Spencer Pearson wrote: > I was recently trying to implement a dict-like object which would do > some fancy stuff when it was modified, and found that overriding the > __setitem__ method of an instance did not act the way I expected. The > help documentation (from h

Re: Instances' __setitem__ methods

2011-06-20 Thread Ethan Furman
Spencer Pearson wrote: I was recently trying to implement a dict-like object which would do some fancy stuff when it was modified, and found that overriding the __setitem__ method of an instance did not act the way I expected. The __magic__ methods are only looked up on the class, never the in

Re: Instances of BaseException and family don't provide __module__?

2007-11-02 Thread Steven D'Aprano
On Fri, 02 Nov 2007 19:36:05 -0700, Scott Dial wrote: > I have started working on a new project using ZSI and perhaps one can > argue this is a bug in ZSI, but I found it odd. The ZSI dispatcher needs > to catch all exceptions and pass that over to the client; in doing so, > it passes along the na

Re: instances

2006-07-14 Thread Nick Vatamaniuc
Quenton, What kind of instances do you want to create? An instance has to be an instance of something. You mention creating instances "of a method", what do you mean by that? Anyway, assuming you are new to Python here is a basic intro about objects and classes: Think of a class as a blueprint an

Re: instances

2006-07-14 Thread Simon Forman
Quenton Bonds wrote: > Hello > I am trying to understand the abilities and limitation of creating an > instance. First I will give you my understanding then please steer me > in the right direction. > Wow, you've got it nearly completely comprehensively backwards. > Abiities > 1. The two ways t

Re: instances

2006-07-14 Thread Paddy
Quenton Bonds wrote: > Hello > I am trying to understand the abilities and limitation of creating an > instance. First I will give you my understanding then please steer me > in the right direction. > > Abiities > 1. The two ways to create an instance is def method(self) & > __int__(self, other,

Re: instances

2006-07-14 Thread Fredrik Lundh
Quenton Bonds wrote: > I am trying to understand the abilities and limitation of creating an > instance. First I will give you my understanding then please steer me > in the right direction. > > Abiities > 1. The two ways to create an instance is def method(self) & > __int__(self, other, ins

Re: Instances behaviour

2005-12-04 Thread Giovanni Bajo
Mr.Rech wrote: > and so on. The problem I'm worried about is that an unaware user may > create an instance of "A" supposing that it has any real use, while it > is only a sort of prototype. However, I can't see (from my limited > point of view) any other way to rearrange things and still get a > s

Re: Instances behaviour

2005-12-02 Thread Inyeol Lee
On Fri, Dec 02, 2005 at 10:43:56AM +0100, bruno at modulix wrote: > Inyeol Lee wrote: > (snip) > > class A(object): > ... def __init__(self, foo): > ... if self.__class__ is A: > ... raise TypeError("A is base class.") > > > s/TypeError/NotI

Re: Instances behaviour

2005-12-02 Thread Mr.Rech
I see your point. Looking again at my metaclass implementation and comparing it with your abstract class + inheritance approach it turns out that the latter is definetively more straightforward, easier to maintain and all in all more pythonic. Sorry, but being an OOP newbie put me in the position

Re: Instances behaviour

2005-12-02 Thread bruno at modulix
Mr.Rech wrote: > Thanks for your suggestions. They are very usefull and indeed bypass my > problem. However, I've found a (perhaps) more elegant way to get the > same result using metaclasses. (snip code) > > I know metaclasses are a complete different beast, anyway I find this > approach more

Re: Instances behaviour

2005-12-02 Thread Peter Otten
Mr.Rech wrote: > Thanks for your suggestions. They are very usefull and indeed bypass my > problem. However, I've found a (perhaps) more elegant way to get the > same result using metaclasses. My idea is to define my classes as > follows: > class meta_A(type): > def __new__(cls, cl

Re: Instances behaviour

2005-12-02 Thread Mr.Rech
Thanks for your suggestions. They are very usefull and indeed bypass my problem. However, I've found a (perhaps) more elegant way to get the same result using metaclasses. My idea is to define my classes as follows: >>> class meta_A(type): def __new__(cls, classname, bases, classdict):

Re: Instances behaviour

2005-12-02 Thread bruno at modulix
Inyeol Lee wrote: (snip) class A(object): ... def __init__(self, foo): ... if self.__class__ is A: ... raise TypeError("A is base class.") s/TypeError/NotImplementedError/ s/base class/abstract class/ -- bruno desthuilliers python -c "pri

Re: Instances behaviour

2005-12-02 Thread Peter Otten
Mr.Rech wrote: > Suppose I have a bunch of classes that represent slightly (but > conceptually) different object. The instances of each class must behave > in very similar manner, so that I've created a common class ancestor > (let say A) that define a lot of special method (such as __getattr__, >

Re: Instances behaviour

2005-12-01 Thread Mike Meyer
"Mr.Rech" <[EMAIL PROTECTED]> writes: > Suppose I have a bunch of classes that represent slightly (but > conceptually) different object. The instances of each class must behave > in very similar manner, so that I've created a common class ancestor > (let say A) that define a lot of special method (

Re: Instances behaviour

2005-12-01 Thread Inyeol Lee
On Thu, Dec 01, 2005 at 03:51:05PM -0800, Mr.Rech wrote: [...] > Suppose I have a bunch of classes that represent slightly (but > conceptually) different object. The instances of each class must behave > in very similar manner, so that I've created a common class ancestor > (let say A) that define

Re: Instances of class object not modifiable?

2005-01-25 Thread Nick Coghlan
Steven Bethard wrote: Open Issues === What should the type be named? Some suggestions include 'Bunch', 'Record' and 'Struct'. Add 'namespace' to the list of name suggestions :) Cheers, Nick. The name came up in some thread a few weeks back. . . -- Nick Coghlan | [EMAIL PROTECTED] |

Re: Instances of class object not modifiable?

2005-01-24 Thread Steven Bethard
Krzysztof Stachlewski wrote: I tried to run the following piece of code: Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. o = object() o.a = 5 Traceback (most recent call last): File "", line 1, i