Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Does Python really follow its philosophy of "Readability counts"?

Reply
Thread Tools

Does Python really follow its philosophy of "Readability counts"?

 
 
Roy Smith
Guest
Posts: n/a
 
      01-12-2009
In article
<(E-Mail Removed)>,
"Madhusudan.C.S" <(E-Mail Removed)> wrote:

> In such situations, where the Instance variables come into existence
> only when they are used it is very difficult to track the flow of code.


As the saying goes, "It's possible to write Fortran in any language".

My personal habit is to "declare" all instance variables in the __init__()
method of every class. If there's no better value, I set them to None.
This isn't strictly required, but I think it makes it easier for somebody
reading the code to understand the class.

I'm not a big fan of dogmatic rules, other than the rule that says you
should make your code as easy for somebody else to understand as possible.
 
Reply With Quote
 
 
 
 
Carl Banks
Guest
Posts: n/a
 
      01-12-2009
On Jan 11, 5:49*pm, Chris Rebert <(E-Mail Removed)> wrote:
> On Sun, Jan 11, 2009 at 3:15 PM, Carl Banks <(E-Mail Removed)> wrote:
> > On Jan 11, 3:31 pm, Chris Rebert <(E-Mail Removed)> wrote:
> >> On Sun, Jan 11, 2009 at 1:22 PM, Madhusudan.C.S <(E-Mail Removed)> wrote:
> >> > * *def somemethod(self, arg1):
> >> > * * * *self.c = 20.22
> >> > * * * *d = "some local variable"
> >> > * * * *# do something
> >> > * * * *....
> >> > * *...
> >> > * *def somemethod2 (self, arg2):
> >> > * * * *self.c = "Changed the variable"
> >> > * * * *# do something 2
> >> > * * * *...

>
> >> > In such situations, where the Instance variables come into existence
> >> > only when they are used
> >> > it is very difficult to track the flow of code. Its obviously not
> >> > possible to remember what
> >> > instance variable was defined where, when reading some substantial
> >> > amount of code and where
> >> > it was manipulated for that matter. It becomes so very frustrating
> >> > even when reading a Class's
> >> > code with just 6-8 methods and not more than 100-150 lines of code.

>
> >> That's bad coding style on the part of the code writer.
> >> Conditionally-existing instance variables are *evil*.

>
> > Do you mean conditionally-useful instance variables evil, or that
> > conditionally-useful variables are ok but it's evil for them to
> > conditionally-exist?

>
> > The former I don't agree with at all.

>
> > If it's the latter, I believe there is something to be said for
> > variables that exist when they are needed and don't when they're not.
> > However, I acknowledge that listing all the variables you intend to
> > use in __init__ is highly comforting, even if it does belie their
> > current uselessness.

>
> The latter. I never even used the word "useful", so I have no idea
> where you got that from.


I was just asking for clarification of your rationale, of which I
imagined two possibilities ("conditional-usefulness is bad", or
"declaring attributes outside of __init__" is bad). However...


> To reiterate, variables which might only exist under certain
> conditions are evil, IMHO.
> This is not to say they are not useful in certain specific cases, just
> that in general there are better ways to design/structure programs to
> avoid them.


....the way you phrase this suggests to me that conditional-usefulness
*is* what you are really concerned with. Let me give you an example:

class A:
def __init__(self):
pass
def something(self):
self._conditionally_existent_variable = 1


ISTM that I don't need any restructuring at all to avoid conditional
existence; all I'd have to do is add

self._conditionally_existent_variable = None

