Re: class inheritance when not defined

[Ben Finney]

Steve D'Aprano  writes:

> Good way:
>
> Foreigner speaking English as their second language:
> "Who is the father of this class?"
>
> Native English speaker:
> "The father is 'object', but in English we would normally ask
> 'what is the parent?' instead."

Of the three scenarios you presented, this is clearly the closest. I
gave the correct answer, I offered a correction to English usage, and I
gave no insult to the questioner.

-- 
 \   “Nothing exists except atoms and empty space; everything else |
  `\  is opinion.” —Democritus |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: class inheritance when not defined

[Steve D'Aprano]

On Fri, 8 Sep 2017 07:03 pm, Ben Finney wrote:

>> Who is the father of ExampleClass1 ?
> 
> No-one, since classes do not have gender. (The convention is to use the
> gender-neutral “parent” to refer to that relationship.)


Possibly not the case in Russia. Besides, words have gender in many languages.

While I have no problem with correcting people's English when it is relevant,
there's a good way and a bad way to do it.

Good way:

Foreigner speaking English as their second language:
"Who is the father of this class?"

Native English speaker:
"The father is 'object', but in English we would normally 
ask 'what is the parent?' instead."

Bad way:

Foreigner:
"Who is the father of this class?"

Native:
"No one, you ignorant heathen foreigner!"

Worse way:

Foreigner:
"Who is the father of this class?"

Native:
*PLONK*



I'll leave you to guess where I think your response fits in this scale :-)





-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: class inheritance when not defined

[Ben Finney]

Andrej Viktorovich  writes:

> I found several class creation samples:
>
> class ExampleClass1:
>
> class ExampleClass2(object):
>
>
> What is difference between them?

Very little difference.

In Python 3, both create classes that inherit from one other class,
‘object’.

In Python 2, the first creates ‘ExampleClass1’ that has no parent class,
and doesn't work in the standard type hierarchy. The ‘ExampleClass2’
class inherits from ‘object’ and does participate in the standard type
hierarchy.

This is, broadly, one of the good reasons to abandon Python 2: you can
forget about the special case of classes that don't inherit from
‘object’. In Python 3, they don't exist because every class inherits
ultimately from ‘object’.

> Who is the father of ExampleClass1 ?

No-one, since classes do not have gender. (The convention is to use the
gender-neutral “parent” to refer to that relationship.)

-- 
 \“We cannot solve our problems with the same thinking we used |
  `\   when we created them.” —Albert Einstein |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: class inheritance when not defined

[Thomas Jollans]

On 2017-09-08 10:17, Andrej Viktorovich wrote:
> Hello
> 
> I found several class creation samples:
> 
> class ExampleClass1:
> 
> class ExampleClass2(object):
> 
> 
> What is difference between them? Who is the father of ExampleClass1 ?
> 


In Python 3, unless you've redefined "object", these are the same.

Python 2 had, for historical reasons, a distinction between "old-style"
and "new-style" classes. It normally doesn't matter much, but explicitly
inheriting from object makes a class new-style.


-- 
Thomas Jollans
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance from different module

[Jean-Michel Pichavant]

- Original Message -
> From: "Jean-Michel Pichavant" 
> To: "Juan Christian" 
> Cc: "Python" 
> Sent: Monday, 22 September, 2014 1:37:41 PM
> Subject: Re: Class Inheritance from different module
> 
> 
> > class User(Inheritance from API):
> > def __init__(self, ID):
> > steamapi.core.APIConnection(api_key = KEY)
> > super( " Inheritance SteamUser" (ID)) # creates the user using the
> > API
> > 
> > 
> > [...]
> > 
> > 
> > So that in my code when I need to create a new user, I just call
> > 'usr
> > = User("XXX")' instead of calling 'usr =
> > steamapi.user.SteamUser(76561197996416028)', is that possible?
> [snip

Sorry, sent the message by mistake.

Anyway if you just want a nice way to create an instance, you may simply write

import steamapi.user.SteamUser as User

usr = User('whatever')

However you don't create an APIConnection when creating a user, it does not 
make much sense, you only need one API connection per session and it will be 
shared by all the User objects.

# Note ApiConnection is a singleton, and you only need to execute this once, in 
you app/script initialization for instance.
api = APIConnection(api_key='dlkfnsdlfn')

# query the database
user1 = User('user1')
user2 = User('user2')

Cheers,

JM


NB: I assumed you were using https://github.com/smiley/steamapi
NB2 : because APIConnection is a singleton, your original code probably works 
just fine, I'm just not a big fan of breaking to python module design


-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be 
privileged. If you are not the intended recipient, please notify the sender 
immediately and do not disclose the contents to any other person, use it for 
any purpose, or store or copy the information in any medium. Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance from different module

[Jean-Michel Pichavant]

> class User(Inheritance from API):
> def __init__(self, ID):
> steamapi.core.APIConnection(api_key = KEY)
> super( " Inheritance SteamUser" (ID)) # creates the user using the
> API
> 
> 
> [...]
> 
> 
> So that in my code when I need to create a new user, I just call 'usr
> = User("XXX")' instead of calling 'usr =
> steamapi.user.SteamUser(76561197996416028)', is that possible?
[snip


-- IMPORTANT NOTICE: 

The contents of this email and any attachments are confidential and may also be 
privileged. If you are not the intended recipient, please notify the sender 
immediately and do not disclose the contents to any other person, use it for 
any purpose, or store or copy the information in any medium. Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance from different module

[Peter Otten]

Juan Christian wrote:

> I have the following structure:
> 
> Third-party API installed via pip:
> steamapi /
> app.py
> consts.py
> core.py
> users.py
> [...]
> 
> My script:
> test.py
> 
> 
> In the API, the module users.py has a class 'SteamUser' and I want to
> mimic it's usage on my code, like this:
> 
> import steamapi
> 
> [...]
> 
> class User(Inheritance from API):
> def __init__(self, ID):
> steamapi.core.APIConnection(api_key = KEY)
> super( " Inheritance SteamUser" (ID)) # creates the user using the API
> 
> [...]
> 
> So that in my code when I need to create a new user, I just call 'usr =
> User("XXX")' instead of calling 'usr =
> steamapi.user.SteamUser(76561197996416028)', is that possible? 

Yes, it doesn't matter in what module a baseclass is defined. Just go ahead 
and import it:

# untested
import steamapi.user

class User(steamapi.user.User):
def __init__(self, userid=None, userurl=None):
super().__init__(userid, userurl)
# code specific to you subclass

> And of
> course, I want to have access to all the class methods like 'name',
> 'country_code', 'time_created', 'avatar', 'friends' and so on. 

That's the very idea of subclassing.

> And finally, is that a good approach, pythonic? 

It depends ;) If you are planning only small adjustments it might be an 
option to write a few helper functions together with the original 
steamapi.user.User class and be done.

> If not, what would be a good way?

Generally speaking the Python community often favours duck-typing or 
composition over inheritance. I'm not prepared to go into a lengthy 
discussion over this -- if you are interested you have to try a search 
engine or rely on the usual suspects ;)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance from different module

