> >>I'm not sure I follow that bit.
>
> Say you have a master part, # 3245671, this is sort of a "primary machined
>number".
>
> On the blueprint for this part, there will be certain features that don't
> have
>any dimensional
>
> information, but instead have a callout of some kind, i
Elwin Estle wrote:
--- On Wed, 1/26/11, Alan Gauld wrote:
From: Alan Gauld
Subject: Re: [Tutor] class question
To: tutor@python.org
Date: Wednesday, January 26, 2011, 1:10 PM
Is this really a series of different types of casting or a single Workpiece
going through a sequence of Actions
each
--- On Wed, 1/26/11, Alan Gauld wrote:
From: Alan Gauld
Subject: Re: [Tutor] class question
To: tutor@python.org
Date: Wednesday, January 26, 2011, 1:10 PM
>>Is this really a series of different types of casting or a single Workpiece
>>going through a sequence of Actions
>>
"Elwin Estle" wrote
The class in question, does, in fact, deal with a thing.
The problem is, the "thing" is highly mutable.
You can mutate objects, that is not a problem.
But you need to be sure you need to.
Is this really a series of different types of casting or
a single Workpiece goin
"Karim" wrote
Sure, but I come from java world and 1 inheritance is allowed but we
can implement multiple interfaces.
I like to use Abstract classes in Python then inherit and implement
abstract method like in java (at least
Sure and that is the normal way of doing it. Not least because you
class Raw ---> class Processor ---> class Final
2011/1/26 Tino Dai
>
>
>>
>> A raw casting comes into a factory. It is listed as such. When machined,
>> this part number changes to a different part number. The raw casting has
>> no "quality related" stuff, but the machined casting does, and
>
>
> A raw casting comes into a factory. It is listed as such. When machined,
> this part number changes to a different part number. The raw casting has
> no "quality related" stuff, but the machined casting does, and it can have
> more than one "quality related" thing.
>
> ...because, the raw
Elwin Estle wrote:
> Is it better to have one large sort of "do it all" class, or break
> the larger class up into smaller classes?
Yes.
Or no.
It's impossible to answer that question definitively without knowing more about
what "it all" is. But I can give some general advice:
* Python isn't
I know the the law of Murphy.
But this one is a must-have.:-)
Regards
Karim
* One way to reduce coupling is with the Law of Demeter: if you want
your dog to walk, don't talk to your dog's legs. You will only confuse
the dog and it won't get anywhere.
http://en.wikipedia.org/wiki/Law_of_Deme
Sure, but I come from java world and 1 inheritance is allowed but we can
implement multiple interfaces.
I like to use Abstract classes in Python then inherit and implement
abstract method like in java (at least
that's all I remember from Java experience).
Indeed I was too direct everybody has
"Karim" wrote
Program towards interface that means you have to use inheritance.
Just to be picky, you can program by interface without using
inheritance. Inheritance is only needed to implement interfaces
in languages like C++. In Python (and other dynamically
bound OOP languages) you can
On 01/25/2011 08:50 PM, Steven D'Aprano wrote:
> Corey Richardson wrote:
>> On 01/25/2011 06:26 PM, Elwin Estle wrote:
>>> Is it better to have one large sort of "do it all" class, or break
>>> the larger class up into smaller classes?
>
>> If you're just learning, go ahead and make a 'do it all'
Corey Richardson wrote:
On 01/25/2011 06:26 PM, Elwin Estle wrote:
Is it better to have one large sort of "do it all" class, or break the larger
class up into smaller classes?
If you're just learning, go ahead and make a 'do it all' class. Don't do
it later in your growth as a programmer tho
Elwin Estle wrote:
Is it better to have one large sort of "do it all" class, or break
the larger class up into smaller classes?
Yes.
Or no.
It's impossible to answer that question definitively without knowing
more about what "it all" is. But I can give some general advice:
* Python isn't
Hello,
Design Patterns is the key for code reuse and problem solving. Indeed
you have to separate your objects (classes) to use
it. The god class is like a script with only one function: not very
flexible and easy to debug.
Program towards interface that means you have to use inheritance.
Try
"Elwin Estle" wrote
Is it better to have one large sort of "do it all" class,
or break the larger class up into smaller classes?
Usually the latter. But remember that classes model objects.
Objects usually have a direct relationship to some kind of
"real world" entity - even if its an abstr
On Tue, Jan 25, 2011 at 3:26 PM, Elwin Estle wrote:
>
> Is it better to have one large sort of "do it all" class, or break the larger
> class up into smaller classes? Seems to me like the one large class would be
> clearer in some ways. I have something I am trying to do that have somewhere
>
On 01/25/2011 06:26 PM, Elwin Estle wrote:
> Is it better to have one large sort of "do it all" class, or break the larger
> class up into smaller classes? Seems to me like the one large class would be
> clearer in some ways. I have something I am trying to do that have somewhere
> in the neig
Is it better to have one large sort of "do it all" class, or break the larger
class up into smaller classes? Seems to me like the one large class would be
clearer in some ways. I have something I am trying to do that have somewhere
in the neighborhood of 20 attributes that all relate together,
Ooops, didn't see Alan's post before I sent this...
JS
>> Your second way seems to make more sense. And instead of raising the
>> error, why not just print it:
>
> There is a very good reason for this and it's important that you
> understand
> it to write good code. If you use a print statement,
At 03:12 PM 7/13/2007, Alan Gauld wrote:
>"Dick Moores" <[EMAIL PROTECTED]> wrote
>
> > Thanks. You've clarified it for me completely.
> >
> > Your second way seems to make more sense.
> > And instead of raising the error, why not just print it:
>
>Because that would make the class much less reusa
> Your second way seems to make more sense. And instead of raising the
> error, why not just print it:
There is a very good reason for this and it's important that you understand
it to write good code. If you use a print statement, you break the benefit
of encapsulation.
If you were to use tha
"Dick Moores" <[EMAIL PROTECTED]> wrote
> Thanks. You've clarified it for me completely.
>
> Your second way seems to make more sense.
> And instead of raising the error, why not just print it:
Because that would make the class much less reusable.
It would be limited to applications using s
At 12:35 PM 7/13/2007, [EMAIL PROTECTED] wrote:
However if you try to withdraw
any money after you took out the $25 it would raise the error.
The overdrawn function checks if you are in the negatives.
Since the balance is checked before the money is taken out, there is no
error when you take ou
fax: 317.242.3469
e-mail: [EMAIL PROTECTED]
Dick Moores <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
07/13/2007 03:04 PM
To
Tiger12506 <[EMAIL PROTECTED]>,
cc
Subject
Re: [Tutor] class question
At 05:35 AM 7/13/2007, Tiger12506 wrote:
> > =
At 05:35 AM 7/13/2007, Tiger12506 wrote:
> > ===
> > class BankAccount(object):
> >def __init__(self, initial_balance=0):
> >self.balance = initial_balance
> >def deposit(self, amount):
> >self.balance += amount
> >def withdraw(self, a
> ===
> class BankAccount(object):
>def __init__(self, initial_balance=0):
>self.balance = initial_balance
>def deposit(self, amount):
>self.balance += amount
>def withdraw(self, amount):
>self.balance -= amount
>def overdr
on
http://wiki.python.org/moin/SimplePrograms I found this
code:
===
class BankAccount(object):
def __init__(self, initial_balance=0):
self.balance =
initial_balance
def deposit(self, amount):
self.balance += amount
def withdraw(sel
28 matches
Mail list logo
