Fredrik Lundh a écrit :
Bruno Desthuilliers wrote:
Given the lack of proper support for the descriptor protocol in
old-style classes and a couple other diverging behaviors, I wouldn't
say that advising newcomers to use new-style classes is so pointless.
Yeah, but if you don't need descriptor
Bruno Desthuilliers wrote:
Given the lack of proper support for the descriptor protocol in
old-style classes and a couple other diverging behaviors, I wouldn't say
that advising newcomers to use new-style classes is so pointless.
Yeah, but if you don't need descriptors, new-style classes don'
Fredrik Lundh a écrit :
Bruno Desthuilliers wrote:
Unless you have a really good reason to use an antiquated and
deprecated object model, use "new-style" classes (for a value of "new"
being "now many years old"):
the distinction is gone in 3.0,
Yeps, but not in 2.5.2, which is still the cu
Bruno Desthuilliers wrote:
Unless you have a really good reason to use an antiquated and deprecated
object model, use "new-style" classes (for a value of "new" being "now
many years old"):
the distinction is gone in 3.0, so can we please stop flaming people for
violating a crap rule that's q
Craig Allen a écrit :
generally, I name the members in the Class definition and set them to
None there...
class Car:
Unless you have a really good reason to use an antiquated and deprecated
object model, use "new-style" classes (for a value of "new" being "now
many years old"):
class Car(o
En Thu, 21 Aug 2008 14:31:02 -0300, Craig Allen <[EMAIL PROTECTED]>
escribi�:
generally, I name the members in the Class definition and set them to
None there...
class Car:
speed = None
brand = None
def __init__():
self.speed = defaultspeed #alternately, and more commonly, get
Craig Allen:
> class Car:
>speed = None
>brand = None
>
>def __init__():
> self.speed = defaultspeed #alternately, and more commonly, get
> this speed as a initializer argument
> self.brand = defaultbrand
>
> That solves the issue of being able to "see" all the members of a
Craig Allen wrote:
> generally, I name the members in the Class definition and set them to
> None there...
>
> class Car:
>speed = None
>brand = None
>
>def __init__():
> self.speed = defaultspeed #alternately, and more commonly, get
> this speed as a initializer argument
>
generally, I name the members in the Class definition and set them to
None there...
class Car:
speed = None
brand = None
def __init__():
self.speed = defaultspeed #alternately, and more commonly, get
this speed as a initializer argument
self.brand = defaultbrand
That solves
Hussein B a écrit :
Hey,
Well, as you all know by now, I'm learning Python :)
One thing that is annoying my is the OOP in Python.
If so, the answer to your question is "obviously, no" !-)
Ok, let's see...
Consider this code in Java:
--
public class Car {
private int speed;
private String
On 21 Aug, 14:21, Hussein B <[EMAIL PROTECTED]> wrote:
> If you have a huge class, you can't figure the instance variables of
> each object.
> So, I created this constructor:
> --
> def __init__(self):
> self.speed = None
> self.brand = None
> --
> This way, I can figure the instance variables
Hussein B wrote:
> Hey,
> Well, as you all know by now, I'm learning Python :)
> One thing that is annoying my is the OOP in Python.
> Consider this code in Java:
> --
> public class Car {
> private int speed;
> private String brand;
> // setters & getters
> }
> --
> With one look at the top
Hussein B:
> class Car:
> def setspeed(self, speed):
> self.speed = speed
> def setbrand(self, brand):
> self.brand = brand
You can also learn the _attribute and __attribute conventions.
In Python getter/setters are used less often, you can remove those two
setters and just access th
Hey,
Well, as you all know by now, I'm learning Python :)
One thing that is annoying my is the OOP in Python.
Consider this code in Java:
--
public class Car {
private int speed;
private String brand;
// setters & getters
}
--
With one look at the top of the class, you can know that each
ins
14 matches
Mail list logo
