On Oct 30, 2007 5:52 AM, Fuzzyman <[EMAIL PROTECTED]> wrote:
> On Oct 29, 11:35 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > Fuzzyman wrote:
> > > On Oct 22, 6:43 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > >> # Inherit from object. There's no reason to create old-style classes.
> >
> >
On Oct 29, 11:35 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Fuzzyman wrote:
> > On Oct 22, 6:43 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
> >> # Inherit from object. There's no reason to create old-style classes.
>
> > We recently had to change an object pipeline from new style classes to
Fuzzyman <[EMAIL PROTECTED]> writes:
> We recently had to change an object pipeline from new style classes
> to old style. A lot of these objects were being created and the
> *extra overhead* of new style classes was killing us. :-)
Can you please expand on this? What extra overhead of new-style
Fuzzyman a écrit :
> On Oct 22, 6:43 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
(snip)
>> # Inherit from object. There's no reason to create old-style classes.
>
>
> We recently had to change an object pipeline from new style classes to
> old style. A lot of these objects were being created an
Fuzzyman wrote:
> On Oct 22, 6:43 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
>> # Inherit from object. There's no reason to create old-style classes.
>
> We recently had to change an object pipeline from new style classes to
> old style. A lot of these objects were being created and the *extra
On Oct 22, 6:43 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Sunburned Surveyor wrote:
> > Contents of input text file:
>
> > [Name]
> > Fire Breathing Dragon
>
> > [Properties]
> > Strength
> > Scariness
> > Endurance
>
> > [Methods]
> > eatMaiden argMaiden
> > fightKnight argKnight
>
> > Gener
Bruno Desthuilliers wrote:
> Now how does your desire for documentation imply that "if you're
> creating a class for the first time, it should *never* use property()" ?
Of course, there's *never* any such thing as "never" in Python. ;-)
STeVe
P.S. If you really don't understand what I was gett
Steven Bethard a écrit :
> Bruno Desthuilliers wrote:
>
>> Steven Bethard a écrit :
>>
>>> Bruno Desthuilliers wrote:
>>>
> I guess as long as your documentation is clear about which
> attributes require computation and which don't...
Why should it ?
>
> [snip]
>
>> I bel
Bruno Desthuilliers wrote:
> Steven Bethard a écrit :
>> Bruno Desthuilliers wrote:
I guess as long as your documentation is clear about which
attributes require computation and which don't...
>>>
>>> Why should it ?
[snip]
> I believe we simply disagree on weither properties should be u
Steven Bethard a écrit :
> Bruno Desthuilliers wrote:
>
>>> I guess as long as your documentation is clear about which attributes
>>> require computation and which don't...
>>
>>
>> Why should it ? FWIW, I mentionned that I would obviously not use
>> properties for values requiring heavy, non ca
Bruno Desthuilliers wrote:
>> I guess as long as your documentation is clear about which attributes
>> require computation and which don't...
>
> Why should it ? FWIW, I mentionned that I would obviously not use
> properties for values requiring heavy, non cachable computation. This
> set aside
Steven Bethard a écrit :
> Bruno Desthuilliers wrote:
>
>> Steven Bethard a écrit :
>>
>>> Bruno Desthuilliers wrote:
>>>
Steven Bethard a écrit :
(snip)
> In Python, you can use property() to make method calls look like
> attribute access. This could be necessary if you h
Bruno Desthuilliers wrote:
> Steven Bethard a écrit :
>> Bruno Desthuilliers wrote:
>>> Steven Bethard a écrit :
>>> (snip)
In Python, you can use property() to make method calls look like
attribute access. This could be necessary if you have an existing
API that used public attri
Marc 'BlackJack' Rintsch wrote:
> On Mon, 22 Oct 2007 17:31:51 -0600, Steven Bethard wrote:
>
>> Bruno Desthuilliers wrote:
>>> Computed attributes are IMHO not only a life-saver when it comes to
>>> refactoring. There are cases where you *really* have - by 'design' I'd
>>> say - the semantic of
Steven Bethard a écrit :
> Bruno Desthuilliers wrote:
>> Steven Bethard a écrit :
>> (snip)
>>> In Python, you can use property() to make method calls look like
>>> attribute access. This could be necessary if you have an existing
>>> API that used public attributes, but changes to your code req
On Mon, 22 Oct 2007 17:31:51 -0600, Steven Bethard wrote:
> Bruno Desthuilliers wrote:
>> Computed attributes are IMHO not only a life-saver when it comes to
>> refactoring. There are cases where you *really* have - by 'design' I'd
>> say - the semantic of a property, but know from the start you
Bruno Desthuilliers wrote:
> Steven Bethard a écrit :
> (snip)
>> In Python, you can use property() to make method calls look like
>> attribute access. This could be necessary if you have an existing API
>> that used public attributes, but changes to your code require those
>> attributes to do
On Oct 22, 11:44 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote:
> > You wrote: " can't think of a single reason why you would ever want to
> > do this,
> > since your "list of method and property names" would be just as
> > verbose as just typing the actual python code."
>
> > I don't think I un
On Oct 22, 1:23 pm, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> Steven Bethard a écrit :
> (snip)
>
> > In Python, you can use property() to make method calls look like
> > attribute access. This could be necessary if you have an existing API
> > that used public attributes, but changes to yo
Steven Bethard a écrit :
(snip)
> In Python, you can use property() to make method calls look like
> attribute access. This could be necessary if you have an existing API
> that used public attributes, but changes to your code require those
> attributes to do additional calculations now.
>
> B
Sunburned Surveyor a écrit :
> On Oct 22, 11:47 am, Bruno Desthuilliers
> <[EMAIL PROTECTED]> wrote:
(snip)
>
> Bruno wrote: "You don't need these getters and setters. Python has
> support for
> computed attributes (look for 'property'), so until you need to
> control
> access, a plain attribute
On Oct 22, 11:47 am, Bruno Desthuilliers
<[EMAIL PROTECTED]> wrote:
> Sunburned Surveyor a écrit :
>
> > On Oct 22, 10:26 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
>
> (snip)
> >>I can't think of a single reason why you would ever want to do this,
> >>since your "list of method and property nam
Sunburned Surveyor a écrit :
> On Oct 22, 10:26 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
>
(snip)
>>I can't think of a single reason why you would ever want to do this,
>>since your "list of method and property names" would be just as
>>verbose as just typing the actual python code.
>>
>>Auto
Sunburned Surveyor wrote:
> I also intended to add statements creating properties from the getter
> and setter methods. I understand that getters and setters aren't
> really necessary if you aren't making a property. I just forgot to add
> the property statements to my example.
You still don't wan
On Oct 22, 11:43 am, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Sunburned Surveyor wrote:
> > Contents of input text file:
>
> > [Name]
> > Fire Breathing Dragon
>
> > [Properties]
> > Strength
> > Scariness
> > Endurance
>
> > [Methods]
> > eatMaiden argMaiden
> > fightKnight argKnight
>
> > Gene
> You wrote: " can't think of a single reason why you would ever want to
> do this,
> since your "list of method and property names" would be just as
> verbose as just typing the actual python code."
>
> I don't think I understand how this would be the same amount of
> typing. Consider the followi
Sunburned Surveyor wrote:
> Contents of input text file:
>
> [Name]
> Fire Breathing Dragon
>
> [Properties]
> Strength
> Scariness
> Endurance
>
> [Methods]
> eatMaiden argMaiden
> fightKnight argKnight
>
> Generated Python Class File:
>
> def class FireBreathingDragon:
>
>def getStrengt
On Oct 22, 11:23 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> On 10/22/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > On Oct 22, 10:26 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> > > On 10/22/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
>
> > > > I was thinking of a way
On Mon, 22 Oct 2007 11:05:52 -0700, Sunburned Surveyor wrote:
> On Oct 22, 10:26 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
>
> You wrote: " can't think of a single reason why you would ever want to
> do this,
> since your "list of method and property names" would be just as
> verbose as just t
On 10/22/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> On Oct 22, 10:26 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> > On 10/22/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> >
> > > I was thinking of a way I could make writing Python Class Files a
> > > little less pa
Sunburned Surveyor a écrit :
> I was thinking of a way I could make writing Python Class Files
What's a "Python Class File" ?
> a
> little less painful.
If you find writing classes in Python "painful", then either you have no
experience with any mainstream language or you are doing something wr
On Oct 22, 10:26 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
> On 10/22/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > I was thinking of a way I could make writing Python Class Files a
> > little less painful. I was considering a Ptyhon script that read a
> > file with a list of
On 10/22/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> I was thinking of a way I could make writing Python Class Files a
> little less painful. I was considering a Ptyhon script that read a
> file with a list of property names and method names and then generated
> a skeleton class file.
>
> I
33 matches
Mail list logo
