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 scenario
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 langua
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 cre
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
- 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
>
>
> > cl
> 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")' ins
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
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 c
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 func
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
>
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 clas
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, o
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 appro
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
Valu
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
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
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.
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-poi
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 applica
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 coul
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.
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
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(ArithmeticSel
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
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 = Va
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):
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)
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 th
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 = V
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, G
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
d
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,
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
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, i
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(
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
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)._
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):
>
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 r
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,
Ma
40 matches
Mail list logo
