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
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
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 quite
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 current
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
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 the
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 of the
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 by just
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
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
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
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 an
object
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 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
14 matches
Mail list logo