[Steven D'Aprano]

Juan Christian wrote:

[...]
> In the API, the module users.py has a class 'SteamUser' and I want to
> mimic it's usage on my code, like this:
> 
> import steamapi
> 
> [...]
> 
> class User(Inheritance from API):

What do you mean, "Inheritance from API"? You can't inherit from an API,
only from classes.


> def __init__(self, ID):
> steamapi.core.APIConnection(api_key = KEY)
> super( " Inheritance SteamUser" (ID)) # creates the user using the API
> 
> [...]
> 
> So that in my code when I need to create a new user, I just call 'usr =
> User("XXX")' instead of calling 'usr =
> steamapi.user.SteamUser(76561197996416028)', is that possible?

I would do something like this:

# untested
def make_user(ID):
steamapi.core.APIConnection(api_key = KEY)
return steamapi.user.SteamUser(76561197996416028)

usr = make_user("X")


No need for inheritance. make_user returns an actual SteamUser instance, not
some subclass.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: class inheritance python2.7 vs python3.3

[jwe . van . dijk]

On Monday, 6 January 2014 18:14:08 UTC+1, jwe.va...@gmail.com  wrote:
> I have problems with these two classes:
> 
> 
> 
> class LPU1():
> 
> def __init__(self, formula):
> 
> """
> 
> formula is a string that is parsed into a SymPy function
> 
> and several derived functions
> 
> """
> 
> self.formula = formula
> 
> ... ...
> 
> 
> 
> class LPU3(LPU1):
> 
> def __new__(self):
> 
> """
> 
> the same functions as LPU1 but some added functions
> 
> and some functions redefined
> 
> """
> 
> ... ...
> 
> 
> 
> if __name__ == '__main__:
> 
> y = y = 'x_0 * x_1 + x_2'
> 
> stats1 = LPU1(y)
> 
> stats3 = LPU3(y)
> 
> 
> 
> Worked perfectly on Python 2.7.5+ but on Python 3.3.2+ I get on 
> instantiatiating stat3:
> 
> TypeError: __new__() takes 1 positional argument but 2 were given
> 
> 
> 
> What am I doing wrong?
> 
> I must confess I am a bit out of my depth here so any explanation will be a 
> learning experience.
> 
> 
> 
> Many thanks, Janwillem

Thanks for all the contributions. I now have:
class LPU1(object):
def __init__(self, formula):
... ...
and
class LPU3(LPU1):
def __init__(self, y):
LPU1.__init__(self, y)
   ... ...

which gives the correct results both on 2.7 and 3.3.
Is that more or less good practice?
Now I stumble on a SymPy problem under 3.3 but that obviously is an other topic
Cheers, janwillem
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: class inheritance python2.7 vs python3.3

[Steven D'Aprano]

jwe.van.d...@gmail.com wrote:

> I have problems with these two classes:
> 
> class LPU1():
> def __init__(self, formula):
> """
> formula is a string that is parsed into a SymPy function
> and several derived functions
> """
> self.formula = formula
> ... ...
> 
> class LPU3(LPU1):
> def __new__(self):
> """
> the same functions as LPU1 but some added functions
> and some functions redefined
> """
> ... ...

If this actually is your class, then in Python 2.7 the __new__ method will
do nothing at all.

However, if you actually inherited from object in LPU1, then it (might) work
in Python 2.7. In Python 3.3, it will work regardless. Perhaps you have a
bug in the __new__ method? In Python 2.7, it is never called, and so the
bug never occurs. In Python 3.3, it is called, and the bug occurs.


> Worked perfectly on Python 2.7.5+ but on Python 3.3.2+ I get on
> instantiatiating stat3: TypeError: __new__() takes 1 positional argument
> but 2 were given

And sure enough, that's exactly it.



> What am I doing wrong?
> I must confess I am a bit out of my depth here so any explanation will be
> a learning experience.

Back in the Dark Ages of Python 1.x, built-in types like int, str, list and
so forth were completely independent of classes created with the class
statement. So you couldn't subclass them.

In Python 2.2, Python underwent what was called "class/type unification",
which added a new mechanism to allow built-in types to be subclassed. For
reasons of backward compatibility, the existing classes were left alone,
and were called "old style" or "classic" classes. But a new built-in,
called object, was created. All the other built-in types (str, list, int,
etc.) inherit from object. These became known as "new style classes".

New style classes had extra features that classic classes don't have,
including the __new__ constructor method. (Classic classes don't let you
override the constructor, only the initializer, __init__. New-style classes
let you override both.)

So Python 2.2 and beyond has two distinct models for classes, which *mostly*
work the same but have a few differences -- those that inherit from object
or some other built-in type, and those that don't.

# Python 2 classic class:
class LPU1():
 def __new__(cls): ...

__new__ is dead code here, and won't be called.

# Python 2 new-style class:
class LPU1(object):
 def __new__(cls): ...

__new__ is called.

So when you inherit from LPU1, your LPU3 class gets the same "old"
versus "new" behaviour, and __new__ is either dead code or not.

Now fast forward to Python 3. In Python 3, having two types of classes was
considered one too many. The old-style classes were dropped. Inheriting
from object became optional. Either way, you would get the same behaviour,
and __new__ is always used. So if you have a buggy __new__ method, it could
be ignored in Python 2 and suddenly run in Python 3, giving you an error.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: class inheritance python2.7 vs python3.3

[Dave Angel]

On Mon, 6 Jan 2014 09:14:08 -0800 (PST), jwe.van.d...@gmail.com wrote:

I have problems with these two classes:




class LPU1() :


You forgot to derive from object. That's implied on 3.x, but you say 
you're also running on 2.7  Without naming your base class you're 
asking for an old style class which has been obsolete maybe 10 years. 
I sure don't recall how it differs.



def __init__(self, formula):
"""
formula is a string that is parsed into a SymPy function
and several derived functions
"""
self.formula = formula
... ...




class LPU3(LPU1):
def __new__(self):
"""
the same functions as LPU1 but some added functions
and some functions redefined


You don't show where you call super, so we can't tell what you had in 
mind. And did you actually mean __new__ here or should you have 
defined __init__ as you did in the base class?



if __name__ == '__main__:
y = y = 'x_0 * x_1 + x_2'
stats1 = LPU1(y)
stats3 = LPU3(y)


And where did you expect that y to go?


Worked perfectly on Python 2.7.5+ but on Python 3.3.2+ I get on 

instantiatiating stat3:

I don't see anything called stat3. Presumably you mean stats3, but 
you're not instantiating it you're instantiating LPU3.



TypeError: __new__() takes 1 positional argument but 2 were given


You forgot to include the rest of the stack trace.


I think the real problem is you forgot to include the second 
parameter on the misnamed __init__ method. It should have parameters 
self and arg, and pass arg up through super.


--
DaveA

--
https://mail.python.org/mailman/listinfo/python-list

Re: class inheritance python2.7 vs python3.3

[Chris Angelico]

On Tue, Jan 7, 2014 at 4:14 AM,   wrote:
> class LPU3(LPU1):
> def __new__(self):
> """
> the same functions as LPU1 but some added functions
> and some functions redefined
> """

You probably don't want to be using __new__ here. Try using __init__
instead, or simply not defining __new__ at all.

I suspect that the reason that appears to work under Py2 is that
you're using an old-style class, there. That means it'll be subtly
different on the two versions. To make them do the same thing,
explicitly subclass object:

class LPU1(object):

In Python 3, that's redundant - subclassing object is the default. In
Python 2, though, it's important.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[JLundell]

That's nice, Ethan, especially in that it saves having to explicitly find and 
list all the methods being covered. It's perhaps not quite so critical for a 
Fraction-based class, since the set of methods to be covered is fairly well 
contained, but that's not always going to be the case.

The approach I mentioned earlier (rebinding __class__) is a little faster, 
since it avoids a call to __new__, but the difference is no doubt negligible in 
this example, since rational arithmetic isn't exactly lightning fast.

Thanks.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[Ethan Furman]

JLundell wrote:

On Saturday, March 13, 2010 9:03:36 AM UTC-8, Jonathan Lundell wrote:

I've got a subclass of fractions.Fraction called Value; it's a mostly
trivial class, except that it overrides __eq__ to mean 'nearly equal'.
However, since Fraction's operations result in a Fraction, not a
Value, I end up with stuff like this:

x = Value(1) + Value(2)

where x is now a Fraction, not a Value, and x == y uses
Fraction.__eq__ rather than Value.__eq__.

This appears to be standard Python behavior (int does the same thing).
I've worked around it by overriding __add__, etc, with functions that
invoke Fraction but coerce the result. But that's tedious; there are a
lot of methods to override.

So I'm wondering: is there a more efficient way to accomplish what I'm
after?


I recently implemented a different approach to this. I've got:

class Rational(fractions.Fraction):

... and some methods of my own, including my own __new__ and __str__ (which is 
one of the reasons I need the class). Then after (outside) the class 
definition, this code that was inspired by something similar I noticed in 
Python Cookbook. There are two things going on here. One is, of course, the 
automation at import time. The other is that the wrapper gets a Fraction 
instance and simply overrides __class__, rather than creating yet another 
Rational and unbinding the interim Fraction. Seems to work quite well.


[snip]

Another option is to use a metaclass:

class Perpetuate(ABCMeta):
def __new__(metacls, cls_name, cls_bases, cls_dict):
if len(cls_bases) > 1:
raise TypeError("multiple bases not allowed")
result_class = type.__new__(metacls, cls_name,
cls_bases, cls_dict)
base_class = cls_bases[0]
known_attr = set()
for attr in cls_dict.keys():
known_attr.add(attr)
for attr in base_class.__dict__.keys():
if attr in ('__new__'):
continue
code = getattr(base_class, attr)
if callable(code) and attr not in known_attr:
setattr(result_class, attr,
metacls._wrap(base_class, code))
elif attr not in known_attr:
setattr(result_class, attr, code)
return result_class
@staticmethod
def _wrap(base, code):
def wrapper(*args, **kwargs):
if args:
cls = args[0]
result = code(*args, **kwargs)
if type(result) == base:
return cls.__class__(result)
elif isinstance(result, (tuple, list, set)):
new_result = []
for partial in result:
if type(partial) == base:
new_result.append(cls.__class__(partial))
else:
new_result.append(partial)
result = result.__class__(new_result)
elif isinstance(result, dict):
for key in result:
value = result[key]
if type(value) == base:
result[key] = cls.__class__(value)
return result
wrapper.__name__ = code.__name__
wrapper.__doc__ = code.__doc__
return wrapper


then the actual class becomes:

class CloseFraction(Fraction):
__metaclass__ = Perpetuate
def __eq__(x, y):
return abs(x - y) < 1  # season to taste
def __repr__(x):
return "CloseFraction(%d, %d)" % (x.numerator, x.denominator)

Perpetuate needs to handle multiple inheritance better, but it might 
meet your needs at this point.


Sample run:
--> n = CloseFraction(3, 2)
--> n
CloseFraction(3, 2)
--> print n
3/2
--> m = CloseFraction(9, 4)
--> m
CloseFraction(9, 4)
--> n == m
True
--> n - m
CloseFraction(-3, 4)
--> n + m
CloseFraction(15, 4)
--> n.real
CloseFraction(3, 2)
--> n.imag
0  # this is an int

Hope this helps!

~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[JLundell]

On Saturday, March 13, 2010 9:03:36 AM UTC-8, Jonathan Lundell wrote:
> I've got a subclass of fractions.Fraction called Value; it's a mostly
> trivial class, except that it overrides __eq__ to mean 'nearly equal'.
> However, since Fraction's operations result in a Fraction, not a
> Value, I end up with stuff like this:
> 
> x = Value(1) + Value(2)
> 
> where x is now a Fraction, not a Value, and x == y uses
> Fraction.__eq__ rather than Value.__eq__.
> 
> This appears to be standard Python behavior (int does the same thing).
> I've worked around it by overriding __add__, etc, with functions that
> invoke Fraction but coerce the result. But that's tedious; there are a
> lot of methods to override.
> 
> So I'm wondering: is there a more efficient way to accomplish what I'm
> after?

I recently implemented a different approach to this. I've got:

class Rational(fractions.Fraction):

... and some methods of my own, including my own __new__ and __str__ (which is 
one of the reasons I need the class). Then after (outside) the class 
definition, this code that was inspired by something similar I noticed in 
Python Cookbook. There are two things going on here. One is, of course, the 
automation at import time. The other is that the wrapper gets a Fraction 
instance and simply overrides __class__, rather than creating yet another 
Rational and unbinding the interim Fraction. Seems to work quite well.

# create wrappers for Rational methods that return Rational (not Fraction) 
objects
#
def _wrap_method(method):
"wrap a Fraction method in Rational"
fraction_method = getattr(Fraction, method)
def x(*args):
"call Fraction and change result to Rational"
v = fraction_method(*args)
v.__class__ = Rational
return v
x.func_name = method
setattr(Rational, method, x)

for name in "pos neg abs trunc".split():
_wrap_method("__%s__" % name)   # wrap method, eg __pos__

for name in "add sub mul div truediv floordiv mod pow".split():
_wrap_method("__%s__" % name)   # wrap method, eg __add__
_wrap_method("__r%s__" % name)  # wrap reversed-argument method, eg __radd__

del _wrap_method
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[JLundell]

On Mar 17, 5:12 pm, Steven D'Aprano
 wrote:
> On Mon, 15 Mar 2010 16:34:35 -0700,JLundellwrote:
> > It's also unfortunate that Python doesn't have an approximately-equal
> > operator; it'd come in handy for floating-point applications while
> > preserving hash. If only there were a ~= or ≈ operator I could overload.
> > And ~ is unary, so no joy.
>
> Not everything needs to be a built-in, or an operator. This might be
> useful for you:
>
> http://code.activestate.com/recipes/577124-approximately-equal/
>
> Feedback welcome.
>
> --
> Steven

Thanks, Steven. I'd considered and rejected that a while ago, but on
reconsideration it's sounding like a better idea. Aside from
preserving the semantics of =, it makes the use of approximate
equality explicit in the code, and that's a plus for what I'm doing.
I'll give it a shot.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[Steven D'Aprano]

On Mon, 15 Mar 2010 16:34:35 -0700, JLundell wrote:

> It's also unfortunate that Python doesn't have an approximately-equal
> operator; it'd come in handy for floating-point applications while
> preserving hash. If only there were a ~= or ≈ operator I could overload.
> And ~ is unary, so no joy.

Not everything needs to be a built-in, or an operator. This might be 
useful for you:

http://code.activestate.com/recipes/577124-approximately-equal/


Feedback welcome.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[Robert Kern]

On 2010-03-16 17:55 PM, JLundell wrote:

On Mar 16, 8:06 am, Robert Kern  wrote:

On 2010-03-16 07:35 AM, Dave Angel wrote:


Carl Banks wrote:

On Mar 15, 4:34 pm, JLundell  wrote:

It's also unfortunate that Python doesn't have an approximately-equal
operator; it'd come in handy for floating-point applications while
preserving hash. If only there were a ~=r ≈ operator I could
overload. And ~ is unary, so no joy.



One problem with it is that there's no way to make it universal;
different appiplications have different ideas of close. Conceivably
it could be usefully defined for a user type though..



Bacause of this problem almost no languages have an almost equal
operator. I'm curious what languages do, of if there are any with a
trinary operator that also takes a threshold.



Carl Banks



If I recall correctly, APL has a *fuzz* value, which is used in all(?)
comparisons. But I do not recall anything about how it was defined. I do
recall that you could change the threshold, and suspect it was relative
to the operands. For symmetry, it would probably have to be relative to
the average of the two values, or some such.


The problem is that frequently there is no system-wide fuzz value which is
appropriate for all comparisons in a given program. You need to choose the right
value for each comparison. Consequently, you might as well use a function
instead of an operator and a global variable.

--
Robert Kern



APL scaled their fuzz to the larger of the values being compared.


I know. My statement stands for relative fuzz values as well as it does for 
absolute fuzz values. :-)



In
my case, my domain permits me to use a constant fuzz; all my units are
the same (votes, as it happens). I've seen abs(a/b-1) used instead of
abs(a-b); obviously you'd need to treat comparison with zero
specially.


One usually uses a combination of relative and absolute tolerances to account 
for the case when the values are close to zero.



But yeah, it's really a domain-specific problem.


Right. And a single program might need to deal with multiple domains, so a 
single global setting to control a language feature is pretty fragile.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[JLundell]

On Mar 16, 8:06 am, Robert Kern  wrote:
> On 2010-03-16 07:35 AM, Dave Angel wrote:
>
>
>
>
>
>
>
> > Carl Banks wrote:
> >> On Mar 15, 4:34 pm, JLundell  wrote:
> >>> It's also unfortunate that Python doesn't have an approximately-equal
> >>> operator; it'd come in handy for floating-point applications while
> >>> preserving hash. If only there were a ~=r ≈ operator I could
> >>> overload. And ~ is unary, so no joy.
>
> >> One problem with it is that there's no way to make it universal;
> >> different appiplications have different ideas of close. Conceivably
> >> it could be usefully defined for a user type though..
>
> >> Bacause of this problem almost no languages have an almost equal
> >> operator. I'm curious what languages do, of if there are any with a
> >> trinary operator that also takes a threshold.
>
> >> Carl Banks
>
> > If I recall correctly, APL has a *fuzz* value, which is used in all(?)
> > comparisons. But I do not recall anything about how it was defined. I do
> > recall that you could change the threshold, and suspect it was relative
> > to the operands. For symmetry, it would probably have to be relative to
> > the average of the two values, or some such.
>
> The problem is that frequently there is no system-wide fuzz value which is
> appropriate for all comparisons in a given program. You need to choose the 
> right
> value for each comparison. Consequently, you might as well use a function
> instead of an operator and a global variable.
>
> --
> Robert Kern
>

APL scaled their fuzz to the larger of the values being compared. In
my case, my domain permits me to use a constant fuzz; all my units are
the same (votes, as it happens). I've seen abs(a/b-1) used instead of
abs(a-b); obviously you'd need to treat comparison with zero
specially.

But yeah, it's really a domain-specific problem.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[Robert Kern]

On 2010-03-16 07:35 AM, Dave Angel wrote:



Carl Banks wrote:

On Mar 15, 4:34 pm, JLundell  wrote:

It's also unfortunate that Python doesn't have an approximately-equal
operator; it'd come in handy for floating-point applications while
preserving hash. If only there were a ~=r ≈ operator I could
overload. And ~ is unary, so no joy.


One problem with it is that there's no way to make it universal;
different appiplications have different ideas of close. Conceivably
it could be usefully defined for a user type though..

Bacause of this problem almost no languages have an almost equal
operator. I'm curious what languages do, of if there are any with a
trinary operator that also takes a threshold.

Carl Banks


If I recall correctly, APL has a *fuzz* value, which is used in all(?)
comparisons. But I do not recall anything about how it was defined. I do
recall that you could change the threshold, and suspect it was relative
to the operands. For symmetry, it would probably have to be relative to
the average of the two values, or some such.


The problem is that frequently there is no system-wide fuzz value which is 
appropriate for all comparisons in a given program. You need to choose the right 
value for each comparison. Consequently, you might as well use a function 
instead of an operator and a global variable.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

--
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[Dave Angel]

Carl Banks wrote:

On Mar 15, 4:34 pm, JLundell  wrote:
  

It's also unfortunate that Python doesn't have an approximately-equal
operator; it'd come in handy for floating-point applications while
preserving hash. If only there were a ~=r ≈ operator I could
overload. And ~ is unary, so no joy.



One problem with it is that there's no way to make it universal;
different appiplications have different ideas of close.  Conceivably
it could be usefully defined for a user type though..

Bacause of this problem almost no languages have an almost equal
operator.  I'm curious what languages do, of if there are any with a
trinary operator that also takes a threshold.

Carl Banks

  
If I recall correctly, APL has a *fuzz* value, which is used in all(?) 
comparisons. But I do not recall anything about how it was defined. I do 
recall that you could change the threshold, and suspect it was relative 
to the operands. For symmetry, it would probably have to be relative to 
the average of the two values, or some such.

--
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[Carl Banks]

On Mar 15, 4:34 pm, JLundell  wrote:
> It's also unfortunate that Python doesn't have an approximately-equal
> operator; it'd come in handy for floating-point applications while
> preserving hash. If only there were a ~= or ≈ operator I could
> overload. And ~ is unary, so no joy.

One problem with it is that there's no way to make it universal;
different appiplications have different ideas of close.  Conceivably
it could be usefully defined for a user type though..

Bacause of this problem almost no languages have an almost equal
operator.  I'm curious what languages do, of if there are any with a
trinary operator that also takes a threshold.

Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[JLundell]

On Mar 13, 1:26 pm, Carl Banks  wrote:
> It's a tad unfortunately Python doesn't make this easier.  If I had to
> do it more than once I'd probably write a mixin to do it:
>
> class ArithmeticSelfCastMixin(object):
>     def __add__(self,other):
>         return
> self.__class__(super(ArithmeticSelfCastMixin,self).__add__(other)
>     # etc.
>
> class Value(ArithmeticSelfCastMixin,fraction.Fraction):
>     pass
>
> However, I want to warn you about overriding __eq__ to mean "almost
> equal": it can have unexpected results so I don't recommend it.  Two
> of the main issues with it are:
>
> 1. It violates the transitive property ("If A == B and B == C, then A
> == C") which most programmers expect to be true.
>
> 2. It will give unpredictable results when the objects are used in
> sets or as dictionary keys.  Those thow types expect the transitive
> property to be true.  If you are going to redefine __eq__ to mean
> "almost equal", then at least define __hash__ to raise
> NotImplementedError so that Python will refuse to use them in sets or
> as dictionary keys:
>
>     def __hash__(self): raise NotImplementedError
>
> Carl Banks

It's also unfortunate that Python doesn't have an approximately-equal
operator; it'd come in handy for floating-point applications while
preserving hash. If only there were a ~= or ≈ operator I could
overload. And ~ is unary, so no joy.

My application is in that sense a little like a floating-point app, in
that it needs approximately-equal. And it doesn't need Value to be
hashable; thanks for the NotImplementedError suggestion; I've done
that as a safeguard.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[Jean-Michel Pichavant]

JLundell wrote:

I've got a subclass of fractions.Fraction called Value; it's a mostly
trivial class, except that it overrides __eq__ to mean 'nearly equal'.
However, since Fraction's operations result in a Fraction, not a
Value, I end up with stuff like this:

x = Value(1) + Value(2)

where x is now a Fraction, not a Value, and x == y uses
Fraction.__eq__ rather than Value.__eq__.

This appears to be standard Python behavior (int does the same thing).
I've worked around it by overriding __add__, etc, with functions that
invoke Fraction but coerce the result. But that's tedious; there are a
lot of methods to override.

So I'm wondering: is there a more efficient way to accomplish what I'm
after?
  

I would change the approach.
To the question, "*is* a Value a Fraction", some may tempted to answer 
"No" (for instance, a fraction has a denominator, a value has not).

However "Does a Fraction *have* a Value", you could possibly say "Yes".

The value may be then an attribute of the class Fraction, not a subclass.
To test fraction equality, use F1 == F2. In order to test 'nearly 
equality', use F1.val() == F2.val().


JM




--
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[Carl Banks]

On Mar 13, 9:03 am, JLundell  wrote:
> I've got a subclass of fractions.Fraction called Value; it's a mostly
> trivial class, except that it overrides __eq__ to mean 'nearly equal'.
> However, since Fraction's operations result in a Fraction, not a
> Value, I end up with stuff like this:
>
> x = Value(1) + Value(2)
>
> where x is now a Fraction, not a Value, and x == y uses
> Fraction.__eq__ rather than Value.__eq__.
>
> This appears to be standard Python behavior (int does the same thing).
> I've worked around it by overriding __add__, etc, with functions that
> invoke Fraction but coerce the result. But that's tedious; there are a
> lot of methods to override.
>
> So I'm wondering: is there a more efficient way to accomplish what I'm
> after?

It's a tad unfortunately Python doesn't make this easier.  If I had to
do it more than once I'd probably write a mixin to do it:

class ArithmeticSelfCastMixin(object):
def __add__(self,other):
return
self.__class__(super(ArithmeticSelfCastMixin,self).__add__(other)
# etc.


class Value(ArithmeticSelfCastMixin,fraction.Fraction):
pass


However, I want to warn you about overriding __eq__ to mean "almost
equal": it can have unexpected results so I don't recommend it.  Two
of the main issues with it are:

1. It violates the transitive property ("If A == B and B == C, then A
== C") which most programmers expect to be true.

2. It will give unpredictable results when the objects are used in
sets or as dictionary keys.  Those thow types expect the transitive
property to be true.  If you are going to redefine __eq__ to mean
"almost equal", then at least define __hash__ to raise
NotImplementedError so that Python will refuse to use them in sets or
as dictionary keys:

def __hash__(self): raise NotImplementedError


Carl Banks
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[JLundell]

On Mar 13, 9:37 am, Jack Diederich  wrote:
> If Fraction.__add__ returns a new object but the subclass Value is
> compatible (as I would except since it is a sublcass) then just change
> all references in Franction.__add__ to be more generic, ex/
>
> class Franction():
>   def __add__(self, other):
>     return self.__classs__(self.denominator + other.denominator)
>
> That way if __add__ is called by an instance of a subclass it will
> return an instance of that subclass.

That was my first thought, because I had originally assumed that's the
way Fraction worked. However, a) it's easier to do the overriding in
my own class than patching Fraction (or at least no harder), and 2)
Fraction is only doing the same thing that int does, so it's hard to
justify a patch.

I think Patrick's solution might be the tidiest one. I'll give it a
shot (thanks, Patrick).
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[Patrick Maupin]

On Mar 13, 11:37 am, Jack Diederich  wrote:
> If Fraction.__add__ returns a new object but the subclass Value is
> compatible (as I would except since it is a sublcass) then just change
> all references in Franction.__add__ to be more generic, ex/
>
> class Franction():
>   def __add__(self, other):
>     return self.__classs__(self.denominator + other.denominator)
>
> That way if __add__ is called by an instance of a subclass it will
> return an instance of that subclass.
>

Yes, I think the OP understands that, and also understands that he
would have to do the same thing for __sub__, __div__, __rsub__,
__radd__, etc.

That's why I suggested that, instead of writing all that tedious code,
he could write code that writes the tedious code :-)

As Terence Parr of ANTLER fame asks:  "Why program by hand in five
days what you can spend five years of your life automating?"

Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[Jack Diederich]

On Sat, Mar 13, 2010 at 12:03 PM, JLundell  wrote:
> I've got a subclass of fractions.Fraction called Value; it's a mostly
> trivial class, except that it overrides __eq__ to mean 'nearly equal'.
> However, since Fraction's operations result in a Fraction, not a
> Value, I end up with stuff like this:
>
> x = Value(1) + Value(2)
>
> where x is now a Fraction, not a Value, and x == y uses
> Fraction.__eq__ rather than Value.__eq__.
>
> This appears to be standard Python behavior (int does the same thing).
> I've worked around it by overriding __add__, etc, with functions that
> invoke Fraction but coerce the result. But that's tedious; there are a
> lot of methods to override.
>
> So I'm wondering: is there a more efficient way to accomplish what I'm
> after?

If Fraction.__add__ returns a new object but the subclass Value is
compatible (as I would except since it is a sublcass) then just change
all references in Franction.__add__ to be more generic, ex/

class Franction():
  def __add__(self, other):
return self.__classs__(self.denominator + other.denominator)

That way if __add__ is called by an instance of a subclass it will
return an instance of that subclass.

-Jack
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: class inheritance

[Patrick Maupin]

On Mar 13, 11:03 am, JLundell  wrote:
> I've got a subclass of fractions.Fraction called Value; it's a mostly
> trivial class, except that it overrides __eq__ to mean 'nearly equal'.
> However, since Fraction's operations result in a Fraction, not a
> Value, I end up with stuff like this:
>
> x = Value(1) + Value(2)
>
> where x is now a Fraction, not a Value, and x == y uses
> Fraction.__eq__ rather than Value.__eq__.
>
> This appears to be standard Python behavior (int does the same thing).
> I've worked around it by overriding __add__, etc, with functions that
> invoke Fraction but coerce the result. But that's tedious; there are a
> lot of methods to override.
>
> So I'm wondering: is there a more efficient way to accomplish what I'm
> after?

7 years ago, I had a similar problem for a different and now obsolete
reason.  I'm sure my solution could be easily updated though.  I wrote
code to write a wrapper class.  Sort of a meta-module.  Original
reference here:

http://groups.google.com/group/comp.lang.python/browse_frm/thread/1253bbab7dfd4b/59289c16603fb374?hl=en&lnk=gst&q=pmaupin+userint#59289c16603fb374

HTH,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance - What am I doing wrong?

[Brian Munroe]

On Apr 24, 10:11 pm, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:

> In python, use attributes starting with a single underscore (such as
> _name).  It tells users that they shouldn't mess with them.  By
> design, python doesn't include mechanisms equivalent to the Java / C++
> 'private'.

Arnaud, Gabriel:

Ok, Ok, I'll trust my users to not abuse my API :)  I didn't realize
that 'private' meant 'private, even to sub-classes' - it is all
becoming clear to me now!

Thanks for the help, and I'm going to re-read 'Python is Not Java'
right about now (I've spent the past few months knee-deep in Java, I
guess I need to cleanse myself)
--
http://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance - What am I doing wrong?

[Bruno Desthuilliers]

Brian Munroe a écrit :

Ok, so thanks everyone for the helpful hints.  That *was* a typo on my
part (should've been super(B...) not super(A..), but I digress)

I'm building a public API.  Along with the API I have a few custom
types that I'm expecting API users to extend, if they need too.  If I
don't use name mangling, isn't that considered bad practice (read not
defensive programming) to not protect those 'private' fields?


There would be a lot to say about whether defensive programming is a 
good practice or not. At least in the context of hi-level languages with 
exception handling and automatic memory management.


Anyway:
- there's just no way to make anything truly "private" in Python
- the convention is that attributes (including methods - they are 
attributes too) whose name starts with a single leading underscore are 
implementation stuff and should not be messed with. IOW, the contract is 
"mess with them and you're on your own".
- name mangling is only useful when you really need to make sure an 
implementation attribute won't be *accidentally* shadowed. These 
attributes should only be used by methods that are not themselves 
supposed to be overridden or extended by user code. FWIW, I must have 
used them less than half a dozen times in 7+ years (and I wrote more 
than a couple mini-frameworks, with lot of black-juju metaclasses and 
custom descriptors magic in them).


So just use single-leading-underscore for implementation attributes, and 
document what the users are supposed to extend and what they're supposed 
to leave alone.


My 2 cents.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance - What am I doing wrong?

[Arnaud Delobelle]

Brian Munroe <[EMAIL PROTECTED]> writes:

> Ok, so thanks everyone for the helpful hints.  That *was* a typo on my
> part (should've been super(B...) not super(A..), but I digress)
>
> I'm building a public API.  Along with the API I have a few custom
> types that I'm expecting API users to extend, if they need too.  If I
> don't use name mangling, isn't that considered bad practice (read not
> defensive programming) to not protect those 'private' fields?

The problem is that you are using name mangling for an attribute which
is accessed by several generations of a class hierarchy.  Name
mangling is only useful for attributes you *don't* want to share with
subclasses (or bases).

In python, use attributes starting with a single underscore (such as
_name).  It tells users that they shouldn't mess with them.  By
design, python doesn't include mechanisms equivalent to the Java / C++
'private'.

-- 
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance - What am I doing wrong?

[Gabriel Genellina]

En Thu, 24 Apr 2008 18:18:01 -0300, Brian Munroe  
<[EMAIL PROTECTED]> escribió:



Ok, so thanks everyone for the helpful hints.  That *was* a typo on my
part (should've been super(B...) not super(A..), but I digress)

I'm building a public API.  Along with the API I have a few custom
types that I'm expecting API users to extend, if they need too.  If I
don't use name mangling, isn't that considered bad practice (read not
defensive programming) to not protect those 'private' fields?


Please read this article:  

You don't have to define any getXXX/setXXX methods, just use a public  
attribute (if it is supposed to be public, of course). In case you have to  
do something special with it (like notifying some observers when the value  
changes, by example) use a property instead, and use a *single* leading  
underscore in the protected attribute name. In any case, the client code  
remains the same: some_object.attribute_name = value


In Python, a single leading underscore means "this is an implementation  
detail, don't mess with it". This is a convention and we all -adult and  
responsible programmers- follow that convention. Double leading  
underscores are a means to avoid name conflicts with subclasses - don't  
use them unless you have a valid reason. Double leading and trailing  
underscores are __special__ names reserved by Python itself.


--
Gabriel Genellina

--
http://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance - What am I doing wrong?

[Brian Munroe]

Ok, so thanks everyone for the helpful hints.  That *was* a typo on my
part (should've been super(B...) not super(A..), but I digress)

I'm building a public API.  Along with the API I have a few custom
types that I'm expecting API users to extend, if they need too.  If I
don't use name mangling, isn't that considered bad practice (read not
defensive programming) to not protect those 'private' fields?
--
http://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance - What am I doing wrong?

[Gary Herron]

Brian Munroe wrote:

My example:

class A(object):

def __init__(self, name):
self.__name = name

def getName(self):
return self.__name

class B(A):

def __init__(self,name=None):
super(A,self).__init__()

def setName(self, name):
self.__name = name

if __name__ == '__main__':

a = A('class a')
print a.getName()

b = B('class b')
print b.getName()

b.setName('class b, reset')
print b.getName()

I get the following error:

mtinky:~ brian$ python teste.py
class a
Traceback (most recent call last):
  File "teste.py", line 23, in 
print b.getName()
  File "teste.py", line 7, in getName
return self.__name
AttributeError: 'B' object has no attribute '_A__name'

Am I *not* using super() correctly?  Also, did I define my the class B
constructor correctly?
--
http://mail.python.org/mailman/listinfo/python-list
  


Tell us what you are trying to do and what you expected to happen. 

If you are trying to do simple inheritance, you don't need the supers, 
and you should not invoke the name mangling implied by the double 
underscore.


If you *are* trying to use the name mangling, then you still don't need 
the super.



Gary Herron


--
http://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance - What am I doing wrong?

[Arnaud Delobelle]

Arnaud Delobelle <[EMAIL PROTECTED]> writes:

> That is, if you also pass the name parameter to super(A,self).__init__
> in B's __init__ method

Oops.  should be super(B, self).__init__(name), of course.

-- 
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance - What am I doing wrong?

[Arnaud Delobelle]

Brian Munroe <[EMAIL PROTECTED]> writes:

> My example:
>
> class A(object):
>
>   def __init__(self, name):
>   self.__name = name
>
>   def getName(self):
>   return self.__name
>
> class B(A):
>
>   def __init__(self,name=None):
>   super(A,self).__init__()
>
>   def setName(self, name):
>   self.__name = name
>
> if __name__ == '__main__':
>
>   a = A('class a')
>   print a.getName()
>
>   b = B('class b')
>   print b.getName()
>
>   b.setName('class b, reset')
>   print b.getName()
>
> I get the following error:
>
> mtinky:~ brian$ python teste.py
> class a
> Traceback (most recent call last):
>   File "teste.py", line 23, in 
> print b.getName()
>   File "teste.py", line 7, in getName
> return self.__name
> AttributeError: 'B' object has no attribute '_A__name'
>
> Am I *not* using super() correctly?  Also, did I define my the class B
> constructor correctly?

You have fallen victim to the Name Mangling Trap [1].  Replace the
leading double underscore in the __name attribute with a single one,
and Python shall calm down and let your code behave as you expect it
to.

That is, if you also pass the name parameter to super(A,self).__init__
in B's __init__ method

[1] http://docs.python.org/ref/atom-identifiers.html

-- 
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance - What am I doing wrong?

[Virgil Dupras]

On Apr 24, 10:22 pm, Brian Munroe <[EMAIL PROTECTED]> wrote:
> My example:
>
> class A(object):
>
>         def __init__(self, name):
>                 self.__name = name
>
>         def getName(self):
>                 return self.__name
>
> class B(A):
>
>         def __init__(self,name=None):
>                 super(A,self).__init__()
>
>         def setName(self, name):
>                 self.__name = name
>
> if __name__ == '__main__':
>
>         a = A('class a')
>         print a.getName()
>
>         b = B('class b')
>         print b.getName()
>
>         b.setName('class b, reset')
>         print b.getName()
>
> I get the following error:
>
> mtinky:~ brian$ python teste.py
> class a
> Traceback (most recent call last):
>   File "teste.py", line 23, in 
>     print b.getName()
>   File "teste.py", line 7, in getName
>     return self.__name
> AttributeError: 'B' object has no attribute '_A__name'
>
> Am I *not* using super() correctly?  Also, did I define my the class B
> constructor correctly?

Exactly, you used it wrong. It's super(B, self).

But before you start using super() everywhere, read this:

http://fuhm.net/super-harmful/

I love Python, but super() is one of those tricky things...
--
http://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance

[Bruno Desthuilliers]

Andrew Rekdal < a écrit :
> I am trying to bring functions to a class by inheritance... for instance in 
> layout_ext I have..
> 
> 
> --- layout_ext.py-
> class Layout()
> def...some function that rely on css in Layout.py

It shouldn't, definitively. The Layout instance should have a reference 
on the CSS instance, ie:

# layout_ext.py
class LayoutExt(object):
   def __init__(self, css):
 self.css = css

   def some_function(self):
  do_something_with(self.css)

# layout.py
from layout_ext import LayoutExt
from CSS import CSS

class Layout(LayoutExt):
def __init__(self, css):
LayoutExt.__init__(self, css)
# etc


> def...
> 
> ---EOF--
> 
> in the main application file I have...
> Layout.py---
> from layout_ext import Layout
> from CSS import CSS
> css = CSS()
> class Layout(Layout)

You will have a problem here - this class statement will shadow the 
Layout class imported from layout_ext. Remember that in Python, def and 
class statements are executed at runtime and that they bind names in 
current namespace - here, the 'class Layout' statement rebinds the name 
'Layout' in the Layout module's namespace.


> def __init__
> more code.
> 
> EOF
> 
> 
> Problem is layout_ext and Layout code is dependant on a Class instance 
> 'css'.  Whenever the CSS instance it parses a file, this means that I would
> have to parse the file twice?? Why is this? Can I do something like pass an 
> already created instance to the import?

Wrong solution, obviously. cf above for the most probably correct one.

HTH
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Class Inheritance

[Marc 'BlackJack' Rintsch]

On Thu, 13 Mar 2008 00:06:52 -0500, "Andrew Rekdal" < wrote:

> Problem is layout_ext and Layout code is dependant on a Class instance 
> 'css'.

Then pass that instance to the `Layout` class in the `__init__()` so both,
the base class and the subclass use the same `CSS` instance.

Ciao,
Marc 'BlackJack'
-- 
http://mail.python.org/mailman/listinfo/python-list