Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: is python Object oriented??

Reply
Thread Tools

Re: is python Object oriented??

 
 
thmpsn.m.k@gmail.com
Guest
Posts: n/a
 
      01-31-2009
On Jan 30, 12:15*am, Chris Rebert <(E-Mail Removed)> wrote:
> - Python supports encapsulation. Prefixing an attribute/method with an
> underscore indicates that other programmers should treat it as
> 'private'. However, unlike B&D languages, Python itself does nothing
> to enforce this privacy, leaving it instead to the good judgement of
> the programmer, under the philosophy that "We're all consenting adults
> here".


How do you know? (I know I'm not.)

Seriously, though, the lack of private members does allow for ugly
hacks in user code, and you know there are always ugly hackers.

> This allows people to meddle with internals, at their own risk,
> if it ends up being absolutely necessary.


If it ends up being necessary, the class's design is flawed. (Though
in this case, the flaw is easily solved by simply providing a getter.)

> The enforcement point is
> largely academic anyway, as most languages' reflection APIs let you
> poke at ostensibly "private" things.


If you're talking about getters, then note that this doesn't let you
modify the member (unless there's a corresponding setter).

In the absence of private/protected, Python should at least provide
something similar to C++'s 'const' or Java's 'final'. (Similar, not
equivalent, because then the object itself wouldn't be able to
manipulate its own members!)

 
Reply With Quote
 
 
 
 
Michael Torrie
Guest
Posts: n/a
 
      01-31-2009
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote
>> This allows people to meddle with internals, at their own risk,
>> if it ends up being absolutely necessary.

>
> If it ends up being necessary, the class's design is flawed. (Though
> in this case, the flaw is easily solved by simply providing a getter.)


No the class design is not necessarily flawed. Sometimes it is
desirable to modify a class's behavior at a lower level. In Java this
isn't possible directly and so it has led to an entire class of
libraries that provide means of doing this. For more information, look
up "Aspect-oriented Programming" on wikipedia. Since most
aspect-oriented programming examples I've seen are in Java I never
understood much about it ("cross-cutting concerns" is a pretty
meaningless explanation) until I realized that metaprogramming in
python, monkey-patching classes, and dynamically adding attributes to an
existing class are all forms of aspect-oriented programming. And it
turns out to be quite useful for some things.

One area where aspect-oriented programming is useful is in libraries
that add security layers to objects and methods. Rather than having to
make code directly aware of the security layer (which could take
different forms), we can instead reach into the classes and, for
example, wrap certain methods in a function that enforces security. If
we do it in the class directly, then even code that descends from this
class will transparently "inherit" all of the newly added security layer
code that was never there when the code was first written. By security
layer I'm talking more about code that enforces certain user
authentication before use (as in web programming) rather than "secure" code.
 
Reply With Quote
 
 
 
 
Marc 'BlackJack' Rintsch
Guest
Posts: n/a
 
      02-01-2009
On Sat, 31 Jan 2009 09:08:25 -0800, thmpsn.m.k wrote:

> On Jan 30, 12:15¬*am, Chris Rebert <(E-Mail Removed)> wrote:
>> - Python supports encapsulation. Prefixing an attribute/method with an
>> underscore indicates that other programmers should treat it as
>> 'private'. However, unlike B&D languages, Python itself does nothing to
>> enforce this privacy, leaving it instead to the good judgement of the
>> programmer, under the philosophy that "We're all consenting adults
>> here".

>
> How do you know? (I know I'm not.)


Then stay with B&D languages.

> Seriously, though, the lack of private members does allow for ugly hacks
> in user code, and you know there are always ugly hackers.


So what? The hacks in Java to access private fields are even uglier IMHO.

>> This allows people to meddle with internals, at their own risk, if it
>> ends up being absolutely necessary.

>
> If it ends up being necessary, the class's design is flawed.


Maybe that's the reason why it is really necessary.

> (Though in this case, the flaw is easily solved by simply providing a
> getter.)


Simply providing a getter for a private attribute? I thought that's not
easily possible in C++ or Java!?

>> The enforcement point is
>> largely academic anyway, as most languages' reflection APIs let you
>> poke at ostensibly "private" things.

>
> If you're talking about getters, then note that this doesn't let you
> modify the member (unless there's a corresponding setter).


It's not about getters but about accessing private fields without any
getters or setters through the reflection API. See the article
`Subverting Java Access Protection for Unit Testing`_ for examples.

... _Subverting Java Access Protection for Unit Testing:
http://www.onjava.com/pub/a/onjava/2...eflection.html

Ciao,
Marc 'BlackJack' Rintsch
 
Reply With Quote
 
Chris Rebert
Guest
Posts: n/a
 
      02-01-2009
On Sat, Jan 31, 2009 at 9:08 AM, <(E-Mail Removed)> wrote:
> On Jan 30, 12:15 am, Chris Rebert <(E-Mail Removed)> wrote:
>> - Python supports encapsulation. Prefixing an attribute/method with an
>> underscore indicates that other programmers should treat it as
>> 'private'. However, unlike B&D languages, Python itself does nothing
>> to enforce this privacy, leaving it instead to the good judgement of
>> the programmer, under the philosophy that "We're all consenting adults
>> here".

>
> How do you know? (I know I'm not.)
>
> Seriously, though, the lack of private members does allow for ugly
> hacks in user code, and you know there are always ugly hackers.


Marc already addressed your points excellently, but I'll add that I
once read somewhere (can't be bothered to find the source, PG maybe?)
that mediocre programming languages are designed for average
programmers and presume the language designers are smarter than the
programmer, whereas the truly great languages are designed for great
programmers and presume that the programmer is smarter than (or at
least knows better than) the designer.

This allows smart programmers using great languages to say: "I don't
like X about the language, I think I'll change it" or "The language
needs Y, I'll add it". For example, see the amazing magic some Python
people have worked using metaclasses.
Whereas smart programmers using a mediocre language are stuck: "I
don't like X about the language and there's nothing I can do about it
short of hacking the language implementation. Darn. Now I'm going to
have to write Y lines every time I want to workaround X since the
language doesn't let me factor the solution out any further! (sigh)".
For example, consider looping through an array in Java before the new
'for' statement was added.

Therefore, Python wisely chooses to not give a damn about how "ugly
hackers" may abuse the language; they'll abuse *any* language they get
their grubby mitts on; just let them and their ugly code quietly rot
in the corner while the elite are allowed by the language the extra
leeway they need to write their code masterpieces, which the common
people can then use to improve their programs.

Not that I'm saying any of us are necessarily elite; just don't be
/particularly/ stupid by using anything *clearly marked* with an
initial underscore without *extremely* good reason. And this isn't to
say the language shouldn't take average programmers into account; just
don't overly restrict the the 90% that are decent programmers in the
name of trying to save the bottom 10% from themselves (it's rather
like the "Save the Children!" retort on /.)

Cheers,
Chris

--
Follow the path of the Iguana...
http://rebertia.com
 
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
conversion of Python object to perl object srinivasan srinivas Python 0 08-17-2009 10:47 AM
boost.python Event object wrapped with bp::object() Alexander Eisenhuth Python 0 02-13-2008 03:38 PM
Working with C object of python object (pycairo,ctypes) AngelBlaZe Python 1 02-27-2007 09:37 AM
Object creation - Do we really need to create a parent for a derieved object - can't the base object just point to an already created base object jon wayne C++ 9 09-22-2005 02:06 AM
reading a python file object in c extension crashes python travis ray Python 0 06-13-2005 11:50 PM



Advertisments