to __init__. If you think I need to restructure this code, than you
evidently care about something more than just conditional existence.
If so, what is it that's so evil about conditionally-existent
variables? (I'll leave the question open-ended this time.)


Carl Banks
 
Reply With Quote
 
 
 
 
r
Guest
Posts: n/a
 
      01-12-2009
On Jan 11, 6:00*pm, Roy Smith <(E-Mail Removed)> wrote:
> In article
> <(E-Mail Removed)>,
>
> *"Madhusudan.C.S" <(E-Mail Removed)> wrote:
> > In such situations, where the Instance variables come into existence
> > only when they are used it is very difficult to track the flow of code.

>
> As the saying goes, "It's possible to write Fortran in any language".
>
> My personal habit is to "declare" all instance variables in the __init__()
> method of every class. *If there's no better value, I set them to None. *
> This isn't strictly required, but I think it makes it easier for somebody
> reading the code to understand the class.
>
> I'm not a big fan of dogmatic rules, other than the rule that says you
> should make your code as easy for somebody else to understand as possible..


Roy i totally agree and as i read down this thread i was thinking i
might get to spit that out first but you beat me -- Darn!

PS: your explanation is also much more eloquent than mine would have
been
 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      01-12-2009
Carl Banks <(E-Mail Removed)> writes:
> If so, what is it that's so evil about conditionally-existent
> variables? (I'll leave the question open-ended this time.)


I have found they make the code more confusing and bug prone.
It's better to define and document all the instance variables
in one place, in most cases.
 
Reply With Quote
 
Carl Banks
Guest
Posts: n/a
 
      01-12-2009
On Jan 11, 5:41*pm, Paul Rubin <http://(E-Mail Removed)> wrote:
> Carl Banks <(E-Mail Removed)> writes:
> > > The criticism is very valid. *Some languages do support immutable
> > > variables (e.g. "final" declarations in Java, "const" in C++, or
> > > universal immutability in pure functional languages) and they do so
> > > precisely for the purpose of taming the chaos of uncontrolled
> > > mutation. *It would be great if Python also supported immutability.

>
> > I don't think what you said (which is fine) makes his criticism valid,
> > unless you also suggest that all objects should be immutable.

>
> It would be enough to have a way to make specific objects and instance
> attributes immutable.


Enough for what, to make the guy's criticism valid? No it wouldn't.
Or are you just ignoring the OP altogether and complaining about what
bothers you?

For my part I am concerned with answering the OP's issues here, not
yours.


> > If any objects are mutable, you have to be prepared for objects to
> > mutated outside the initializer.

>
> Sure, but why have mutable objects all over the place? *And, why
> always have attributes visible at all, outside the class definition?
> The approach in C++ and Java is to have public and private instance
> variables, where the private ones are visible only in the class methods.


The OP wasn't complaining about the fact that objects aren't
immutable, as far as I can tell, nor about having public and private
variables, so I can't agree Python's lack of these has anything to do
with the OP's concerns.


Carl Banks
 
Reply With Quote
 
Carl Banks
Guest
Posts: n/a
 
      01-12-2009
On Jan 11, 6:42*pm, Paul Rubin <http://(E-Mail Removed)> wrote:
> Carl Banks <(E-Mail Removed)> writes:
> > If so, what is it that's so evil about conditionally-existent
> > variables? *(I'll leave the question open-ended this time.)

>
> I have found they make the code more confusing and bug prone.
> It's better to define and document all the instance variables
> in one place, in most cases.


That means all I have to do is add a stopgap value in __init__. I'm
asking Chris why that is evidently not enough, and that I'd have to
structure/design my code to avoid it.


Carl Banks
 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      01-12-2009
In article <(E-Mail Removed)>,
Chris Rebert <(E-Mail Removed)> wrote:

> This is not to say that breaking encapsulation willy-nilly is advised,
> but it does allow for some neat hackery every now and again.


I'm all for neat hackery, except when used in code that I need to read and
understand.
 
Reply With Quote
 
Chris Rebert
Guest
Posts: n/a
 
      01-12-2009
On Sun, Jan 11, 2009 at 4:33 PM, Carl Banks <(E-Mail Removed)> wrote:
> On Jan 11, 5:49 pm, Chris Rebert <(E-Mail Removed)> wrote:
>> On Sun, Jan 11, 2009 at 3:15 PM, Carl Banks <(E-Mail Removed)> wrote:
>> > On Jan 11, 3:31 pm, Chris Rebert <(E-Mail Removed)> wrote:
>> >> On Sun, Jan 11, 2009 at 1:22 PM, Madhusudan.C.S <(E-Mail Removed)> wrote:
>> >> > def somemethod(self, arg1):
>> >> > self.c = 20.22
>> >> > d = "some local variable"
>> >> > # do something
>> >> > ....
>> >> > ...
>> >> > def somemethod2 (self, arg2):
>> >> > self.c = "Changed the variable"
>> >> > # do something 2
>> >> > ...

>>
>> >> > In such situations, where the Instance variables come into existence
>> >> > only when they are used
>> >> > it is very difficult to track the flow of code. Its obviously not
>> >> > possible to remember what
>> >> > instance variable was defined where, when reading some substantial
>> >> > amount of code and where
>> >> > it was manipulated for that matter. It becomes so very frustrating
>> >> > even when reading a Class's
>> >> > code with just 6-8 methods and not more than 100-150 lines of code.

>>
>> >> That's bad coding style on the part of the code writer.
>> >> Conditionally-existing instance variables are *evil*.

>>
>> > Do you mean conditionally-useful instance variables evil, or that
>> > conditionally-useful variables are ok but it's evil for them to
>> > conditionally-exist?

>>
>> > The former I don't agree with at all.

>>
>> > If it's the latter, I believe there is something to be said for
>> > variables that exist when they are needed and don't when they're not.
>> > However, I acknowledge that listing all the variables you intend to
>> > use in __init__ is highly comforting, even if it does belie their
>> > current uselessness.

>>
>> The latter. I never even used the word "useful", so I have no idea
>> where you got that from.

>
> I was just asking for clarification of your rationale, of which I
> imagined two possibilities ("conditional-usefulness is bad", or
> "declaring attributes outside of __init__" is bad). However...
>
>
>> To reiterate, variables which might only exist under certain
>> conditions are evil, IMHO.
>> This is not to say they are not useful in certain specific cases, just
>> that in general there are better ways to design/structure programs to
>> avoid them.

>
> ...the way you phrase this suggests to me that conditional-usefulness
> *is* what you are really concerned with. Let me give you an example:
>
> class A:
> def __init__(self):
> pass
> def something(self):
> self._conditionally_existent_variable = 1
>
>
> ISTM that I don't need any restructuring at all to avoid conditional
> existence; all I'd have to do is add
>
> self._conditionally_existent_variable = None
>
> to __init__. If you think I need to restructure this code, than you
> evidently care about something more than just conditional existence.


No, this is exactly the sort of restructuring I was referring to; and
nothing more. Making that one-line change would be sufficient for me.
Perhaps "restructuring" was a poor choice of words...

Cheers,
Chris

--
Follow the path of the Iguana...
http://rebertia.com
 
Reply With Quote
 
bieffe62@gmail.com
Guest
Posts: n/a
 
      01-12-2009
On 12 Gen, 00:02, Paul Rubin <http://(E-Mail Removed)> wrote:
> Carl Banks <(E-Mail Removed)> writes:
> > and where it was manipulated for that matter.

>
> > This criticism is completely unfair. *Instance variables have to be
> > manipulated somewhere, and unless your object is immutable, that is
> > going to happen outside of __init__. *That's true in Java, C++, and
> > pretty much any other language.

>
> The criticism is very valid. *Some languages do support immutable
> variables (e.g. "final" declarations in Java, "const" in C++, or
> universal immutability in pure functional languages) and they do so
> precisely for the purpose of taming the chaos of uncontrolled
> mutation. *It would be great if Python also supported immutability.
>
> > I'm not going to argue that this doesn't hurt readability, because it
> > does (though not nearly as much as you claim). *But there are other
> > considerations, and in this case the flexibility of defining
> > attributes outside __init__ is worth the potential decrease in
> > readability.

>
> There are cases where this is useful but they're not terribly common.
> I think it would be an improvement if creating new object attributes
> was by default not allowed outside the __init__ method. *In the cases
> where you really do want to create new attributes elsewhere, you'd
> have to explicitly enable this at instance creation time, for example
> by inheriting from a special superclass:
>
> * *class Foo (DynamicAttributes, object): pass
>


You cannot do that, but you can establish a fixed set of attributes by
defining
the __slot__ class variable.


Ciao
-----
FB
 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      01-12-2009
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
> > * *class Foo (DynamicAttributes, object): pass
> >

> You cannot do that, but you can establish a fixed set of attributes by
> defining the __slot__ class variable.


That is not what __slot__ is for.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 14 04-03-2010 10:08 AM
Its a bird, its a plane, its.. um, an Attribute based System? thunk Ruby 0 04-01-2010 10:25 PM
Its a bird, its a plane, no ummm, its a Ruide thunk Ruby 1 03-30-2010 11:10 AM
Does the Python community really follow the philospy of "CommunityMatters?" r Python 16 02-02-2009 08:21 PM
Its really NOT the camera, its the PICTURE Larry Digital Photography 7 06-02-2004 06:07 AM



Advertisments