Re: is python Object oriented??

Discussion in 'Python' started by Michael Torrie, Jan 29, 2009.

  1. M Kumar wrote:
    > but still I am not clear of the execution of the code, when we write or
    > execute a piece of python code without defining class, predefined class
    > attributes are available (not all but __name__ and __doc__ are available).
    > does it mean anything to this topic. Is it necessory to have __module__,
    > __dict__ and __bases__ for a class object in python?


    I think you're confused as to what object-oriented means. OO defines
    the internals of a language more than a particular programming paradigm.
    Obviously python lets you program in a variety of paradigms, including
    procedural and event-driven, but it is all very much object-oriented.
    So ignore those that say python doesn't force you to use OOP, when in
    fact it's unavoidable. It's just that you're not forced to place all
    your code in class definitions. You don't need to because your code is
    already object-oriented in that you're manipulating objects and their
    attributes.

    As others have said, Python is an object-oriented language through and
    through, closer to Smalltalk in many ways, the grand-daddy of all OO
    languages.

    It appears that you are only really familiar with Java, and that leads
    to a number of interesting misconceptions about OO. Java's bizarre OO
    requires everything to be in a class, which leads many people to believe
    this is what OO should be. In fact Java is a bit odd when it comes to
    OO, as there are many things in Java that aren't in fact objects. For
    example, primitives are intrinsic types and are not objects.
    Furthermore class definitions are not objects either, at least from the
    programmer's pov. You can't manipulate them by standard means as you
    can in Smalltalk and Python. In Smalltalk and Python a "class" is an
    object just as much as an instance of a class is an object which has a
    constructor factory method that returns instance objects. Java also has
    very strange ways of doing singleton patterns. You have to wrap
    singletons in class and define them as "static." I think this was
    inherited from C++.

    The most basic object in a python script is the module object which
    represents the namespace of the current script. In effect a module
    object is a singleton. It has a few attributes, and you can use it to
    look up any of the objects it contains, such as functions, objects
    (so-called variables), classes, etc. Everything in python is an object.
    The statement:

    a = 4

    defines an integer object "4" and binds a name to it, 'a.' You can even
    check to see what methods the object supports by doing:

    >>> dir(4)

    ['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__',
    '__delattr__', '__div__', '__divmod__', '__doc__', '__float__',
    '__floordiv__', '__getattribute__', '__getnewargs__', '__hash__',
    '__hex__', '__index__', '__init__', '__int__', '__invert__', '__long__',
    '__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__',
    '__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__',
    '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__',
    '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__',
    '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__',
    '__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__']

    dir(a) would return the same thing. As you can see, all the operators
    that can be performed with a number object are defined. This little
    exercise alone should show you how much more object-oriented Python is
    than Java.

    Python's OO capabilities are really exposed when you start extending
    built-in types, or doing meta programming where you dynamically alter
    classes (and instance objects) on the fly.
     
    Michael Torrie, Jan 29, 2009
    #1
    1. Advertising

  2. Michael Torrie

    Hung Vo Guest

    On Jan 30, 4:19 am, Michael Torrie <> wrote:
    > M Kumar wrote:
    > > but still I am not clear of the execution of the code, when we write or
    > > execute a piece of python code without defining class, predefined class
    > > attributes are available (not all but __name__ and __doc__ are available).
    > > does it mean anything to this topic. Is it necessory to have __module__,
    > > __dict__ and __bases__ for a class object in python?

    >
    > I think you're confused as to what object-oriented means.  OO defines
    > the internals of a language more than a particular programming paradigm.
    >  Obviously python lets you program in a variety of paradigms, including
    > procedural and event-driven, but it is all very much object-oriented.
    > So ignore those that say python doesn't force you to use OOP, when in
    > fact it's unavoidable.  It's just that you're not forced to place all
    > your code in class definitions.  You don't need to because your code is
    > already object-oriented in that you're manipulating objects and their
    > attributes.
    >
    > As others have said, Python is an object-oriented language through and
    > through, closer to Smalltalk in many ways, the grand-daddy of all OO
    > languages.
    >
    > It appears that you are only really familiar with Java, and that leads
    > to a number of interesting misconceptions about OO.  Java's bizarre OO
    > requires everything to be in a class, which leads many people to believe
    > this is what OO should be.  In fact Java is a bit odd when it comes to
    > OO, as there are many things in Java that aren't in fact objects.  For
    > example, primitives are intrinsic types and are not objects.
    > Furthermore class definitions are not objects either, at least from the
    > programmer's pov.  You can't manipulate them by standard means as you
    > can in Smalltalk and Python.  In Smalltalk and Python a "class" is an
    > object just as much as an instance of a class is an object which has a
    > constructor factory method that returns instance objects.  Java also has
    > very strange ways of doing singleton patterns.  You have to wrap
    > singletons in class and define them as "static."  I think this was
    > inherited from C++.
    >
    > The most basic object in a python script is the module object which
    > represents the namespace of the current script.  In effect a module
    > object is a singleton.  It has a few attributes, and you can use it to
    > look up any of the objects it contains, such as functions, objects
    > (so-called variables), classes, etc.  Everything in python is an object..
    >  The statement:
    >
    > a = 4
    >
    > defines an integer object "4" and binds a name to it, 'a.'  You can even
    > check to see what methods the object supports by doing:
    >
    > >>> dir(4)

    >
    > ['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__',
    > '__delattr__', '__div__', '__divmod__', '__doc__', '__float__',
    > '__floordiv__', '__getattribute__', '__getnewargs__', '__hash__',
    > '__hex__', '__index__', '__init__', '__int__', '__invert__', '__long__',
    > '__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__',
    > '__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__',
    > '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__',
    > '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__',
    > '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__',
    > '__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__']
    >
    > dir(a) would return the same thing.  As you can see, all the operators
    > that can be performed with a number object are defined.  This little
    > exercise alone should show you how much more object-oriented Python is
    > than Java.
    >
    > Python's OO capabilities are really exposed when you start extending
    > built-in types, or doing meta programming where you dynamically alter
    > classes (and instance objects) on the fly.


    I'm new to Python and also wondering about OOP in Python.

    I want to justify the above question (is Python Object-Oriented?).
    Does Python follow the concepts/practices of Encapsulation,
    Polymorphism and Interface, which are quite familiar to Java
    programmers?

    Cheers,
    Hung
     
    Hung Vo, Jan 30, 2009
    #2
    1. Advertising

  3. Michael Torrie

    Hung Vo Guest

    On Jan 30, 4:19 am, Michael Torrie <> wrote:
    > M Kumar wrote:
    > > but still I am not clear of the execution of the code, when we write or
    > > execute a piece of python code without defining class, predefined class
    > > attributes are available (not all but __name__ and __doc__ are available).
    > > does it mean anything to this topic. Is it necessory to have __module__,
    > > __dict__ and __bases__ for a class object in python?

    >
    > I think you're confused as to what object-oriented means.  OO defines
    > the internals of a language more than a particular programming paradigm.
    >  Obviously python lets you program in a variety of paradigms, including
    > procedural and event-driven, but it is all very much object-oriented.
    > So ignore those that say python doesn't force you to use OOP, when in
    > fact it's unavoidable.  It's just that you're not forced to place all
    > your code in class definitions.  You don't need to because your code is
    > already object-oriented in that you're manipulating objects and their
    > attributes.
    >
    > As others have said, Python is an object-oriented language through and
    > through, closer to Smalltalk in many ways, the grand-daddy of all OO
    > languages.
    >
    > It appears that you are only really familiar with Java, and that leads
    > to a number of interesting misconceptions about OO.  Java's bizarre OO
    > requires everything to be in a class, which leads many people to believe
    > this is what OO should be.  In fact Java is a bit odd when it comes to
    > OO, as there are many things in Java that aren't in fact objects.  For
    > example, primitives are intrinsic types and are not objects.
    > Furthermore class definitions are not objects either, at least from the
    > programmer's pov.  You can't manipulate them by standard means as you
    > can in Smalltalk and Python.  In Smalltalk and Python a "class" is an
    > object just as much as an instance of a class is an object which has a
    > constructor factory method that returns instance objects.  Java also has
    > very strange ways of doing singleton patterns.  You have to wrap
    > singletons in class and define them as "static."  I think this was
    > inherited from C++.
    >
    > The most basic object in a python script is the module object which
    > represents the namespace of the current script.  In effect a module
    > object is a singleton.  It has a few attributes, and you can use it to
    > look up any of the objects it contains, such as functions, objects
    > (so-called variables), classes, etc.  Everything in python is an object..
    >  The statement:
    >
    > a = 4
    >
    > defines an integer object "4" and binds a name to it, 'a.'  You can even
    > check to see what methods the object supports by doing:
    >
    > >>> dir(4)

    >
    > ['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__',
    > '__delattr__', '__div__', '__divmod__', '__doc__', '__float__',
    > '__floordiv__', '__getattribute__', '__getnewargs__', '__hash__',
    > '__hex__', '__index__', '__init__', '__int__', '__invert__', '__long__',
    > '__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__',
    > '__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__',
    > '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__',
    > '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__',
    > '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__',
    > '__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__']
    >
    > dir(a) would return the same thing.  As you can see, all the operators
    > that can be performed with a number object are defined.  This little
    > exercise alone should show you how much more object-oriented Python is
    > than Java.
    >
    > Python's OO capabilities are really exposed when you start extending
    > built-in types, or doing meta programming where you dynamically alter
    > classes (and instance objects) on the fly.


    I'm new to Python and also wondering about OOP in Python.

    I want to justify the above question (is Python Object-Oriented?).
    Does Python follow the concepts/practices of Encapsulation,
    Polymorphism and Interface, which are quite familiar to Java
    programmers?

    Cheers,
    Hung
     
    Hung Vo, Jan 30, 2009
    #3
  4. Michael Torrie

    Hung Vo Guest

    On Jan 30, 4:19 am, Michael Torrie <> wrote:
    > M Kumar wrote:
    > > but still I am not clear of the execution of the code, when we write or
    > > execute a piece of python code without defining class, predefined class
    > > attributes are available (not all but __name__ and __doc__ are available).
    > > does it mean anything to this topic. Is it necessory to have __module__,
    > > __dict__ and __bases__ for a class object in python?

    >
    > I think you're confused as to what object-oriented means.  OO defines
    > the internals of a language more than a particular programming paradigm.
    >  Obviously python lets you program in a variety of paradigms, including
    > procedural and event-driven, but it is all very much object-oriented.
    > So ignore those that say python doesn't force you to use OOP, when in
    > fact it's unavoidable.  It's just that you're not forced to place all
    > your code in class definitions.  You don't need to because your code is
    > already object-oriented in that you're manipulating objects and their
    > attributes.
    >
    > As others have said, Python is an object-oriented language through and
    > through, closer to Smalltalk in many ways, the grand-daddy of all OO
    > languages.
    >
    > It appears that you are only really familiar with Java, and that leads
    > to a number of interesting misconceptions about OO.  Java's bizarre OO
    > requires everything to be in a class, which leads many people to believe
    > this is what OO should be.  In fact Java is a bit odd when it comes to
    > OO, as there are many things in Java that aren't in fact objects.  For
    > example, primitives are intrinsic types and are not objects.
    > Furthermore class definitions are not objects either, at least from the
    > programmer's pov.  You can't manipulate them by standard means as you
    > can in Smalltalk and Python.  In Smalltalk and Python a "class" is an
    > object just as much as an instance of a class is an object which has a
    > constructor factory method that returns instance objects.  Java also has
    > very strange ways of doing singleton patterns.  You have to wrap
    > singletons in class and define them as "static."  I think this was
    > inherited from C++.
    >
    > The most basic object in a python script is the module object which
    > represents the namespace of the current script.  In effect a module
    > object is a singleton.  It has a few attributes, and you can use it to
    > look up any of the objects it contains, such as functions, objects
    > (so-called variables), classes, etc.  Everything in python is an object..
    >  The statement:
    >
    > a = 4
    >
    > defines an integer object "4" and binds a name to it, 'a.'  You can even
    > check to see what methods the object supports by doing:
    >
    > >>> dir(4)

    >
    > ['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__',
    > '__delattr__', '__div__', '__divmod__', '__doc__', '__float__',
    > '__floordiv__', '__getattribute__', '__getnewargs__', '__hash__',
    > '__hex__', '__index__', '__init__', '__int__', '__invert__', '__long__',
    > '__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__',
    > '__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__',
    > '__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__',
    > '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__',
    > '__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__',
    > '__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__']
    >
    > dir(a) would return the same thing.  As you can see, all the operators
    > that can be performed with a number object are defined.  This little
    > exercise alone should show you how much more object-oriented Python is
    > than Java.
    >
    > Python's OO capabilities are really exposed when you start extending
    > built-in types, or doing meta programming where you dynamically alter
    > classes (and instance objects) on the fly.


    I'm new to Python and also wondering about OOP in Python.

    I want to justify the above question (is Python Object-Oriented?).
    Does Python follow the concepts/practices of Encapsulation,
    Polymorphism and Interface, which are quite familiar to Java
    programmers?

    Cheers,
    Hung
     
    Hung Vo, Jan 30, 2009
    #4
  5. Michael Torrie

    alex23 Guest

    On Jan 30, 4:00 pm, Hung Vo <> wrote:
    > Does Python follow the concepts/practices of Encapsulation,
    > Polymorphism and Interface, which are quite familiar to Java
    > programmers?


    Well, it has the same _concepts_, but definitely not the same
    practices/implementations. As they say, Python is not Java :)
     
    alex23, Jan 30, 2009
    #5
  6. Michael Torrie

    Chris Rebert Guest

    On Thu, Jan 29, 2009 at 9:56 PM, Hung Vo <> wrote:
    <snip>
    > I'm new to Python and also wondering about OOP in Python.
    >
    > I want to justify the above question (is Python Object-Oriented?).
    > Does Python follow the concepts/practices of Encapsulation,
    > Polymorphism and Interface, which are quite familiar to Java
    > programmers?


    If you're looking for a benchmark for object-orientedness, Smalltalk,
    not Java, is the canonical language to compare against.

    Anyway, to your three-pronged question:
    - Yes, Python supports polymorphism. I find it hard to think of an
    example of an OO language that doesn't.

    - Python does not support interfaces in the Java sense (although there
    are a few third-party libraries that add such support); neither does
    Smalltalk. Instead, both Smalltalk and Python use duck-typing to
    similar effect. See http://en.wikipedia.org/wiki/Duck_typing

    - 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". This allows people to meddle with internals, at their own risk,
    if it ends up being absolutely necessary. The enforcement point is
    largely academic anyway, as most languages' reflection APIs let you
    poke at ostensibly "private" things.

    Cheers,
    Chris

    P.S. You appear to have posted the same message 3 times(!), which is a
    bit annoying for readers.

    --
    Follow the path of the Iguana...
    http://rebertia.com
     
    Chris Rebert, Jan 30, 2009
    #6
  7. Michael Torrie

    alex23 Guest

    On Jan 30, 4:15 pm, Chris Rebert <> wrote:
    > - Python does not support interfaces in the Java sense (although there
    > are a few third-party libraries that add such support); neither does
    > Smalltalk. Instead, both Smalltalk and Python use duck-typing to
    > similar effect. Seehttp://en.wikipedia.org/wiki/Duck_typing


    I haven't yet had reason to use them, but do Abstract Base Classes
    (introduced in 2.6/3.0) go some way to provide more defined interface
    support for Python? My assumption was that was what they'd generally
    be used for...
     
    alex23, Jan 30, 2009
    #7
  8. Michael Torrie

    Chris Rebert Guest

    On Thu, Jan 29, 2009 at 10:25 PM, alex23 <> wrote:
    > On Jan 30, 4:15 pm, Chris Rebert <> wrote:
    >> - Python does not support interfaces in the Java sense (although there
    >> are a few third-party libraries that add such support); neither does
    >> Smalltalk. Instead, both Smalltalk and Python use duck-typing to
    >> similar effect. Seehttp://en.wikipedia.org/wiki/Duck_typing

    >
    > I haven't yet had reason to use them, but do Abstract Base Classes
    > (introduced in 2.6/3.0) go some way to provide more defined interface
    > support for Python? My assumption was that was what they'd generally
    > be used for...


    Ah, excellent point. I neglected to take ABCs into account. Smalltalk
    did have those as well.

    Cheers,
    Chris

    --
    Follow the path of the Iguana...
    http://rebertia.com
     
    Chris Rebert, Jan 30, 2009
    #8
  9. Michael Torrie

    Tim Rowe Guest

    2009/1/30 Hung Vo <>:

    > I want to justify the above question (is Python Object-Oriented?).
    > Does Python follow the concepts/practices of Encapsulation,
    > Polymorphism and Interface, which are quite familiar to Java
    > programmers?


    It's not the role of the language to follow those concepts, it's the
    role of the programmer to follow those concepts if the programmer
    believes OO to be an appropriate paradigm for the task in hand. If
    the programmer decides that following those concepts is appropriate,
    Python will offer more than enough support. If the programmer decides
    that OO is not an appropriate paradigm but wants to follow procedural
    or functional concepts instead, Python will support that, too.

    Object orientation is not really a language property at all; it's a
    design approach. I've written object oriented programs in C,
    hand-coding the despatch tables, before anybody gave the name "object
    oriented" to that approach. When people talk about an object oriented
    language they either mean a language that allows a close mapping
    between an object oriented design and the actual code (Python does),
    or they mean a language that *requires* the code to conform to an
    object oriented design (Python doesn't). So the answer to "Is Python
    Object-Oriented" is either "yes" or "no", depending on what you're
    /really/ asking.

    --
    Tim Rowe
     
    Tim Rowe, Jan 30, 2009
    #9
  10. Hung Vo wrote:
    > I'm new to Python and also wondering about OOP in Python.
    >
    > I want to justify the above question (is Python Object-Oriented?).
    > Does Python follow the concepts/practices of Encapsulation,
    > Polymorphism and Interface, which are quite familiar to Java
    > programmers?


    I'd say that actually Python uses encapsulation extensively throughout
    the language. Every object in Python has attributes. Thus every
    object encapsulates (contains) attributes (which are themselves objects).

    I think the term "encapsulation" is often misinterpreted by some (Java
    programmers in particular) to mean some kind of enforced black-box
    methodology. In effect they feel that getters and setters is the
    definition of encapsulation. This is really not true, especially if you
    go back to the original OO languages, such as Smalltalk.

    So if you are asking, does python enforce some kind of bizarre black box
    access semantics (requiring getters and setters), the answer is an
    emphatic "no!"

    Interfaces have nothing to do with OO programming as a matter of a
    fundamental principle. Interfaces exist in Java to compensate for
    flaws/features in the language. Particularly the lack of multiple
    inheritance which is a blessing/curse in Java. Python just doesn't need
    interfaces. Protocols for communication with an object do not need to
    be formally enforced. For example the popular database API that most
    python database libraries use just makes sure it implements certain
    methods. Thus it doesn't matter if I'm using mysql, postgresql, or
    oracle. I still call the object's "connect" method. Such a breath of
    fresh air compared to Java, in my opinion. Such informality can be a
    bit of a hindrance to some I guess.

    After this entire thread, it's funny that people are still chiming in
    saying, "so is it really OOP" after having it explained in so many ways.
     
    Michael Torrie, Jan 30, 2009
    #10
  11. Michael Torrie

    Guest

    On Jan 30, 12:15 am, Chris Rebert <> 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!)
     
    , Jan 31, 2009
    #11
  12. 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.
     
    Michael Torrie, Jan 31, 2009
    #12
  13. On Sat, 31 Jan 2009 09:08:25 -0800, thmpsn.m.k wrote:

    > On Jan 30, 12:15 am, Chris Rebert <> 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/2003/11/12/reflection.html

    Ciao,
    Marc 'BlackJack' Rintsch
     
    Marc 'BlackJack' Rintsch, Feb 1, 2009
    #13
  14. Michael Torrie

    Chris Rebert Guest

    On Sat, Jan 31, 2009 at 9:08 AM, <> wrote:
    > On Jan 30, 12:15 am, Chris Rebert <> 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
     
    Chris Rebert, Feb 1, 2009
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robert Hathaway
    Replies:
    0
    Views:
    427
    Robert Hathaway
    Jul 29, 2003
  2. Robert Hathaway
    Replies:
    0
    Views:
    427
    Robert Hathaway
    Jul 29, 2003
  3. Robert Hathaway
    Replies:
    1
    Views:
    467
    Robert J Hathaway III
    Jul 29, 2003
  4. Replies:
    2
    Views:
    444
    Bruno Desthuilliers
    May 26, 2008
  5. rolo
    Replies:
    3
    Views:
    194
    Robert Klemme
    Apr 9, 2004
Loading...

Share This Page