The debate got more interesting than I expected. Without taking sides, I would
like to add that perhaps my "length" example was misleading: length is easy to
calculate. The information could be hard to extract from the data, either
because complex calculations are involved, or because it is not
On Sun, Aug 18, 2013 at 12:40 AM, Steven D'Aprano
wrote:
> The Law of Demeter is really about being careful about what interface
> your classes provide. Customers should provide a get_payment method; dogs
> should provide a walk method. You shouldn't have to send individual step
> messages to the
On Sun, 18 Aug 2013 00:52:06 +0200, Irmen de Jong wrote:
> On 17-8-2013 19:18, Steven D'Aprano wrote:
[...]
>> How is this:
>>
>> obj.data_length()
>>
>> easier for the user than this?
>>
>> len(obj.data)
>>
>>
> It's not easier for the user perse, but it might be preferable from a
> design p
On 17-8-2013 19:18, Steven D'Aprano wrote:
> On Sat, 17 Aug 2013 09:53:07 -0700, Fernando Saldanha wrote:
>
>> Suppose my class contains an attribute called "data" that can
>> potentially provide a lot of information that will be needed by class
>> users. I have two options:
>>
>> 1) For each piec
On 2013-08-17 17:18, Steven D'Aprano wrote:
> # Yes, this is good, consistent design
> len(myrecord.field)
> len(obj.data)
> len(data.value)
> len(collection[key])
I would also add that, if the primary goal of your class is to
encapsulate the data, you can do
class MyClass:
def __init__(sel
On Sat, 17 Aug 2013 09:53:07 -0700, Fernando Saldanha wrote:
> Suppose my class contains an attribute called "data" that can
> potentially provide a lot of information that will be needed by class
> users. I have two options:
>
> 1) For each piece of information within data (e.g., length) I write
On 17/08/2013 17:53, Fernando Saldanha wrote:
I am new to Python.
I understand that it is "unpythonic" to write getters and setters, and that
property() can be used if necessary.
This deals with the case of attributes, but there are other kinds of
information available within a class.
Suppos
I am new to Python.
I understand that it is "unpythonic" to write getters and setters, and that
property() can be used if necessary.
This deals with the case of attributes, but there are other kinds of
information available within a class.
Suppose my class contains an attribute called "data" t
Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
> Which puts us to the next question: the sealing itself doesn't do
> anything to restrict the code, the SecurityManager does. Which AFAIK is
> something hooked into the VM. Now, I'm not on sure grounds here on how
> to altere its behaviour, but I'd sa
Ed Jensen schrieb:
> Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>>> Java is not an acronym. That is: it's "Java", not "JAVA".
>> Now THAT was an important information RIGHT on topic.
>
> It was not meant offensively.
Ok.
>>> Java does not allow access to private members via reflection.
>> For
Ed Jensen wrote:
> Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
> > Ah, you mean like in JAVA
>
> Java is not an acronym. That is: it's "Java", not "JAVA".
>
> > where the compiler prevents you from accessing
> > private variables, but the runtime allows access to these very variables
> > via refl
Ant a écrit :
> Came across this article this afternoon - thought it may be of interest
> to some of those following this thread...
>
> http://www.devx.com/opensource/Article/31593/0/page/2
>
Yeah. Presenting name mangling as the usual way to have 'private'
attributes, then implementing (costly)
Dennis Lee Bieber a écrit :
> On Thu, 20 Jul 2006 12:52:52 +0200, Bruno Desthuilliers
> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>
>
>>Granted. Actually, it *was* a typo - but it happened to also make sens,
>>so I decided it was not a typo !-)
>>
>
> Ah... One of th
Gerhard Fiedler a écrit :
> On 2006-07-20 09:40:31, Bruno Desthuilliers wrote:
>
>
>>>I'm not sure, but there's one thing that has a potential to be the real
>>>issue: what's the common way to create a property that is read-write
>>>for the implementation and "read-only" for the interface?
>>
>>
Diez B. Roggisch a écrit :
>> You mean:
>>
>> class Pythonic(object):
>> def __init__(self):
>> self._is_active = True
>>
>> @apply
>> def is_active():
>> def fget(self): return self._is_active
>> def fset(self): raise SomeException('sorry, read-only')
>> return
Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>> Java is not an acronym. That is: it's "Java", not "JAVA".
>
> Now THAT was an important information RIGHT on topic.
It was not meant offensively.
>> Java does not allow access to private members via reflection.
>
> For somebody nitpicking on natur
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
>
> >>point 2 : so anyone *can* "illegimately tampering with an object's
> >>internal data" at will.
> >>
> >
> >And this is robust how?
> >
>
> You can do just the same in Java or C++.
>
On 2006-07-20 09:40:31, Bruno Desthuilliers wrote:
>> I'm not sure, but there's one thing that has a potential to be the real
>> issue: what's the common way to create a property that is read-write
>> for the implementation and "read-only" for the interface?
>
> class Foo(object):
> @apply
>
Came across this article this afternoon - thought it may be of interest
to some of those following this thread...
http://www.devx.com/opensource/Article/31593/0/page/2
--
http://mail.python.org/mailman/listinfo/python-list
mystilleef wrote:
> Bruno Desthuilliers wrote:
>>point 2 : so anyone *can* "illegimately tampering with an object's
>>internal data" at will.
>>
>
>And this is robust how?
>
You can do just the same in Java or C++.
>>>
>>>
>>>OMG!
>>
>>It's common knowledge.
>
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
> >
> (snip)
> >You use accessors when you need to control access to a data attribute.
>
> Indeed. And when you don't need too ? (the second 'o' is not a typo)
>
> >>>
> >>>
> >>>You make the attribute
> You mean:
>
> class Pythonic(object):
> def __init__(self):
> self._is_active = True
>
> @apply
> def is_active():
> def fget(self): return self._is_active
> def fset(self): raise SomeException('sorry, read-only')
> return property(**locals())
Neat! That sli
mystilleef wrote:
> Bruno Desthuilliers wrote:
>
(snip)
>You use accessors when you need to control access to a data attribute.
Indeed. And when you don't need too ? (the second 'o' is not a typo)
>>>
>>>
>>>You make the attribute private/protected.
>>
>>doh :(
>>
>>Let's talk ab
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
> >
> >>mystilleef wrote:
> >>
> >>>Bruno Desthuilliers wrote:
> >>>
> >>>
> mystilleef wrote:
> >>
> >>(snip)
> >>
> >>>Of course using setters for the sake of just using them is pointless.
> >>
> >>Inde
Gerhard Fiedler wrote:
(snip)
>
> I'm not sure, but there's one thing that has a potential to be the real
> issue: what's the common way to create a property that is read-write for
> the implementation and "read-only" for the interface?
class Foo(object):
@apply
def _imp():
def fget(self
mystilleef wrote:
(snip)
>
> __monitor_event is not supposed to be a write accessor. My point was
> show how you can change the state of an object internally without
> needing external access to it. Since some people are surprisingly
> claiming it is not possible.
I failed to see anyone making su
> Lol. I actually did *un*learn the hard way.
>
> Mystilleef, I've started programing 17 years ago, and have done it
> professionnaly for almost 10 years now. I do not pretend to be a good
> programmer, but please believe that I do know my job. I've read the Book
> too, I've tried applying it blin
Gerhard Fiedler wrote:
> On 2006-07-20 04:15:33, Steve Holden wrote:
>
>
>>mystilleef wrote:
>>[...]
>>
>>>I don't know it's your code not mine.
>>>
>>>class Robust(object):
>>>
>>> def __init__(self):
>>> # Arbitrarily changing this state to False will crash app or
>>> will
>>>
On 2006-07-20 04:15:33, Steve Holden wrote:
> mystilleef wrote:
> [...]
>>
>> I don't know it's your code not mine.
>>
>> class Robust(object):
>>
>> def __init__(self):
>> # Arbitrarily changing this state to False will crash app or
>> will
>> # corrupt the whol
Dennis Lee Bieber wrote:
> On Wed, 19 Jul 2006 18:54:55 +0200, Bruno Desthuilliers
> <[EMAIL PROTECTED]> declaimed the following in comp.lang.python:
>
>
>>Indeed. And when you don't need too ? (the second 'o' is not a typo)
>>
>
> Pardon, but for the sense you intend, it should be:
>
>
mystilleef wrote:
> Bruno Desthuilliers wrote:
>
>>mystilleef wrote:
>>
>>>Bruno Desthuilliers wrote:
>>>
>>>
mystilleef wrote:
>>
>>(snip)
>>
>>>Of course using setters for the sake of just using them is pointless.
>>
>>Indeed.
>>
>>
>>
>>
>>>The reason to use
Steve Holden wrote:
> mystilleef wrote:
> [...]
> >
> > I don't know it's your code not mine.
> >
> > class Robust(object):
> >
> > def __init__(self):
> > # Arbitrarily changing this state to False will crash app or
> > will
> > # corrupt the whole event system.
> >
mystilleef wrote:
[...]
>
> I don't know it's your code not mine.
>
> class Robust(object):
>
> def __init__(self):
> # Arbitrarily changing this state to False will crash app or
> will
> # corrupt the whole event system.
> self.__is_active = True
Dennis Lee Bieber wrote:
> On 19 Jul 2006 22:38:17 -0700, "mystilleef" <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>
>>permitted should be between an object and its mediator. Messages are
>>passed through the system via signals or events or established
>>protocols. What a
In <[EMAIL PROTECTED]>, mystilleef
wrote:
>
> Bruno Desthuilliers wrote:
>> mystilleef wrote:
>> > Bruno Desthuilliers wrote:
>> >
>> > Because you don't want third parties illegimately tampering with an
>> > object's internal data and thus crashing your system?
>>
>> Let's try again...
>>
>> poi
Steve Holden wrote:
> mystilleef wrote, making me somewhat tired of his/her repeated inability
> to get what's being said [sigh]:
> > Bruno Desthuilliers wrote:
> >>mystilleef wrote:
> >>>Bruno Desthuilliers wrote:
> mystilleef wrote:
> >Gerhard Fiedler wrote:
> >>On 2006-07-15 06:55:1
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
> >
> >>mystilleef wrote:
> (snip)
> >
> >Of course using setters for the sake of just using them is pointless.
>
> Indeed.
>
>
>
> >The reason to use them is if pre-conditions or post
Bruno Desthuilliers wrote:
> ZeD wrote:
> > Bruno Desthuilliers wrote:
> >
> >
> >>>I decided to change the name of an attribute. Problem is I've used the
> >>>attribute in several places spanning thousands of lines of code. If I
> >>>had encapsulated the attribute via an accessor, I wouldn't need
Ed Jensen schrieb:
> Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
>> Ah, you mean like in JAVA
>
> Java is not an acronym. That is: it's "Java", not "JAVA".
Now THAT was an important information RIGHT on topic.
>> where the compiler prevents you from accessing
>> private variables, but the runti
Tobias Brox a écrit :
> [Jason]
>
>>Nothing like being forced to write getters and setters in C++/Java
>>before you feel like shooting your source code. Please don't bring
>>this code-rage into Python.
>
>
> "Code generation" springs into my mind. IMO, if the code needs to be
> generated, the
Ed Jensen wrote:
> > where the compiler prevents you from accessing
> > private variables, but the runtime allows access to these very variables
> > via reflection?
>
> Java does not allow access to private members via reflection.
Yes it does. You can call setAccessible(true) on the Method objec
On 2006-07-19 14:12:33, Tobias Brox wrote:
> "Code generation" springs into my mind. IMO, if the code needs to be
> generated, the language is not sufficiently advanced.
Isn't that just a question of level? I'm sure there are editors that
generate Python class stubs, GUI builders that generate P
mystilleef wrote:
> Bruno Desthuilliers wrote:
>
>>mystilleef wrote:
>>
(snip)
>For example, a third party randomly changing
>is_active, (which Python lets you do freely and easily)
Unless you make it a read-only property.
>>>
>>>So you see the purpose of accessors then?
>>
[Jason]
> Nothing like being forced to write getters and setters in C++/Java
> before you feel like shooting your source code. Please don't bring
> this code-rage into Python.
"Code generation" springs into my mind. IMO, if the code needs to be
generated, the language is not sufficiently advance
[ZeD]
> you mean sed :)
> sed 's/oldName/newName/g' oldFile > newFile
I used to be a Perl programmer :-)
perl -i.bak -pe 's/oldName/newName/g' *
As said, this is risky as oldName can be used in other contexts.
--
Tobias Brox, 69°42'N, 18°57'E
--
http://mail.python.org/mailman/listinfo/pyth
mystilleef wrote:
> Bruno Desthuilliers wrote:
>
>>mystilleef wrote:
(snip)
>
>Of course using setters for the sake of just using them is pointless.
Indeed.
>The reason to use them is if pre-conditions or post-conditions need to
>be met. Or to control access
Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
> Ah, you mean like in JAVA
Java is not an acronym. That is: it's "Java", not "JAVA".
> where the compiler prevents you from accessing
> private variables, but the runtime allows access to these very variables
> via reflection?
Java does not allow ac
>> What I'm saying here is that it's totally useless to duplicate default
>> behaviour.
>>
>
> And who's doing that?
Somebody who uses setters that only set a property?
Diez
--
http://mail.python.org/mailman/listinfo/python-list
>> Then why do you advise "(making) all attributes of a class
>> private/protected" and systematically using properties ?
>>
>
> Because you don't want third parties illegimately tampering with an
> object's internal data and thus crashing your system?
Ah, you mean like in JAVA where the compiler
mystilleef wrote, making me somewhat tired of his/her repeated inability
to get what's being said [sigh]:
> Bruno Desthuilliers wrote:
>>mystilleef wrote:
>>>Bruno Desthuilliers wrote:
mystilleef wrote:
>Gerhard Fiedler wrote:
>>On 2006-07-15 06:55:14, mystilleef wrote:
>>>In very
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
> >
> >>mystilleef wrote:
> >>Please don't top-post
> >>
> >>>On State and Behavior:
> >>>
> >>>To understand objects in terms of state and behavior you need to
> >>>absolve yourself from implementation details of langua
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
> >
> >>mystilleef wrote:
> >>
> >>>Gerhard Fiedler wrote:
> >>>
> >>>
> On 2006-07-15 06:55:14, mystilleef wrote:
>
>
>
> >In very well designed systems, the state of an object should only be
> >>
mystilleef wrote:
> Bruno Desthuilliers wrote:
>
>>mystilleef wrote:
>>Please don't top-post
>>
>>>On State and Behavior:
>>>
>>>To understand objects in terms of state and behavior you need to
>>>absolve yourself from implementation details of languages
>>>and think at an abstract level.
>>
>>
>>
mystilleef wrote:
> Bruno Desthuilliers wrote:
>
>>mystilleef wrote:
>>
>>>Gerhard Fiedler wrote:
>>>
>>>
On 2006-07-15 06:55:14, mystilleef wrote:
>In very well designed systems, the state of an object should only be
>changed by the object.
IMO that's not quite
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Gerhard Fiedler wrote:
> >
> >>On 2006-07-15 06:55:14, mystilleef wrote:
> >>
> >>
> >>>In very well designed systems, the state of an object should only be
> >>>changed by the object.
> >>
> >>IMO that's not quite true. Ultimately, the state alwa
Bruno Desthuilliers wrote:
> mystilleef wrote:
> Please don't top-post
> > On State and Behavior:
> >
> > To understand objects in terms of state and behavior you need to
> > absolve yourself from implementation details of languages
> > and think at an abstract level.
>
>
>
> > Take a button objec
Bruno Desthuilliers wrote:
> mystilleef wrote:
(snip)
>>Here are the lessons I've learned (the hard way).
>>
>>1) Make all attributes of a class private or protected.
>
>
> Unless they are obviously part of the implementation
s/implementation/interface/, of course.
> (ie: when you would
> def
mystilleef wrote:
> Gerhard Fiedler wrote:
>
>>On 2006-07-15 06:55:14, mystilleef wrote:
>>
>>
>>>In very well designed systems, the state of an object should only be
>>>changed by the object.
>>
>>IMO that's not quite true. Ultimately, the state always gets changed by
>>something else (user inter
mystilleef wrote:
Please don't top-post
> On State and Behavior:
>
> To understand objects in terms of state and behavior you need to
> absolve yourself from implementation details of languages
> and think at an abstract level.
> Take a button object, for example. It has state and behavior. Pos
On 2006-07-15 19:46:16, Ben C wrote:
> There isn't any practical difference, as you say, if all the setter does
> is set. But it might easily do a few other subtle things, in particular
> wait for a good moment to actually effect the change.
I agree. But even then, for me there's no practical dif
On 2006-07-15, Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
> On 2006-07-15 06:55:14, mystilleef wrote:
>
>> In very well designed systems, the state of an object should only be
>> changed by the object.
>
> IMO that's not quite true. Ultimately, the state always gets changed by
> something else (us
On 2006-07-15 12:04:20, mystilleef wrote:
> State - behavior is not something I made up, so it isn't subjective. It
> is a common term used in OO literature. In fact, the only reason I used
> it is because I thought is was common knowledge.
Of course. But your association of state with attribute
Gerhard Fiedler wrote:
> On 2006-07-15 06:55:14, mystilleef wrote:
>
> > In very well designed systems, the state of an object should only be
> > changed by the object.
>
> IMO that's not quite true. Ultimately, the state always gets changed by
> something else (user interaction, physical events);
On 2006-07-15 06:55:14, mystilleef wrote:
> In very well designed systems, the state of an object should only be
> changed by the object.
IMO that's not quite true. Ultimately, the state always gets changed by
something else (user interaction, physical events); very few objects are
completely se
On State and Behavior:
To understand objects in terms of state and behavior you need to
absolve yourself from implementation details of languages and think at
an abstract level.
Take a button object, for example. It has state and behavior. Possible
states may include, is_active, is_focused, is_ma
mystilleef ha scritto:
> Methods are used to perform actions. Data attributes usually aren't. We
> are on different planes.
You aren't thinking pythonic. You should not make any difference
between accessing an attribute and accessing a function. They both just
need to receive the right data to p
mystilleef wrote:
> Marc 'BlackJack' Rintsch wrote:
>
>>In <[EMAIL PROTECTED]>, mystilleef
>>wrote:
>>
>>
>>>Maric Michaud wrote:
>>>
But that's not python philosophy.
>>>
>>>Python doesn't have any philosophy with regards to naming identifiers.
>>
>>But the python community has one. Pythonis
mystilleef wrote:
> Fredrik Lundh wrote:
> > "mystilleef" wrote:
> >
> > > Pretending to be intelligent does, however.
> >
> > so the real reason you've written a few hundred posts saying basically "I
> > pick
> > bad names, which proves... uh... whatever" is to impress people by
> > pretending
mystilleef wrote:
(snip)
>
> Okay, I feel I need to make myself clear. I certainly I'm not blaming
> Python for my mistakes. And I don't think language X is better than
> Python or vice-versa. Okay scrap the vice-versa. It was silly of me to
> name the variable tmp regardless of whatever excuses I
Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
> On 2006-07-13 01:50:18, Alex Martelli wrote:
>
> >> I'm not sure about which languages you are talking (pretty much all that
> >> allow public methods also allow public attributes), [...]
> >
> > Smalltalk is a very well known object-oriented language
mystilleef wrote:
> Ant wrote:
>
>>We seem to be flogging a dead horse now. Is the following a fair
>>summary:
>>
>>Q. What is the Pythonic way of implementing getters and setters?
>>
>>A. Use attributes.
>>
>>Quote: "I put a lot more effort into choosing method and function
>>names"
>>
>>Wisdom:
mystilleef wrote:
> Bruno Desthuilliers wrote:
>
You choose a bad name for a *public* symbol.
>>>
>>>
>>>My point exactly! It doesn't solve my problem!
>>
>>What do you hope ? Something that cures cancer ? Please enlighten us and
>>explain how explicit getters/setters would have solved the pro
mystilleef schreef:
> Ant wrote:
>> We seem to be flogging a dead horse now. Is the following a fair
>> summary:
>>
>> Q. What is the Pythonic way of implementing getters and setters?
>>
>> A. Use attributes.
>>
>> Quote: "I put a lot more effort into choosing method and function
>> names"
>>
>> Wi
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
> >
> >>mystilleef wrote:
> >>
> (snip)
>
> >I have used that name in
> >dozens of places spanning over 27000 LOC.
>
> Too bad for you.
> >>>
> >>>
> >>>Thank you, that was helpful.
> >>
> >>What am
On 2006-07-13 01:50:18, Alex Martelli wrote:
>> I'm not sure about which languages you are talking (pretty much all that
>> allow public methods also allow public attributes), [...]
>
> Smalltalk is a very well known object-oriented language that behaves
> otherwise, just as one example.
I didn'
On 2006-07-13 06:03:40, Bruno Desthuilliers wrote:
>> [...] the underscore way to mark private entities. Maybe this doesn't
>> work as I think it does
>
> If you think that single leading underscores have a special meaning for
> the compiler/interpreter, then you got it wrong. It's a convention.
On 7/13/06, Simon Brunning <[EMAIL PROTECTED]> wrote:
> Something like this any use to you?
Or this, about a squillion times cleaner:
class MyClass(object):
def _get_bad_name(self):
warn('"bad_name" deprecated. Please refer to "good_name"', stacklevel=2)
return self.good_name
mystilleef wrote:
> Bruno Desthuilliers wrote:
>
>>mystilleef wrote:
>>
(snip)
>I have used that name in
>dozens of places spanning over 27000 LOC.
Too bad for you.
>>>
>>>
>>>Thank you, that was helpful.
>>
>>What am I supposed to say ? You choose a bad name for a public sym
On 2006-07-13, mystilleef <[EMAIL PROTECTED]> wrote:
>
>> What do you hope ? Something that cures cancer ? Please enlighten us and
>> explain how explicit getters/setters would have solved the problem of
>> badly named getters/setters ?
>>
> I did already. If I had used Java, Eiffel, Smalltalk or C
On 10 Jul 2006 05:51:02 -0700, mystilleef <[EMAIL PROTECTED]> wrote:
> I decided to change the name of an attribute. Problem is I've used the
> attribute in several places spanning thousands of lines of code. If I
> had encapsulated the attribute via an accessor, I wouldn't need to do
> an unreliab
Ant wrote:
> We seem to be flogging a dead horse now. Is the following a fair
> summary:
>
> Q. What is the Pythonic way of implementing getters and setters?
>
> A. Use attributes.
>
> Quote: "I put a lot more effort into choosing method and function
> names"
>
> Wisdom: Python is a different para
We seem to be flogging a dead horse now. Is the following a fair
summary:
Q. What is the Pythonic way of implementing getters and setters?
A. Use attributes.
Quote: "I put a lot more effort into choosing method and function
names"
Wisdom: Python is a different paradigm from (e.g.) Java w.r.t.
a
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
> >
> >>mystilleef wrote:
> >>(snip)
> >>
> >>>Python doesn't have any philosophy with regards to naming identifiers.
> >>
> >>Yes it does.
> >
> >
> > No it doesn't.
> >
> >
> But they are in Python and that is the
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Bruno Desthuilliers wrote:
> >
> >>mystilleef wrote:
> >>
> >>>Lousy Attribute Name:
> >>> self.tmp
> >>>
> >>>Accessors:
> >>> set_temporary_buffer
> >>> get_temporary_buffer
> >>>
> >>>The attribute name I chose, "tmp" sucks.
> >>
> >>Well
mystilleef wrote:
> Bruno Desthuilliers wrote:
>
>>mystilleef wrote:
>>(snip)
>>
>>>Python doesn't have any philosophy with regards to naming identifiers.
>>
>>Yes it does.
>
>
> No it doesn't.
>
>
But they are in Python and that is the python's philosophy. All attribute or
method not
Fredrik Lundh wrote:
> "mystilleef" wrote:
>
> > Pretending to be intelligent does, however.
>
> so the real reason you've written a few hundred posts saying basically "I pick
> bad names, which proves... uh... whatever" is to impress people by pretending
> to be something you're not ?
>
>
Choos
mystilleef wrote:
> Bruno Desthuilliers wrote:
>
>>mystilleef wrote:
>>
>>>Marc 'BlackJack' Rintsch wrote:
>>>
>>>
In <[EMAIL PROTECTED]>, mystilleef
wrote:
>Maric Michaud wrote:
>>
>>(snip)
>>
>>
>>But they are in Python and that is the python's philosophy. All attr
mystilleef wrote:
> Bruno Desthuilliers wrote:
>
>>mystilleef wrote:
>>
>>>Lousy Attribute Name:
>>> self.tmp
>>>
>>>Accessors:
>>> set_temporary_buffer
>>> get_temporary_buffer
>>>
>>>The attribute name I chose, "tmp" sucks.
>>
>>Well, it's surely not as descriptive as 'temporary_buff
"mystilleef" wrote:
> Pretending to be intelligent does, however.
so the real reason you've written a few hundred posts saying basically "I pick
bad names, which proves... uh... whatever" is to impress people by pretending
to be something you're not ?
--
http://mail.python.org/mailman/list
Fredrik Lundh wrote:
> "mystilleef" wrote:
>
> >> if your code is as muddled as your rhetorics, your only solution might be
> >> to give up programming.
> >
> > There's no correlation between rhetorics and programming. That's like
> > me saying if you are trying to be sarcastic your only solution
"mystilleef" wrote:
>> if your code is as muddled as your rhetorics, your only solution might be
>> to give up programming.
>
> There's no correlation between rhetorics and programming. That's like
> me saying if you are trying to be sarcastic your only solution might be
> to give up programming.
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Marc 'BlackJack' Rintsch wrote:
> >
> >>In <[EMAIL PROTECTED]>, mystilleef
> >>wrote:
> >>
> >>
> >>>Maric Michaud wrote:
> (snip)
>
> But they are in Python and that is the python's philosophy. All attribute
> or
> method not beginni
mystilleef wrote:
> Marc 'BlackJack' Rintsch wrote:
>
>>In <[EMAIL PROTECTED]>, mystilleef
>>wrote:
>>
>>
>>>Maric Michaud wrote:
(snip)
But they are in Python and that is the python's philosophy. All attribute or
method not beginning with an '_' *is* API.
>>>
>>>Right, and what if I want
Fredrik Lundh wrote:
> "mystilleef" wrote:
>
> > Right, and what if I want to change a private API to a public one. How
> > does that solve my naming issues.
>
> if your code is as muddled as your rhetorics, your only solution might be
> to give up programming.
>
>
There's no correlation between
Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, mystilleef
> wrote:
>
>
>>Maric Michaud wrote:
>>
(snip)
>>>But they are in Python and that is the python's philosophy. All attribute or
>>>method not beginning with an '_' *is* API.
>>
>>Right, and what if I want to change a private API t
Bruno Desthuilliers wrote:
> mystilleef wrote:
> (snip)
> > Python doesn't have any philosophy with regards to naming identifiers.
>
> Yes it does.
No it doesn't.
> >
> >>But they are in Python and that is the python's philosophy. All attribute or
> >>method not beginning with an '_' *is* API.
>
Gerhard Fiedler wrote:
> On 2006-07-12 06:17:27, mystilleef wrote:
>
>
>>But developers tend to pay more attention to given methods/functions
>>less crappy names, at least when compared to data attributes. This
>>stems from the fact that in many languages data attributes aren't
>>usually part of
"mystilleef" wrote:
> Right, and what if I want to change a private API to a public one. How
> does that solve my naming issues.
if your code is as muddled as your rhetorics, your only solution might be
to give up programming.
--
http://mail.python.org/mailman/listinfo/python-list
Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, mystilleef
> wrote:
>
> > Maric Michaud wrote:
> >> But that's not python philosophy.
> > Python doesn't have any philosophy with regards to naming identifiers.
>
> But the python community has one. Pythonistas prefer readable source code
Bruno Desthuilliers wrote:
> mystilleef wrote:
> > Lousy Attribute Name:
> > self.tmp
> >
> > Accessors:
> > set_temporary_buffer
> > get_temporary_buffer
> >
> > The attribute name I chose, "tmp" sucks.
>
> Well, it's surely not as descriptive as 'temporary_buffer'
>
> > I have used t
1 - 100 of 121 matches
Mail list logo
