Re: is python Object oriented??
Gary Herron
> Object oriented languages doesn't allow execution of the code without
> class objects, what is actually happening when we execute some piece
> of code, is it bound to any class?
> Those who have time and consideration can help me
>
Python *is* object-oriented, but it is not (as your definition suggests)
object-fascist. We use objects to great effect in Python, when it is
natural to do so, but the language does not force it on us.
Gary Herron
> --
> Regards,
>
> Maneesh KB
>
> Comat Technologies
>
> Bangalore
>
> Mob: 9740-192309
>
>
>
> We work with the underprivileged and in rural India. If you are
> interested to be a part of it, please mail or call me. I will be happy
> to share and inform - http://www.comat.com
> ------------------------------------------------------------------------
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Chris Rebert
> Object oriented languages doesn't allow execution of the code without class
> objects, what is actually happening when we execute some piece of code, is
> it bound to any class?
That's not really the standard definition of object-oriented (c.f.
Wikipedia), but by your definition (which seems Java/Ruby-centric,
IMHO), Python would not be object-oriented.
In addition to methods, Python has functions, which are not associated
with a class and let you write code in a procedural style, thus
failing your criterion.
Python also has the top-level module scope, in which the code isn't
even part of a method or function at all and thus certainly is not
associated with a class, again not satisfying your criterion.
Cheers,
Chris
--
Follow the path of the Iguana...
http://rebertia.com
Bruno Desthuilliers
> M Kumar wrote:
>> Object oriented languages doesn't allow execution of the code without
>> class objects,
Chapter and verse, please ?
Nothing in the (very few) "axioms" of OOP mentions "classes". You don't
need classes to have an OOPL (ever heard about prototype-based languages
?). OOP is - as the name imply - about *objects*.
>> what is actually happening when we execute some piece
>> of code,
Top-level code ? or the body of a def statement ?
>> is it bound to any class?
Why should it be ?
Tino Wildenhain
> Python offers support for object orientation, but it's not an
> object-oriented language.
> I mean, you can code a entire program in Python with no classes. So you
> use it if you want to.
>
> It's not like java, which you must use a class to code a Hello World,
> but Java isn't fully object-oriented, because it doesn't provide support
> for multiple inheritance and it has primitive types (multiple interfaces
> and wrappers to primitive types doesn't count :) )
>
> AFAIK, the unique fully object oriented languagem is Smaltalk. (maybe
> Simula?), where everything is a class, even the primitive types.
well actually except keywords, everything is an object in python too,
including of course primitive types (if you say so - practically python
does not have them).
Regards
Tino
MC
Il se trouve que Chris Rebert a formulé :
> Python has functions, which are not associated
> with a class
functions are methods of builtin...
--
@-salutations
Michel Claveau
Steve Holden
> Object oriented languages doesn't allow execution of the code without
> code, is it bound to any class?
> Those who have time and consideration can help me
a) This is a purely theoretical consideration. You asked whether "python
is a pure object oriented language", but this will inevitably lead to
obscure discussions about what you mean rather than what Python is.
b) You seem to believe that a "pure" object oriented language must do
everything using classes. Since many problems are just as easy (or
easier) to solve with a procedural approach, Python takes the view that
it should be easy to provide such solutions as well.
c) import this
The Zen of Python, by Tim Peters
[...] practicality beats purity [...]
We aren't big on purity in the Python world ;-)
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Bruno Desthuilliers
> Hi!
>
> Il se trouve que Chris Rebert a formulé :
>> Python has functions, which are not associated
>> with a class
>
> functions are methods of builtin...
Please check your facts. Python functions are not "methods" of anything
(and not even necessarily attributes of a module - think about nested
functions...).
Michael Torrie
> 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.
Terry Reedy
> Object oriented languages doesn't allow execution of the code without
> class objects, what is actually happening when we execute some piece of
> code, is it bound to any class?
> Those who have time and consideration can help me
My take..
Python is a language. Programs written in Python create and manipulate
information objects. (But programs are not objects themselves.) So,
Python is a language for describing object-based information processing.
Every Python object is an instance of some class. Every class, being an
object itself, is an instance of some metaclass. (The 'type' metaclass
is an instance of itself.) Every class (in Py3) is also a subclasses of
the base class 'object'.
I think 'object-orient language' is a somewhat misleading abbreviation
since 'object-orientedness' is a potential property of the an abstract
computation system a language works, with rather than a property of a
language itself.
Terry Jan Reedy
Kay Schluehr
> Python *is* object-oriented, but it is not (as your definition suggests)
> object-fascist.
I'd put it more mildly. Python is object oriented. The orientation is
there but the fanatism is gone.
Kay
Ben Finney
> Hi!
>
> Il se trouve que Chris Rebert a formulé :
> > Python has functions, which are not associated with a class
>
> functions are methods of builtin...
No, because ‘builtin’ is not a class.
--
\ “The shortest distance between two points is under |
`\ construction.” —Noelie Alito |
_o__) |
Ben Finney
Steven D'Aprano
> In addition to methods, Python has functions, which are not associated
> with a class
Yes they are.
>>> (lambda: None).__class__
<type 'function'>
The function type itself has a class:
>>> (lambda: None).__class__.__class__
<type 'type'>
--
Steven
Chris Rebert
I think we're now quibbling over the interpretation of "associated".
My intention was to contrast how methods and classmethods are stored
and accessed through the class they are defined in (or grafted onto),
whereas plain functions are not (instance/class variables that happen
to hold functions notwithstanding).
Hung Vo
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
I'm new to Python and also wondering about OOP in Python.
Hung Vo
I'm new to Python and also wondering about OOP in Python.
alex23
> 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 :)
Chris Rebert
<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.
alex23
> - 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...
Chris Rebert
Ah, excellent point. I neglected to take ABCs into account. Smalltalk
did have those as well.
Cheers,
Chris
Tim Rowe
> 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
Grant Edwards
> On Thu, Jan 29, 2009 at 9:56 PM, Hung Vo <hung...@gmail.com> 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.
As long as one doesn't then conflate message-passingness with
object-orientedness. [Not that I'm implying Chris does, but
given the OP's comments one worries that he might.]
--
Grant Edwards grante Yow! I know things about
at TROY DONAHUE that can't
visi.com even be PRINTED!!
Michael Torrie
> 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
> Python is not purely object oriented programming, because we can write
> functions without any class.
> You are right, predefined class attributes are available when we write or
> execute a piece of python code without defining class, that means it's just
> using objects for it's purpose. It does not mean its purely object oriented.
To be clear, python does not force you to lay out your code according to
some strict object-oriented paradigm. But Python itself is still purely
object-oriented, as is your script when parsed.
This function without a class that you mentioned, is in fact an object
with attributes. You can pass a function around just like any other
object. Even calling a function is invoked like so:
myfunc.__call__(params)
So necessitating that code be inside a class has nothing to do with
object-oriented programming. Let's not forget that classes are
themselves objects (metaobjects in smalltalk parlance if I recall
correctly).
Now python does not have any way besides lambda expressions of creating
unbound function objects, but in practice this doesn't matter as I can
rebind names freely. I can still do:
a=myfunc
myfunc=some other expression or object
> It all depends on implementation, I think even we can make "C" object
> oriented with proper implementation.
Indeed, any code based on gobject libraries can be object-oriented in
design and function.
Christian Heimes
>> It all depends on implementation, I think even we can make "C" object
>> oriented with proper implementation.
>
> Indeed, any code based on gobject libraries can be object-oriented in
> design and function.
The Python C API is a good example for well designed and object oriented
C code.
Christian
Laszlo Nagy
> Object oriented languages doesn't allow execution of the code without
> class objects, what is actually happening when we execute some piece
> of code, is it bound to any class?
> Those who have time and consideration can help me
have learned some things in the University, and one of them was making
distinction between "pure object oriented" languages, and "mixed" languages.
Pure object oriented languages does not have programming tools that are
non-objects. A good example was SmallTalk, if I remember correctly.
Python is not a pure object oriented language, because it has other
programming tools, for example functions.
However, your question seems to be pedantry. As others would say, "you
can do programming in FORTRAN in any language". In other words, it is
possible to use Python in a non object-oriented way, but the "good" way
of using it is defining classes and making objects... So Python *is*
object oriented, if you use it the right way. There might be a
definition of "object oriented language" that does not apply to Python,
and theoretically, you could say that according to that definition,
Python is not object oriented. But practically, it is!
Best,
Laszlo
MC
> ‘builtin’ is not a class.
I think "object" ; not only "class"
And "builtin" is an object.
--
@-salutations
Michel Claveau
Steve Holden
> Re
>
>> ‘builtin’ is not a class.
>
> I think "object" ; not only "class"
> And "builtin" is an object.
>
between methods of a class and functions of a module. Until you
appreciate that you will likely make mistakes. Don't worry, though, we
all learn from our mistakes.
thmps...@gmail.com
> - 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!)
Stephen Hansen
On Jan 30, 12:15 am, Chris Rebert <c...@rebertia.com> wrote:How do you know? (I know I'm not.)
> - 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".
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, though?
If you're a application developer, writing your own code: just don't do it.
You've now achieved enforced encapsulation! Why does the language
need to check that?
If you're the user of a library and you need access to a private member
of that library: again, just don't do it! Write a patch and maintain a
private fork to expose the member function, and submit it to the developer
and hope it gets included so you don't have to maintain the private fork.
For those people who need access to that internal Right Now and don't
want to wait for the developer to expose it, because its important to them
why should the language forbid it? Sure, its an ugly hack. But so what?
They're doing it, at the risk of future breakage if anything changes in
that undocumented internal detail, because they need to. There are
situations where maintaining a private fork to expose something in a
library is a far greater burden and not worth it.
If you're the writer of a library, why do you even care if the people who
use it access an undocumented internal? If anything breaks its not
your problem.
If you're in some corporate environment which has a 'no fiddling with
the privates of another teams modules' -- why do you need the language
to enforce that restriction? If your employees aren't following the coding
standards of your own organization, that's a problem. Surely it'd come up
very quickly with even the most cursory of reviews, after all "obj._variable"
is really obviously not "self._variable" and so pretty obviously accessing
someone elses private state.
If you're in an open source environment and are worried about quality
of code from lots of contributors who aren't being paid: again, reviews
should be happening /anyways/.
In the end, why bother? If you believe in absolute encapsulation its
extremely easy for you to get it in Python, today... don't touch someone
elses privates.
If it ends up being necessary, the class's design is flawed. (Though
> This allows people to meddle with internals, at their own risk,
> if it ends up being absolutely necessary.
in this case, the flaw is easily solved by simply providing a getter.)
Sure, the design is flawed. Doesn't change the fact that you need to access
that internal state. "Providing a getter" is not necessarily simple: what if
its someone elses code? At the very least you have to maintain a private
fork then /or/ wait until they get around to fixing the design. Sometimes that's
no big deal. Sometimes it is.
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!)
I find marking my constants as SOME_CONSTANT instead of some_constant
to be more then sufficient usually. In the case where I do want to let someone
read a piece of data and not write it, I find a getter accessing a private member
variable without a corresponding setter perfectly fine.
If the users of the code choose to dig inside my class and fiddle with that
private member -- woe on them! I wash my hands of any trouble they
have.
--Stephen
thmps...@gmail.com
But it's only a faking, and things such as inheritance and
polymorphism are implemented clumsily (actually I'm not even sure
about polymorphism). And of course, there are still no private
members.
Andreas Waldenburger
wrote:
> Python is not a pure object oriented language, because it has other
> programming tools, for example functions.
I'm not sure about the first part of the sentence, but Python's
functions are objects. Check it in the interpreter: attributes,
methods, the whole caboodle.
regards,
/W
--
My real email address is constructed by swapping the domain with the
recipient (local part).
Christian Heimes
> But it's only a faking, and things such as inheritance and
> polymorphism are implemented clumsily (actually I'm not even sure
> about polymorphism). And of course, there are still no private
> members.
Do you honestly believe that C++'s private members are really private?
Privateness is only enforced during parsing time. Nobody can stop you
from messing around with header files or memory. You can still access
and modify private members but it's all messy and ugly. Even C# and .NET
don't stop you from doing nasty things from unmananged assemblies.
Seriously, 'private' and 'protected' are merely tools to stop bad
programmers from doing bad stuff. And the serve as documentation, too.
Oh, by the way, the first C++ compilers just converted C++ code to C
code. Such much about "You can't do OOP in C."!
Christian
Michael Torrie
>> 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
>> To be clear, python does not force you to lay out your code according to
>> some strict object-oriented paradigm. But Python itself is still purely
>> object-oriented, as is your script when parsed.
>
> polymorphism are implemented clumsily (actually I'm not even sure
> about polymorphism). And of course, there are still no private
> members.
How is it faking? The class of a function object is "function," which
is of the metaclass "type." What more do you want? If Guido himself
declared that functions are objects would you believe that? Or modules?
Since a function object is an instance of the class "function" I don't
see how you could inherit from it, and polymorphism has nothing to do
with this either. Maybe what you are talking about is deriving a class
from the class "function." Not sure if that's allowed, mainly because
the language has defined a standard way of declaring a function (methods
are functions too, of course), so creating a useful, derived function
object would be difficult given how the syntax of the language works.
Private members? I could stick add any attribute I wanted to a function
object and ask that people treat it as private if I wanted to:
def myfunc():
pass
myfunc.__dict__['_private'] = 4
If you are insinuating that not forcing private attributes to be
unaccessible by others (black box theory) is in somehow a violation of
object-oriented semantics, think again. It's not. (There are no formal
definitions of OO anyay, but wikipedia lists quite a few characteristics
considered common to OO, and enforced private members is not one of them.)
Michael Torrie
> You can think what you like, but there is a fundamental difference
> between methods of a class and functions of a module. Until you
> appreciate that you will likely make mistakes. Don't worry, though, we
> all learn from our mistakes.
And this fundamental difference is?
>From what I can tell an instance method is an object that encapsulates
the function object in a closure that makes sure it has a reference to
"self." I know that you dynamically add functions to objects creating
methods dynamically, by using new.instancemethod or something.
This seems to indicate to me that there are functions and there are
functions. Methods are in fact functions, just with a callable wrapper
around them. Is this not so?
thmps...@gmail.com
> thmpsn....@gmail.com schrieb:
>
> > But it's only a faking, and things such as inheritance and
> > polymorphism are implemented clumsily (actually I'm not even sure
> > about polymorphism). And of course, there are still no private
> > members.
>
> Do you honestly believe that C++'s private members are really private?
> Privateness is only enforced during parsing time. Nobody can stop you
> from messing around with header files or memory. You can still access
> and modify private members but it's all messy and ugly. Even C# and .NET
> don't stop you from doing nasty things from unmananged assemblies.
I don't know how you would do it in C# (or Java for that matter).
In C++ you can play with pointers to "get at" some memory location
somewhere in the object. The only portable way to know the exact
location between the beginning of the object and the desired member is
the offsetof() macro, but as I understand it this only works for POD
types, which means that it won't work for classes such as:
class NonPOD
{
private:
int a;
int b;
public:
NonPOD();
~NonPOD();
int C();
};
(I haven't ever actually tried it, so I'm not sure.)
Nevertheless, you can play and hope for the best. For example, if the
member you want to get at is 'b', then you can do:
NonPOD obj;
std::cout << "obj.b = " << *(int*) ((unsigned char*) &obj + sizeof
(int)) << std::endl;
and hope that the compiler didn't leave a hole between the 'a' member
and the 'b' member.
Getting at the 'a' member would be easier because the first member of
a struct/class always has the same memory location as the object
itself (although again I'm not sure if this is true for non-POD types
as well).
So: Sometimes it may work, usually it will be unsafe and/or non-
portable, and in most cases the procedure will look complicated. It
certainly isn't something I'd try in a real application. However, it
WOULD be tempting to access the member if the language allows me to
just write:
print "obj.b =", obj.b
and be done with it.
Personally, in Python, I use double underscores for "private" members,
so the above would look like:
print "obj.b =", obj._NonPOD__b
but it's still easier than the C++ example.
> Seriously, 'private' and 'protected' are merely tools to stop bad
> programmers from doing bad stuff. And the serve as documentation, too.
It's not just documentation. For example, suppose you're reading a
class definition and see the declaration of a veryInterestingMember
and forget that you're not supposed to access it. If you try to access
it, the compiler will give you a diagnostic message at compile time.
So you can think of it as an error-checking tool as well.
> Oh, by the way, the first C++ compilers just converted C++ code to C
> code. Such much about "You can't do OOP in C."!
More interestingly, though, most compilers translate C and C++ code to
assembler first. Does that mean that you can do object-oriented
programming, generic programming, and procedural programming in
assembler?
(Answer: No, but you can probably -- very clumsily -- fake them.)
Michael Torrie
> More interestingly, though, most compilers translate C and C++ code to
> assembler first. Does that mean that you can do object-oriented
> programming, generic programming, and procedural programming in
> assembler?
>
This is getting quite far off the topic, but of course you can, and it's
not faking anything. This should be obvious.
You can certainly do OO programming in C, which is a glorified
assembler. For example, the gobject system defines a complete
object-oriented system with classes, inheritance, polymorphism,
encapuslation. It uses structures for encapsulating the data and call
tables for virtual methods (to use a c++ parlance). It's such a well
defined object model that you can, with gtkmm, even extend a c-based
gobject class with C++! Of course you can also extend gobject-based C
classes with python as well using PyBank to import them.
Back when assembly was still somewhat in vogue I read a book on
programming assembly in an object-oriented manner. So of course you
can. Yes it can be clumsy without syntactic sugar. If you set up call
tables, you can handle polymorphism. How would this be faking it? By
your definition C++ is faking it since C++ compiles to assembly. In the
early days, C++ was first implemented as a preprocessor that emitted
straight C code. And I guess python fakes it since the python
interpreter is implemented in C compiled to ASM.
Maybe the terminology would be less confusing if we considered the
terms, object-oriented programming, object-oriented languages,
object-oriented systems. Any language can be used for the first.
Python, Java, C++ can be defined by the second, and things like Python
(the runtime environment), .NET, JVM, Parrot, can be defined by the last
term. Fair enough?
Python is certainly an object-oriented language, and implements a
complete object-oriented system. Python can support coding in an
object-oriented methodology, or you can code traditionally while still
taking advantage of the complete OO system.
David Bolen
> I don't know how you would do it in C# (or Java for that matter).
>
> In C++ you can play with pointers to "get at" some memory location
> somewhere in the object. The only portable way to know the exact
> location between the beginning of the object and the desired member is
> the offsetof() macro, but as I understand it this only works for POD
> types, which means that it won't work for classes such as:
>
> class NonPOD
> {
> private:
> int a;
> int b;
> public:
> NonPOD();
> ~NonPOD();
> int C();
> };
>
> (I haven't ever actually tried it, so I'm not sure.)
>
> Nevertheless, you can play and hope for the best. For example, if the
> member you want to get at is 'b', then you can do:
>
> NonPOD obj;
> std::cout << "obj.b = " << *(int*) ((unsigned char*) &obj + sizeof
> (int)) << std::endl;
>
> and hope that the compiler didn't leave a hole between the 'a' member
> and the 'b' member.
Probably moving off topic, but I don't think you have to get anywhere
near that extreme in terms of pointers, unless you're trying to deal
with instances for which you have no source but only opaque pointers.
I haven't gotten stuck having to do this myself yet, but I believe one
commmon "hack" for the sort of class you show above is to just
"#define private public" before including the header file containing
the class definition. No fiddling with pointers, offsets, or
whatever, just normal object access syntax past that point.
Of course, I believe such a redefinition violates the letter of the
C++ standard, but most preprocessors do it anyway. Also, it won't
handle the case where the "private:" is not used, but the members are
just declared prior to any other definition, since a class is private
by default.
But even then, if you had to, just make a copy of the class definition
(or heck, just define a structure if it's just data elements), ensure
the private portions are public, and then cast a pointer to the old
class instance to one of your new class instance. Assuming you're
building everything in a single compiler, the layouts should match
just fine. Again, normal object member access, no casting or pointers
needed (beyond the initial overall object pointer cast).
-- David
Marc 'BlackJack' Rintsch
> On Jan 31, 2:27 pm, Christian Heimes <li...@cheimes.de> wrote:
>> Do you honestly believe that C++'s private members are really private?
>> Privateness is only enforced during parsing time. Nobody can stop you
>> from messing around with header files or memory. You can still access
>> and modify private members but it's all messy and ugly. Even C# and
>> .NET don't stop you from doing nasty things from unmananged assemblies.
>
> I don't know how you would do it in C# (or Java for that matter).
In Java you can use reflection to get your fingers on private fields.
> In C++ you can play with pointers to "get at" some memory location
> somewhere in the object.
> [Snipped pointer fiddling explanation]
> So: Sometimes it may work, usually it will be unsafe and/or non-
> portable, and in most cases the procedure will look complicated.
Or ``#define private public`` before including the header files. Which
doesn't look complicated to me.
> It certainly isn't something I'd try in a real application. However, it
> WOULD be tempting to access the member if the language allows me to just
> write:
>
> print "obj.b =", obj.b
>
> and be done with it.
And that's perfectly okay, because the author would have prepended an
underscore to `b` if you should not mess with it.
> Personally, in Python, I use double underscores for "private" members,
> so the above would look like:
>
> print "obj.b =", obj._NonPOD__b
>
> but it's still easier than the C++ example.
The name mangling is there to prevent name clashes, not to make
attributes inaccessible. It's useful for mixin classes for example.
>> Seriously, 'private' and 'protected' are merely tools to stop bad
>> programmers from doing bad stuff. And the serve as documentation, too.
>
> It's not just documentation. For example, suppose you're reading a class
> definition and see the declaration of a veryInterestingMember and forget
> that you're not supposed to access it. If you try to access it, the
> compiler will give you a diagnostic message at compile time.
I can't forget that because if I'm not supposed to access it, its name
would be `_very_interesting_member`. I don't have to wait till compile
time to see that, it is really obvious at the time I write the code to
access it, or decide not to because it is not part of the API.
Ciao,
Marc 'BlackJack' Rintsch
Marc 'BlackJack' Rintsch
> On Jan 30, 12:15 am, Chris Rebert <c...@rebertia.com> 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
Chris Rebert
>> - 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
MRAB
You can also "#define class struct" before including the header file.
The only difference between 'class' and 'struct' in C++ is that the
members of a class are private by default and the members of a struct
are public by default.
thmps...@gmail.com
> On Sat, 31 Jan 2009 15:28:14 -0800, thmpsn.m.k wrote:
> > On Jan 31, 2:27 pm, Christian Heimes <li...@cheimes.de> wrote:
> >> Do you honestly believe that C++'s private members are really private?
> >> Privateness is only enforced during parsing time. Nobody can stop you
> >> from messing around with header files or memory. You can still access
> >> and modify private members but it's all messy and ugly. Even C# and
> >> .NET don't stop you from doing nasty things from unmananged assemblies.
>
> > I don't know how you would do it in C# (or Java for that matter).
>
> In Java you can use reflection to get your fingers on private fields.
>
> > In C++ you can play with pointers to "get at" some memory location
> > somewhere in the object.
> > [Snipped pointer fiddling explanation]
> > So: Sometimes it may work, usually it will be unsafe and/or non-
> > portable, and in most cases the procedure will look complicated.
>
> Or ``#define private public`` before including the header files. Which
> doesn't look complicated to me.
Which again won't always work, if:
(a) the header defines another macro, say, "PRIVATE", as "private",
and uses PRIVATE to declare private members
(b) the members are preceded with neither "private:" nor "public:" nor
"protected:", in which case they'll be private by default
(c) someone else suggested that point (b) is defeated by defining a
macro named "class" as "struct", which will make members public by
default; well, we can do something similar to what we did in point
(a): define a macro, say, "CLASS", as "class", and use CLASS the
define the class
Anyway, it doesn't matter. We're losing the point here. The point is
that language support for private access, by disallowing user access
to private data, provides an unambiguous information hiding mechanism
which encourages encapsulation. Python's approach, however, which is
only a naming convention rather than a language feature, merely TRUSTS
the programmer not to break encapsulation. And sure, if we're all good
programmers, everything will go well and we'll end up with an
organized application. But the danger is still there: at any given
time, we COULD break encapsulation!
Stephen Hansen
Anyway, it doesn't matter. We're losing the point here. The point is
that language support for private access, by disallowing user access
to private data, provides an unambiguous information hiding mechanism
which encourages encapsulation. Python's approach, however, which is
only a naming convention rather than a language feature, merely TRUSTS
the programmer not to break encapsulation. And sure, if we're all good
programmers, everything will go well and we'll end up with an
organized application. But the danger is still there: at any given
time, we COULD break encapsulation!
I was long-winded the last time I responded to this point so no one probably read it :)
But to be concise: So what?
If you believe encapsulation should never be broken: don't do it! If your corporation believes encapsulation should never be broken, the code review process (you do have one right?) will catch it and you can fire the person for not following policy. If your open source project believes encapsulation should never be broken, the code review process (you do have one right?) will catch it and you can chastise for not following policy and reject the patch.
There is no actual "danger".
The convention is unambiguous. If you believe encapsulation should be absolute, you can have that very easily: don't play with anyone else's privates.
The *idea* of encapsulation is good in many cases, it is quite often a solid design point and admirable goal. The *implementation* of enforced data encapsulation brings no value to any realistic situation.
--S
Luis Zarrabeitia
Quoting thmps...@gmail.com:
> > Or ``#define private public`` before including the header files. Which
> > doesn't look complicated to me.
>
> Which again won't always work, if:
>
> (a) the header defines another macro, say, "PRIVATE", as "private",
> and uses PRIVATE to declare private members
[other reasons deleted]
So, can I assume that most of the C++ code out there defines "PRIVATE" as
"private" just to prevent breaking the encapsulation _intentionally_? Somehow I
find that hard to believe.
> Anyway, it doesn't matter. We're losing the point here. The point is
> that language support for private access, by disallowing user access
> to private data, provides an unambiguous information hiding mechanism
> which encourages encapsulation.
And Python, by providing a well defined convention of what is inaccessible,
provides an unambiguous information hiding mechanism wich encourages encapsulation.
> Python's approach, however, which is
> only a naming convention rather than a language feature, merely TRUSTS
> the programmer not to break encapsulation. And sure, if we're all good
> programmers, everything will go well and we'll end up with an
> organized application. But the danger is still there: at any given
> time, we COULD break encapsulation!
And what's the problem with that, exactly? I can break encapsulation... and I
can jump off my roof. Why do _you_ care about what _I_ can do, as long as it
doesn't harm _you_ (or others)?
If you are worried about you breaking encapsulation, then just don't do it. It
is not hard. Whenever you find yourself typing "._somehting", just check that
the string before the dot is "self". If you can't trust yourself to access only
the well identified "public" attributes, how can you trust that you will just
not make "public" a private attribute anyway?
--
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie
Steve Holden
> [...]
> don't play with anyone else's
> privates.
>
> The *idea* of encapsulation is good in many cases, it is quite often a
> solid design point and admirable goal. The *implementation* of enforced
> data encapsulation brings no value to any realistic situation.
>
I think it's noticeable that the people who have been arguing against
what I might tipify as this "libertarian view" are those for whom the
consequences of programming error are serious to extreme.
I think we might have to accept that they are never going to be
comfortable with Python as it's currently constituted, whether or not we
suggest that discipline might replace enforcement.
Just the same, it still doesn't save them from the consequences of
interface miscommunication, as int he case of the Mars lander that
crashed because one module provided a (probably strongly-typed) value in
meters, and the recipient interpreted it as (probably strongly-typed)
feet, cutting the engine out too early.
rdmu...@bitdance.com
> Anyway, it doesn't matter. We're losing the point here. The point is
> that language support for private access, by disallowing user access
> to private data, provides an unambiguous information hiding mechanism
> which encourages encapsulation. Python's approach, however, which is
> only a naming convention rather than a language feature, merely TRUSTS
> the programmer not to break encapsulation. And sure, if we're all good
> programmers, everything will go well and we'll end up with an
> organized application. But the danger is still there: at any given
> time, we COULD break encapsulation!
You, sir, should be programming in some language other than Python.
--RDM
Rhodri James
wrote:
> Stephen Hansen wrote:
>> [...]
>> don't play with anyone else's
>> privates.
>>
> A good rule in life as well as programming.
Unless, of course, you're both consenting adults.
What? Someone had to say it!
--
Rhodri James *-* Wildebeeste Herder to the Masses
Steven D'Aprano
> I think it's noticeable that the people who have been arguing against
> what I might tipify as this "libertarian view" are those for whom the
> consequences of programming error are serious to extreme.
...
> Just the same, it still doesn't save them from the consequences of
> interface miscommunication, as int he case of the Mars lander that
> crashed because one module provided a (probably strongly-typed) value in
> meters, and the recipient interpreted it as (probably strongly-typed)
> feet, cutting the engine out too early.
Of course. Nor will data hiding prevent off-by-one errors, or errors of
logic, or data corruption, or stray cosmic rays flipping bits in memory.
But it will prevent *some* errors. It's one tool in an entire toolbox for
writing correct code, not a magic bullet.
Python already has enforced data hiding, but only for built-ins.
Consequently, anyone who uses a list can absolutely, categorically trust
that len(alist) will return the actual length of alist, and not some
mangled value stuffed into alist by some arbitrary piece of code
somewhere else.
(For those unaware, in CPython lists are arrays. They store the current
length as a private value inaccessible to Python code.)
Short of cosmic rays flipping bits, any built-in list you receive from
anywhere is going to have a valid length, and no pure-Python code can
make it invalid. To read some of the posts in this thread, one would be
forgiven for thinking that this most be a disaster of the highest
consequences, unPythonic to the extreme, an example of unfree B&D
programming so unpleasant to work with that people hate every second of
it.
Except of course it isn't. Nobody sensibly complains that they can't
mangle the length of a list, or move keys around inside dicts, or
whatever. This data hiding is a good thing.
All I want is the ability to do with Python classes what I can do with C
extension types. I don't think that's an *unreasonable* ask, even if it
is *unpractical* given the current design of Python.
--
Steven
Luis Zarrabeitia
> On Sun, 01 Feb 2009 12:31:27 -0500, Steve Holden wrote:
> Except of course it isn't. Nobody sensibly complains that they can't
> mangle the length of a list, or move keys around inside dicts, or
> whatever. This data hiding is a good thing.
If lists and dictionaries were not C types, and python didn't have to shield
us from the mess that is C and its pointers, that enforcement may not be such
a good thing. And, while we are at it, that is not python having "selective"
enforcement of data hiding but only for C, that's C/C++ having data hiding
and not exporting the attributes back to python.
> All I want is the ability to do with Python classes what I can do with C
> extension types. I don't think that's an *unreasonable* ask, even if it
> is *unpractical* given the current design of Python.
Well, then. Do you want dynamic checks? Go fix Bastion/rexec (that would be a
_good_ thing, valuable for way more than data hiding). Or do you want static
checks? In that case, you have it already.
--
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie
Steve Holden
> On Sun, 01 Feb 2009 17:31:27 -0000, Steve Holden <st...@holdenweb.com>
> wrote:
>
>> Stephen Hansen wrote:
>>> [...]
>>> don't play with anyone else's
>>> privates.
>>>
>> A good rule in life as well as programming.
>
> Unless, of course, you're both consenting adults.
>
> What? Someone had to say it!
>
simple pleasure of posting it :)
Steve Holden
> On Sun, 01 Feb 2009 12:31:27 -0500, Steve Holden wrote:
>
>> I think it's noticeable that the people who have been arguing against
>> what I might tipify as this "libertarian view" are those for whom the
>> consequences of programming error are serious to extreme.
> ...
>> Just the same, it still doesn't save them from the consequences of
>> interface miscommunication, as int he case of the Mars lander that
>> crashed because one module provided a (probably strongly-typed) value in
>> meters, and the recipient interpreted it as (probably strongly-typed)
>> feet, cutting the engine out too early.
>
> Of course. Nor will data hiding prevent off-by-one errors, or errors of
> logic, or data corruption, or stray cosmic rays flipping bits in memory.
> But it will prevent *some* errors. It's one tool in an entire toolbox for
> writing correct code, not a magic bullet.
>
> Python already has enforced data hiding, but only for built-ins.
> Consequently, anyone who uses a list can absolutely, categorically trust
> that len(alist) will return the actual length of alist, and not some
> mangled value stuffed into alist by some arbitrary piece of code
> somewhere else.
>
the len() function in __builtins__ with one of their own. There's no
such thing as a foolproof system. The minute you think you have one the
world comes up with a superior class of fool.
> (For those unaware, in CPython lists are arrays. They store the current
> length as a private value inaccessible to Python code.)
>
> Short of cosmic rays flipping bits, any built-in list you receive from
> anywhere is going to have a valid length, and no pure-Python code can
> make it invalid. To read some of the posts in this thread, one would be
> forgiven for thinking that this most be a disaster of the highest
> consequences, unPythonic to the extreme, an example of unfree B&D
> programming so unpleasant to work with that people hate every second of
> it.
>
> Except of course it isn't. Nobody sensibly complains that they can't
> mangle the length of a list, or move keys around inside dicts, or
> whatever. This data hiding is a good thing.
>
> All I want is the ability to do with Python classes what I can do with C
> extension types. I don't think that's an *unreasonable* ask, even if it
> is *unpractical* given the current design of Python.
>
I think the whole issue has received far more attention than is good for
it. Your requirements seem quite reasonable to me, even though I doubt
I'd ever use them. But it isn't *me* you have to persuade to get them in
the language, is it?
Hung Vo
> Anyway, it doesn't matter. We're losing the point here. The point is
> that language support for private access, by disallowing user access
> to private data, provides an unambiguous information hiding mechanism
> which encourages encapsulation. Python's approach, however, which is
> only a naming convention rather than a language feature, merely TRUSTS
> the programmer not to break encapsulation. And sure, if we're all good
> programmers, everything will go well and we'll end up with an
> organized application. But the danger is still there: at any given
> time, we COULD break encapsulation!
>
>
> I was long-winded the last time I responded to this point so no one probably read it :)
Yes, we read it. You made good points!!
Cheers,
Hung
Hendrik van Rooyen
>
> You, sir, should be programming in some language other than Python.
Why? - Python is object oriented, but I can write whole systems
without defining a single class.
By analogy, if data hiding is added to language, I could write a
whole system without hiding a single item.
Conversely, the lack of data hiding is perceived as a weakness,
and IMO harms the advocacy of the language - This is proven
by your statement above, whereby you are driving a user away,
simply because the language, in one small aspect, does not
give him what he wants, and the tenor of this thread has been
very much: "That's how it is - like it or lump it", and no amount
of careful explanation of why people want the feature has cut
any ice - It has all the time been countered with statements
about how the proponents of private attributes "don't need it",
(as if they are plain dumb), that an underscore convention is
"just as good", (It isn't), that you could crack it if you really
tried, (so what?), and other more specious reasons.
This is IMO an arrogant attitude -
Surely if "we are all adults here" we have to accept that the
other man has as much right to get what he wants, as
anybody else, and that his reasons are as valid as those of
anybody else.
Somehow I don't think that the way this thread has run, is
the way to "win friends and influence people" - not
positively, anyway.
- Hendrik
Stephen Hansen
>> You, sir, should be programming in some language other than Python.
>
> Why? - Python is object oriented, but I can write whole systems
> without defining a single class.
> By analogy, if data hiding is added to language, I could write a
> whole system without hiding a single item.
> Conversely, the lack of data hiding is perceived as a weakness,
> and IMO harms the advocacy of the language -
This is an alarming statement.
Advocacy should advocate the language-- it must not define the language.
If a fundamental principle of the language harms the advocacy of the
language: then the problem is not with the language but the advocacy.
If you are going to advocate a thing: advocate that thing. Don't try
to change that thing into what it is not so as to make your advocacy
the end-goal.
One of the reasons I love Python is because its practical first. It
begins with its license, which some people argue allows companies to
steal effort from its developers to use for their own purposes without
contributing back. The Python license is about empowering people to
accomplish things, to do things. It goes further. Guido and the core
developers ask real questions: would this add a burden to practical
use, or would it hinder another practical use?
> This is proven
> by your statement above, whereby you are driving a user away,
> simply because the language, in one small aspect, does not
> give him what he wants, and the tenor of this thread has been
> very much: "That's how it is - like it or lump it", and no amount
> of careful explanation of why people want the feature has cut
> any ice -
I'm missing the careful explanation. What I've heard is that the lack
of enforced encapsulation is "a danger". What I've heard is that
people want it because they've been told they should want it and
believe that. Why?
Part of my lack of understanding might be because people couldn't read
my previous messages because my mail client's configuration
accidentally got fubar'd and I was sending HTML mail instead of plain
text. But my question remains: Why do you need forced encapsulation?
There have been no "careful explanations" to answer that, in my mind.
And thus my response is: the practical possibility of needing access
vastly outweights the theoretical situation that might go bad if
encapsulation wasn't there. Why? Because in any real situation, IMHO,
*forced* encapsulation is pointless.
If you are writing end-level code, you can achieve forced
encapsulation by simply not playing with anyones privates. If you are
in a corporate environment who has rules about accessing privates
written by another team for valid reasons, your policy to not do so
should be enough or your review process should pick it up. If you are
in an open source environment accepting patches from various people,
you should have a clear policy about the subject if you think breaking
encapsulation is never acceptable and refuse the patches. Those who
have commit access and violate encapsulation anyways against your
projects policy are problems that you clearly need to deal with. The
problem is not the language at that point, its the contributor.
> It has all the time been countered with statements
> about how the proponents of private attributes "don't need it",
> (as if they are plain dumb),
They don't need it. No one has shown a *real* reason why. The only
reasons provided are "its a DANGER" that someone "MIGHT DO BAD".
That's not a real reason. If its your project that someone is doing
bad in, this is a situation which can be *clearly* specified in a
projects policy and coding standards and can be *trivially* tested for
with simple static analysis in nearly all cases. The problem is the
person and not the code then. There's *countless* other ways that
person can do bad if you're allowing them to commit blindly anything
into your project.
If its your projet which someone else is using, and accessing your
internals that are clearly private and not documented: its not your
problem if they stab themselves in the foot. On the contrary, why in
the name of all that is holy, do you care if they manipulate your
internals at their own risk, at their own cost, and achieve something
positive for them? How in any way does this hurt you?
> that an underscore convention is
> "just as good", (It isn't),
Why isn't it?
> that you could crack it if you really
> tried, (so what?),
Exactly.. so what? WHY is the convention not enough? What REAL
situation is there that the lack of *forced* encapsulation but policy
based encapsulation not enough?
> Surely if "we are all adults here" we have to accept that the
> other man has as much right to get what he wants, as
> anybody else, and that his reasons are as valid as those of
> anybody else.
Yes., We're all consenting adults.
But if one adult decides to make rules that the other doesn't agree
to, is that consenting adults, or is that rape? I apologize for the
use of the term, but "consenting adults" has particular connotations
that seem to apply very well here, in the context of that expression.
Forced encapsulation allows one party to make absolute rules and hold
absolute authority over another party.
If you believe that encapsulation should never be broken: do not break it.
If your organization, corporation or project believes that
encapsulation should never be broken: specify that it must not be
done. Your review process (you do have one, right?) will pick it up
and you can very quickly deal with the situation.
Encapsulation is a very, very good thing in general: but it is a
question of *design* and not *implementation*. Python allows EVERYONE
who wants encapsulation to HAVE it. Not forced encapsulation, but
encapsulation. If you're producing a product in Python on your own
simple policy and trivial review (even -automated- review; it is NOT
hard to tell that "other._private" is not "self._private") provides
encapsulation. If you're making a library for others to use, there is
no valid reason for you to care if they screw with your internals.
Really. I just don't get the problem. It seems to me that people who
want this in Python will never be happy *in* Python. Its a very deep
fundamental feature that Python exposes everything it can, even things
that are potentially dangerous like sys._getframe. Recently on
Python-dev(note: I only lurk) someone was working on a debugger and
they were told in that situation it was OK to access a private member
of sys to achieve an end: exposing that internal to general use just
had no value. That's the Python Way. People can dig into things,
classes, functions, and screw around in wild ways if they want to.
That *is* what Python is. 95% of code by 95% of people won't ever go
there, but its there. To remove it means its *not* Python.
--S
Bruno Desthuilliers
> Steve Holden wrote:
>> You can think what you like, but there is a fundamental difference
>> between methods of a class and functions of a module. Until you
>> appreciate that you will likely make mistakes. Don't worry, though, we
>> all learn from our mistakes.
>
> And this fundamental difference is?
That a method is bound to a class and (usually) an instance of this class.
> From what I can tell an instance method is an object that encapsulates
> the function object in a closure
s/closure/object/
> that makes sure it has a reference to
> "self."
the method object is instanciated by the function object itself when it
is looked up upon a class or instance (thanks to the descriptor
protocol). It (the method object) stores the function, the class and (if
bound) the instance as attributes, and it's __call__ method takes care
of calling the function with the instance as first positional argument.
> I know that you dynamically add functions to objects creating
> methods dynamically, by using new.instancemethod or something.
Or simply by manually invoking the descriptor protocol:
def func(self):
print "self is", self
class Foo(object):
pass
f = Foo()
f.func = func.__get__(f, type(f))
print dir(f.func)
>
> This seems to indicate to me that there are functions and there are
> functions. Methods are in fact functions, just with a callable wrapper
> around them.
Methods *are* the callable wrapper around functions - so they can't be
functions themselves. From this POV, the functions wrapped by methods
are actually the *implementation* of the method.
Bruno Desthuilliers
(snip)
> Anyway, it doesn't matter. We're losing the point here. The point is
> that language support for private access, by disallowing user access
> to private data, provides an unambiguous information hiding mechanism
> which encourages encapsulation. Python's approach, however, which is
> only a naming convention rather than a language feature, merely TRUSTS
> the programmer not to break encapsulation. And sure, if we're all good
> programmers, everything will go well and we'll end up with an
> organized application. But the danger is still there: at any given
> time, we COULD break encapsulation!
Oh, my, What a shock! What a nightmare. Thanks, thanks thmpsn for
opening our eyes. How can we have lived so many years with this
permanent danger, and yet managed to write working, robust programs, I
really wonder. Good God, we really need to fix this immediatly, because
obviously, TRUSTING the programmer JUST CANT WORK.
Or can it ?
this-dead-horse-has-been-beaten-to-hell-and-back-pity-the-poor-animal-ly'yrs
Bruno Desthuilliers
> On Sun, 01 Feb 2009 17:31:27 -0000, Steve Holden <st...@holdenweb.com>
> wrote:
>
>> Stephen Hansen wrote:
>>> [...]
>>> don't play with anyone else's
>>> privates.
>>>
>> A good rule in life as well as programming.
>
> Unless, of course, you're both consenting adults.
>
> What? Someone had to say it!
>
Hendrik van Rooyen
8<----------- arguments for the status quo ------
Repeating it, (despite my assertion lately in another thread) does not
make it true - what follows is simply an opinion on how to solve
the problem "by management", instead of providing a different tool.
> reasons provided are "its a DANGER" that someone "MIGHT DO BAD".
> That's not a real reason. If its your project that someone is doing
> bad in, this is a situation which can be *clearly* specified in a
> projects policy and coding standards and can be *trivially* tested for
> with simple static analysis in nearly all cases. The problem is the
> person and not the code then. There's *countless* other ways that
> person can do bad if you're allowing them to commit blindly anything
> into your project.
>
> If its your projet which someone else is using, and accessing your
> internals that are clearly private and not documented: its not your
> problem if they stab themselves in the foot. On the contrary, why in
> the name of all that is holy, do you care if they manipulate your
> internals at their own risk, at their own cost, and achieve something
> positive for them? How in any way does this hurt you?
>
>
> > that an underscore convention is
> > "just as good", (It isn't),
>
> Why isn't it?
Because it needs human intervention.
>
> > that you could crack it if you really
> > tried, (so what?),
>
> Exactly.. so what? WHY is the convention not enough? What REAL
> situation is there that the lack of *forced* encapsulation but policy
> based encapsulation not enough?
>
See human intervention above - and as for
"real, forced data hiding" - have you ever
coded anything that produced a segmentation fault?
I wonder why the designers of processors do such silly things as having
user and supervisor modes in the hardware - according to your
arguments a code review would solve the problem, and then they
could use the silicon saved to do other usefull stuff. - then any process
could use any instruction, and it would be all right. - easy to manage
out of the project - you just have to scan the object code for op codes
that you have decided are dangerous (for whatever stupid reason).
Another example out of the processor world is the fact that some
modern processors actually force a process to keep in its own
memory. What temerity! Who do these idiots think they are
to try to keep "me" from accessing "your" memory - after all,
I have a good reason - (I'm inquisitive)
This is of course rather more difficult to pick up in a code review,
as I could easily calculate the address, which makes it not
immediately apparent that I will access something not belonging
to me. And seeing that Python is not dynamic at all, there is
no analogy here...
> > Surely if "we are all adults here" we have to accept that the
> > other man has as much right to get what he wants, as
> > anybody else, and that his reasons are as valid as those of
> > anybody else.
>
> Yes., We're all consenting adults.
>
> But if one adult decides to make rules that the other doesn't agree
> to, is that consenting adults, or is that rape? I apologize for the
> use of the term, but "consenting adults" has particular connotations
> that seem to apply very well here, in the context of that expression.
>
> Forced encapsulation allows one party to make absolute rules and hold
> absolute authority over another party.
>
I do not agree with this. If _I_ write a module, and _I_ use forced
encapsulation for _my_ purposes ( however misguided you might
think I am) then how does that affect _you_?
Even if I release the thing into the wild - you do not have to use it
if you feel you really *must* muck around with the equivalent
of Steve D'A's example of the length of a builtin - you could write
your own, or fork what I have done. - It seems that by denying me
the use of such a feature, you are the one trying to make absolute
rules, for *your* benefit - *you* want to use *my* stuff, on *your*
terms, without having to bother to put any effort into it.
8<----- repeat of "code review cures all" argument ------
> Really. I just don't get the problem. It seems to me that people who
> want this in Python will never be happy *in* Python. Its a very deep
> fundamental feature that Python exposes everything it can, even things
> that are potentially dangerous like sys._getframe. Recently on
> Python-dev(note: I only lurk) someone was working on a debugger and
> they were told in that situation it was OK to access a private member
> of sys to achieve an end: exposing that internal to general use just
> had no value. That's the Python Way. People can dig into things,
> classes, functions, and screw around in wild ways if they want to.
> That *is* what Python is. 95% of code by 95% of people won't ever go
> there, but its there. To remove it means its *not* Python.
Now there are a LOT of dicey statements in the above passionate
plea - python is a language, and not a philosophy, but I won't go
into that, as that would lead off onto a tangent, of which there have
been a surfeit in this thread.
But this needs addressing:
Nobody is saying that "Python" should change the way "Python"
exposes stuff - All that is being requested that *I* should be
allowed to use python to expose as much of *my* class as *I*
deem fit, for *my* purposes.
And some form of "private" keyword would do that nicely,
thank you, and keep the current "public" default unchanged.
Now this is from a user perspective - It may prove to be
difficult, if not impossible, to implement in CPython. I just
don't know enough details of the implementation to be able
to tell.
Maybe what is needed is some form of *Interpreter* vs.
*User* state, analogous to what is done in the hardware,
with defined, "code reviewable, testable for", procedures
for switching between one and the other.
- Hendrik
Diez B. Roggisch
> user and supervisor modes in the hardware - according to your
> arguments a code review would solve the problem, and then they
> could use the silicon saved to do other usefull stuff. - then any process
> could use any instruction, and it would be all right. - easy to manage
> out of the project - you just have to scan the object code for op codes
> that you have decided are dangerous (for whatever stupid reason).
This is comparing apples to oranges. Forced data encapsulation or not take
place *inside one process*. So this whole argument is a straw-man.
I've seen a lot of programs segfault that are written in C++ with data
encapsulation. And also a lot of them that overcame the restrictions the
compiler or even runtime in java imposed on them, either by pointer-magic,
or through some available backdoors that have been put in place for good
reasons.
So far I haven't seen any argument for forced data encapsulation that went
beyond a matter of personal taste. That's fine, but also just that.
Diez
rdmu...@bitdance.com
> <rd.....murray@bitdance.com> wrote:
>
> >
> > You, sir, should be programming in some language other than Python.
>
> Why? - Python is object oriented, but I can write whole systems
> without defining a single class.
> By analogy, if data hiding is added to language, I could write a
> whole system without hiding a single item.
> Conversely, the lack of data hiding is perceived as a weakness,
> by your statement above, whereby you are driving a user away,
> simply because the language, in one small aspect, does not
> give him what he wants, and the tenor of this thread has been
> very much: "That's how it is - like it or lump it", and no amount
> of careful explanation of why people want the feature has cut
> about how the proponents of private attributes "don't need it",
> "just as good", (It isn't), that you could crack it if you really
> tried, (so what?), and other more specious reasons.
>
> This is IMO an arrogant attitude -
My apologies!! There was a smiley missing from the end of that statement
above. However, you are right, even with the smiley added it would
still be arrogant, and I regret that.
The problem is that there is a fundamental philosophical divide here,
and I don't think the advocates on either side are going to convince
the other.
This debate has happened many times.
--RDM
rdmu...@bitdance.com
> plea - python is a language, and not a philosophy, but I won't go
> into that, as that would lead off onto a tangent, of which there have
> been a surfeit in this thread.
Ah, now I understand. This is where you part company from the
people you are arguing against.
Python _is_ a philosophy.
There is no smiley after that statement. :)
--RDM
PS: More accurately, Python _embodies_ a philosophy, and to advocate
changes that go against that philosophy is to advocate changing
Python into something that would no longer be Python. You can do
that, but you aren't likely to get the community to follow you.
Hendrik van Rooyen
> Quoth "Hendrik van Rooyen" <ma...@microcorp.co.za>:
> > <rd.....murray@bitdance.com> wrote:
> >
> > >
> > > You, sir, should be programming in some language other than Python.
8<------------- reasons given ----------------
> > This is IMO an arrogant attitude -
>
> My apologies!! There was a smiley missing from the end of that statement
> above. However, you are right, even with the smiley added it would
> still be arrogant, and I regret that.
It was not actually aimed at you personally - more of a rant about
the intolerance displayed by the "it's fine as it is" group.
>
> The problem is that there is a fundamental philosophical divide here,
> and I don't think the advocates on either side are going to convince
> the other.
It certaintly looks like that - so far it has produced more heat than
light, and very few funny comments
>
> This debate has happened many times.
>
So why are we dumb enough to repeat it?
:-)
- Hendrik
Hendrik van Rooyen
Hendrik van Rooyen
Hendrik:
> > I wonder why the designers of processors do such silly things as having
> > user and supervisor modes in the hardware - according to your
> > arguments a code review would solve the problem, and then they
> > could use the silicon saved to do other usefull stuff. - then any process
> > could use any instruction, and it would be all right. - easy to manage
> > out of the project - you just have to scan the object code for op codes
> > that you have decided are dangerous (for whatever stupid reason).
>
> This is comparing apples to oranges. Forced data encapsulation or not take
> place *inside one process*. So this whole argument is a straw-man.
I do not agree with this, but then I won't will I?
The reason is that I see a level of abstraction that makes it kind of
irrelevant whether something is run as a process, a thread, a time
multiplexed mainloop, on one or more processors, wherever or
whatever - almost like a fractal structure spread across the total
addressable space - and I would like to use the same rules
everywhere. And if there are reasons for forced encapsulation
*somewhere*, then it is more elegant (to my taste) to allow it
*everywhere*. - and conversely, of course. Hence the rather
*an der Haare herbeigezogen* (see ** below) argument
based on the forced restrictions in processors.
I see almost any piece of code that "does something" as a black
box that has inputs and outputs - and I like to string them together
in a style that resembles a systolic array - closer to unix piping ,
based on true queueing and message passing, where it becomes
at all practical.
Given this approach, there is no reason whatever for anything
to mess with any other thing's innards - in fact the less you know
about it, the more robust and predictable the system becomes.
And in embedded processes, there exist things that are time
critical, that are designed to be used in one way, and no other,
and that can have serious consequences if messed with- when
I have started moving the 100 tonne mass, then I *cannot* tolerate
other code changing my timeouts or speeds or feeds in an arbitrary
fashion - EXPENSIVE noises will result.
> I've seen a lot of programs segfault that are written in C++ with data
> encapsulation. And also a lot of them that overcame the restrictions the
> compiler or even runtime in java imposed on them, either by pointer-magic,
> or through some available backdoors that have been put in place for good
> reasons.
I think that segfaulting is basically caused by programming error -
By the inability of the programmer actually to understand the
limitations of the compiler to "do what I mean".
Encapsulation or data hiding will never "cure" that, because
at best it could move some of the errors from runtime to
compile time.
I doubt the "good reasons for backdoors" part - I think that comes
from a design that has either not been done, or used, at the correct
level of granularity.
> So far I haven't seen any argument for forced data encapsulation that went
> beyond a matter of personal taste. That's fine, but also just that.
This could be true, and if it is, we are just beating our heads one against
the other, trying to win non existent prizes for pig-headedness.
I could also turn that argument around, as well as stating it stronger:
So far I have not seen any argument in favour of free access to
the internals of another piece of code that is based on ANY necessity,
(beside a handwaving "good reasons" ) or that goes beyond a matter
of personal taste based on a hacker's glee in meddling in somebody
else's code.
:-)
- Hendrik
** -*an der Haare herbeigezogen* German, literally "drawn closer by the hair"
expression denoting either a specious argument or a forced analogy. Sorry,
but I could think of no English equivalent.
thmps...@gmail.com
> > This is proven
> > by your statement above, whereby you are driving a user away,
> > simply because the language, in one small aspect, does not
> > give him what he wants, and the tenor of this thread has been
> > very much: "That's how it is - like it or lump it", and no amount
> > of careful explanation of why people want the feature has cut
> > any ice -
>
> I'm missing the careful explanation. What I've heard is that the lack
> of enforced encapsulation is "a danger". What I've heard is that
> people want it because they've been told they should want it and
> believe that. Why?
Who has said the latter? Are you just trying to spread FUD?
> There have been no "careful explanations" to answer that, in my mind.
> And thus my response is: the practical possibility of needing access
> vastly outweights the theoretical situation that might go bad if
> encapsulation wasn't there. Why? Because in any real situation, IMHO,
> *forced* encapsulation is pointless.
I think you've gotten too subjective on this matter. You might as well
say that we don't need no stinkin' OOP, we could all just be
programming with goto's.
Sure, hey, let's do OOP in C, using structs, POD STRUCTS (!!!!), and
PLAIN FUNCTIONS (!!!!) !!!!
Heck, why do we even need OOP?? Long live procedural!!
We don't even need no stinkin programming languages, we could just
program using 1's and 0's!!!!!!!!!
What's with this luddite attitude, Python community?
> > It has all the time been countered with statements
> > about how the proponents of private attributes "don't need it",
> > (as if they are plain dumb),
>
> They don't need it. No one has shown a *real* reason why. The only
> reasons provided are "its a DANGER" that someone "MIGHT DO BAD".
> That's not a real reason. If its your project that someone is doing
> bad in, this is a situation which can be *clearly* specified in a
> projects policy and coding standards and can be *trivially* tested for
> with simple static analysis in nearly all cases. The problem is the
> person and not the code then. There's *countless* other ways that
> person can do bad if you're allowing them to commit blindly anything
> into your project.
Aha! I see this attitude quite often among C/C++ people, regarding
buffer overflows and uninitialized pointer dereferences: someone will
say "C and C++ are unsafe languages because they allow you to overrun
buffers", then a C/C++ zealot will respond "Hire some good
programmers".
SAME ATTITUDE.
Bruno Desthuilliers
> On Feb 2, 2:55 am, Stephen Hansen <apt.shan...@gmail.com> wrote:
>>> This is proven
>>> by your statement above, whereby you are driving a user away,
>>> simply because the language, in one small aspect, does not
>>> give him what he wants, and the tenor of this thread has been
>>> very much: "That's how it is - like it or lump it", and no amount
>>> of careful explanation of why people want the feature has cut
>>> any ice -
>> I'm missing the careful explanation. What I've heard is that the lack
>> of enforced encapsulation is "a danger". What I've heard is that
>> people want it because they've been told they should want it and
>> believe that. Why?
>
> Who has said the latter? Are you just trying to spread FUD?
>
>> There have been no "careful explanations" to answer that, in my mind.
>> And thus my response is: the practical possibility of needing access
>> vastly outweights the theoretical situation that might go bad if
>> encapsulation wasn't there. Why? Because in any real situation, IMHO,
>> *forced* encapsulation is pointless.
>
> I think you've gotten too subjective on this matter.
>
> You might as well
> say that we don't need no stinkin' OOP, we could all just be
> programming with goto's.
>
> Sure, hey, let's do OOP in C, using structs, POD STRUCTS (!!!!), and
> PLAIN FUNCTIONS (!!!!) !!!!
Aren't you going a bit over the board here ? No need to go mad nor
scream at us.
(snip usual stuff about lack of access restriction perceived as
dangerous or whatever - cargo cult, really...).
Diez B. Roggisch
> irrelevant whether something is run as a process, a thread, a time
> multiplexed mainloop, on one or more processors, wherever or
> whatever - almost like a fractal structure spread across the total
> addressable space - and I would like to use the same rules
> everywhere. And if there are reasons for forced encapsulation
> *somewhere*, then it is more elegant (to my taste) to allow it
> *everywhere*. - and conversely, of course. Hence the rather
> *an der Haare herbeigezogen* (see ** below) argument
> based on the forced restrictions in processors.
Your argument would be valid if *any* of the *languages* implementing
encapsulation would offer that real isolation. None does. So where from
comes the feeling that this must be something a *language* should offer?
Sure one could envision a system where each object is running in it's
micro-process. So far, this hasn't been implemented (to the best of my
knowledge) - so making assertions about the feasibility & robustness for
running as well as for developing are somewhat "airy", don't you think?
> Given this approach, there is no reason whatever for anything
> to mess with any other thing's innards - in fact the less you know
> about it, the more robust and predictable the system becomes.
For a certain, very limited definition of robustness & predictability.
As much as I like my OS not to go down, it's nothing that helps me to
accomplish my actual goal using it if the software running on top of it
crashes. From this POV, a chain is always only as strong as it's weakest
member. And that might well be one of your encapsulated components.
> And in embedded processes, there exist things that are time
> critical, that are designed to be used in one way, and no other,
> and that can have serious consequences if messed with- when
> I have started moving the 100 tonne mass, then I *cannot* tolerate
> other code changing my timeouts or speeds or feeds in an arbitrary
> fashion - EXPENSIVE noises will result.
Embedded programming most often even offers the memory protection one needs
to make the "real" encapsulation, due to hardware restrictions.
And even if it did, it won't help you with memory corruption that occurs in
process. Which is of course a re-iteration of my argument.
Again: the expensive noises haven't been avoided because of encapsulation.
They might be the product of expensive testruns, either by trial-and-error,
or by review. Not by encapsulation.
>> I've seen a lot of programs segfault that are written in C++ with data
>> encapsulation. And also a lot of them that overcame the restrictions the
>> compiler or even runtime in java imposed on them, either by
>> pointer-magic, or through some available backdoors that have been put in
>> place for good reasons.
>
> I think that segfaulting is basically caused by programming error -
> By the inability of the programmer actually to understand the
> limitations of the compiler to "do what I mean".
>
> Encapsulation or data hiding will never "cure" that, because
> at best it could move some of the errors from runtime to
> compile time.
>
> I doubt the "good reasons for backdoors" part - I think that comes
> from a design that has either not been done, or used, at the correct
> level of granularity.
>
>> So far I haven't seen any argument for forced data encapsulation that
>> went beyond a matter of personal taste. That's fine, but also just that.
>
> This could be true, and if it is, we are just beating our heads one
> against the other, trying to win non existent prizes for pig-headedness.
>
> I could also turn that argument around, as well as stating it stronger:
>
> So far I have not seen any argument in favour of free access to
> the internals of another piece of code that is based on ANY necessity,
> (beside a handwaving "good reasons" ) or that goes beyond a matter
> of personal taste based on a hacker's glee in meddling in somebody
> else's code.
The argument as apparent in Python: ducktyping is used everyday, to all our
benefit. And every piece of code that only works precisely because it was
possible to access the innards of some other piece of code is an example
and a reason to allow it.
You might say that these things are showing a lack of proper design - but
the point is that design is a question of perspective, and a otherwise
useful piece of code is rendered useless because of encapsulation if that
prevents the usage from a new perspective the original author didn't think
of.
That's my stance on this, and as a coder, I want to (re)use code, not work
around it.
Diez
Russ P.
I couldn't agree more.
As I said before, as an aeronautical engineer I don't know if enforced
access restriction can be added to Python without compromising or
unduly complicating the language. Maybe it can't. If that's the case,
then people should make that argument. But just saying that enforced
access restriction is useless in general is nonsense. Are we supposed
to believe that the designers of C++, Java, Ada, and Scala are all
idiots?
Several participants here keep repeating that the leading-underscore
convention is perfectly adequate. Aside from the aesthetic problem of
littering code with leading underscores, let me try to explain the
problem with leading underscores.
Suppose a library developer (or a module developer on a large team)
uses leading underscores. Now suppose that, for whatever reason
(pressure from the users, perhaps), the library developer decides to
change a "private" attribute to public. Now all occurrences of the
identifier need to be changed. If an assignment to the previously
"private" attribute is missed, no warning will be issued (because
Python allows new attributes to be added anywhere, even completely
outside the class definition itself). And if the library is widely
used, the probability of such bugs occurring is very high.
If a "private" keyword (or equivalent) were available, then the change
would need to be made in only one location rather than at every
occurrence off the identifier. That is much less error prone. Sure,
you can argue (as I'm sure someone will) that the users of the library
should be more careful. Yes they should, but why not let the language
help with such low-level details. That's what high-level languages are
for.
Several people have argued that an advantage of the leading-underscore
convention is that it tells you at every occurrence of the identifier
that it is private. Of course, the leading-underscore convention could
still be used even in combination with enforced access restriction.
But the larger point is this: that is like saying that global
parameters should be repeated as literal numbers at every occurrence
so the user can see the value instantly. Sure, that saves you the
trouble of looking up the value when you need to know it, but it also
requres that any change must be carefully made at every location. No
competent programmer would argue in favor of that.
Tim Rowe
> Are we supposed
> to believe that the designers of C++, Java, Ada, and Scala are all
> idiots?
No, we're supposed to believe that the designers of C++, Java, Ada,
and Scala are all designers of languages that are not Python. If all
languages had the same philosophy what would be the point of different
languages? Is it worth mentioning (again) that Python is not Java?
--
Tim Rowe
Luis Zarrabeitia
> As I said before, as an aeronautical engineer I don't know if enforced
> access restriction can be added to Python without compromising or
> unduly complicating the language. Maybe it can't. If that's the case,
> then people should make that argument. But just saying that enforced
> access restriction is useless in general is nonsense. Are we supposed
> to believe that the designers of C++, Java, Ada, and Scala are all
> idiots?
I'm amazed at how quickly this thread degenerated into another 'enforced data
hiding' thread. I think the previous one ran long enough for me to actually
say that 'access restriction is nonsense', when my point had been '_enforced_
access restrictions in python is worthless in all the examples provided so
far' (except perhaps the extensions modules, but those are not python).
You are an aeronautical engineer. You, and I understand that, don't want,
shouldn't want, and will not want to run anything you cannot trust. You want
the most assurances you can get. You are well within your right to want
that - to disallow in your systems, and in the systems that you build,
anything that you even suspect that may threaten the integrity of the system,
and let's face it, breaking the encapsulation, intentional or not, is pretty
suspicious.
So, in current python, _you_ have the _choice_ of preventing it. As the checks
are static, of course, you can break them in runtime, just like you would in
C, C++ and Java.
But somehow, it is not enough for you that you have the choice, because that
also gives _me_ the choice of _not_ doing it in my own systems. And you still
haven't said why it bothers you that I have the choice.
Now, if you were arguing for [truly optional - as in, the user decides]
dynamic checks, you may see a very different position. That RExec and Bastion
even existed should tell you that there is interest on implementing some kind
of trusted execution (as in 'I trust this code to do whatever it wants, but
not this other code'). That both projects failed should tell you that either
it is impossible to achieve in python (which would be bad), or that there is
just not enough interest on keeping them (which would not amaze me). But, if
you are arguing for dynamic checks, those are not present in C++ either, and
thus, it isn't really what you mean with enforced data hiding.
> If an assignment to the previously
> "private" attribute is missed, no warning will be issued (because
> Python allows new attributes to be added anywhere, even completely
> outside the class definition itself). And if the library is widely
> used, the probability of such bugs occurring is very high.
Good coding standards would prevent that. And by good coding standards, I
mean "treat pylint and similar tools as a requirement before executing any
code", and it will catch that sort of bugs. Again, _you_ have the choice. Use
it if you wish.
Now, I'm with you in that accidental variable creation is a nasty side effect
of python dynamism (and that you may be forfeiting it if you go the pylint
route). But that particular complaint has nothing to do with enforced vs
not-enforced data hiding, and everything to do with static typing. And mind
you, must of us who use python, do so _because_ of the dynamism and not in
spite of it.
Funny thing is, you have the choice, _now, today_, of having your precious
static checks, both of them, for your projects. But you keep complaining
because I also have the choice, and I may chose not to have them.
Russ P.
> 2009/2/2 Russ P. <Russ.Paie...@gmail.com>:
I am not sure why people keep "mentioning" that "Python is not Java."
As a slogan, it is rather misleading. Python is not C++, Ada, or Scala
either. All of those languages have enforced access restriction. Why
only mention Java?
For the record, I have never used Java, nor do I have any desire to
ever use it. That is why I am intrigued by the apparent obsession with
it here. I suspect that many programmers are forced to use against
their wishes. If that's the case, you have my sympathies, but let's
not pretend that Java is the only popular OO language with enforced
access restrictions.
Tim Rowe
> On Feb 2, 2:46 pm, Tim Rowe <digi...@gmail.com> wrote:
>> No, we're supposed to believe that the designers of C++, Java, Ada,
>> and Scala are all designers of languages that are not Python. If all
>> languages had the same philosophy what would be the point of different
>> languages? Is it worth mentioning (again) that Python is not Java?
>>
>> --
>> Tim Rowe
>
> I am not sure why people keep "mentioning" that "Python is not Java."
Because Java is the language that folks most offen insist Python become like.
> As a slogan, it is rather misleading. Python is not C++, Ada, or Scala
> either. All of those languages have enforced access restriction. Why
> only mention Java?
You might notice that I also mentioned C++, Ada and Scala.
> their wishes. If that's the case, you have my sympathies, but let's
> not pretend that Java is the only popular OO language with enforced
> access restrictions.
You might notice (again) that I also mentioned C++, Ada and Scala.
--
Tim Rowe
Rhodri James
<ma...@microcorp.co.za> wrote:
> <r...ray@bi...nce.com> wrote:
>> PS: More accurately, Python _embodies_ a philosophy, and to advocate
>> changes that go against that philosophy is to advocate changing
>> Python into something that would no longer be Python. You can do
>> that, but you aren't likely to get the community to follow you.
>
> *sits on his hands to try to avoid the tangent, with the gaping hole of
> religion
> looming beneath the spiderweb of philosophy, and the language spec
> gathering
> dust in the corner, forgotten and forlorn*
This really, really, *really* isn't a tangent. It's the heart of
the matter. You are advocating a change that doesn't fit with
Python's "consenting adults" approach to programming. It's trivial
to enforce hiding using static checking tools if you really feel the
need to not trust yourself; it's much harder (though by no means
impossible) to break language-enforced hiding when (not if) an
interface turns out to be inadequate.
--
Rhodri James *-* Wildebeeste Herder to the Masses
Mark Wooding
> I am not sure why people keep "mentioning" that "Python is not Java."
> As a slogan, it is rather misleading. Python is not C++, Ada, or Scala
> either. All of those languages have enforced access restriction. Why
> only mention Java?
Because Java is a well-known member of a family of object-oriented
languages (or at least languages supporting object-oriented
programming). `Python is not Java' is somewhat of a slogan, intended to
convey the message that Python, quite intentionally, does not behave in
the same way as other languages you may be familiar with.
Smalltalk's visibility features are very different from C++ and Java: a
method can mess with its own object's (i.e., the recipient of the
message which caused the method to be invoked) instance variables but no
others -- a restriction enforced syntactically, since there is simply no
way of referring to a different instance's variables. There is no
restriction whatever on sending messages to other objects. Self
abandons the concept of instance variable (and of class, for that
matter), and access controls with it.
The Common Lisp Object System provides no access control features
(though one could probably implement some using the MOP, were one
sufficiently motivated); however, CL's package system is better placed
for this job anyway. Other object systems for Lisp-family languages
tend to be similar. The Lisp Machine's Flavors -- the first object
system with multiple inheritance -- relied on the package system for
access control; CLOS-like systems for Scheme, which lacks packages, tend
not to bother at all. (The package system controls the mapping from
tokens read from, say, files to symbols; packages can export some of
their symbols, so you can refer to, say, MDW:FOO if package MDW exports
symbol FOO, or you can `use' package MDW in your own package to make FOO
refer to MDW:FOO. The package system tries to keep you honest rather
than acting as an enforcement mechanism: even if MDW doesn't export BAR,
you can still talk about MDW::BAR -- note the double-colon -- as much as
you like. Working at the name-to-symbol level allows the package system
to operate uniformly on all the various namespaces in Lisp.)
Perl's object system provides no access controls. Ruby does, following
Simula, though it uses C++-ish `private' for Simula's `hidden'.
> If that's the case, you have my sympathies, but let's not pretend that
> Java is the only popular OO language with enforced access
> restrictions.
No, but let's not pretend either that such features are essential to
object orientation, or that they are even typical of object systems
outside of a particular (admittedly popular) subfamily.
-- [mdw]
Russ P.
> This really, really, *really* isn't a tangent. It's the heart of
> the matter. You are advocating a change that doesn't fit with
> Python's "consenting adults" approach to programming. It's trivial
> to enforce hiding using static checking tools if you really feel the
> need to not trust yourself; it's much harder (though by no means
> impossible) to break language-enforced hiding when (not if) an
> interface turns out to be inadequate.
Here we go again. If you have access to the source code (as you nearly
always do with Python code), then "breaking the language-enforced data
hiding" is a trivial matter of deleting the word "private" (or
equivalent).
I know ... changing one word constitutes a "fork." Yeah, right. You
can't be bothered to change one word, but the library developer should
be required to litter his code with leading underscores everywhere,
and large development teams should depend on labor intensive code
reviews for checks that could be automated by the language. (And,
please ... I am not suggesting that enforced access restrictions would
render code reviews unnecessary, but it could certainly simplify
them.)
Grant Edwards
> I am not sure why people keep "mentioning" that "Python is not
> Java." As a slogan, it is rather misleading.
Because other people keep insisting that it ought to be.
> Python is not C++, Ada, or Scala either. All of those
> languages have enforced access restriction. Why only mention
> Java?
It's often mentioned that Python is not C++ as well.
People who know Ada or Scala presumably have a varied enough
background that they find no need insist that all languages
must do things the same way as language X does.
--
Grant
Rhodri James
> Here we go again. If you have access to the source code (as you nearly
> always do with Python code), then "breaking the language-enforced data
> hiding" is a trivial matter of deleting the word "private" (or
> equivalent).
If it's that trivial to defeat something that its proponents appear to
want to be close to an iron-clad guarantee, what on earth is the point
of using "private" in the first place?
Luis Zarrabeitia
Quoting "Russ P." <Russ.P...@gmail.com>:
> I know ... changing one word constitutes a "fork." Yeah, right.
Yeah, right.
> You can't be bothered to change one word, but the library developer should
> be required to litter his code with leading underscores everywhere,
No, instead they will have to litter his code with "private" keywords.
(So now this is about laziness and not wanting to type "_"? The argument gets
weirder and weirder)
> and large development teams should depend on labor intensive code
> reviews for checks that could be automated by the language.
Or, by already existing third party tools that you insist on ignoring.
> (And, please ... I am not suggesting that enforced access restrictions
> would render code reviews unnecessary, but it could certainly simplify
> them.)
Please, tell, how does it having the checks on the interpreter will simplify
them more than having the checks on an external tool?
--
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie
Russ P.
If a library developer releases the source code of a library, any user
can trivially "defeat" the access restrictions. But if a team of
developers is checking in code for a project, the leader(s) of the
project can insist that the access restrictions be respected to
simplify the management of interfaces. The larger the team, the more
useful that can be. That's why Java, C++, Ada, Scala, and other
languages have a "private" keyword.
David Cournapeau
I think a lof of this "discussion" is caused by different usages of
private. My understanding is that you think private is missing in
python because there is no clear different between a member which is
published (part of the API) and one which is not (e.g. whose behavior
may change between different revisions, even minor). I agree the
underscore is not an ideal solution - it is certainly not followed by
all python code out there (not even in python itself - see distutils
for example).
But I think you are overstating the advantage of private for that
usage, at least for C++. In C++, if you have a public class in a
header:
class Foo {
private:
int f;
};
It means f is private (cannot be accessed outside Foo instances), but
it is declared in the public header. Actually, when people means this
kind of 'data-hiding', C++ does not bring anything to C itself - after
all, we have used FILE* for years and I have no idea about the FILE
structure.
Maybe I still lack experience, but I find neither _ prefixing nor
private/public/protected a satisfaying way to make clear what is
public API and what is not. In particular, if I have a python package
which does not use _ at all, shall I assume everything is public ?
cheers,
David
Hendrik van Rooyen
8< --------- arguments I don't agree with -------------
>P.S. Aiee, this discussion is getting overwhelmingly long. :)
It is indeed and I do actually have other stuff to do so I shall
try to retreat with defiant dignity.
Been fun though, to see the other viewpoints when it started
getting serious.
:-)
- Hendrik
Hendrik van Rooyen
"Diez B. Roggisch" <de...@nospam.web.de>
> Your argument would be valid if *any* of the *languages* implementing
> encapsulation would offer that real isolation. None does. So where from
> comes the feeling that this must be something a *language* should offer?
>
> Sure one could envision a system where each object is running in it's
> micro-process. So far, this hasn't been implemented (to the best of my
> knowledge) - so making assertions about the feasibility & robustness for
> running as well as for developing are somewhat "airy", don't you think?
No. Not airy. Hairy, yes.
I suppose the language is a kind of wish list on my part -
I have spent the last twenty years or so writing stuff like this
on small processors, in assembler, and I would have loved a
language that supported it, as well as an operating system
(and I do not mean stuff like tiny os and others of that ilk),
but one that really supported fast task switching to make
the micro tasks less expensive on cheap little processors
with scarce resources. (8031) I have written various flavours
of my own, (pre emptive, round robin, cooperative) and they
all suffer from the speed troubles associated with task
switching on that architecture, but in all cases the performance
was good enough to get the job done.
Most of the stuff really did follow a dataflow model
as I have described, but its all so inextricably intertwined
with the hardware and the requirements of the different
jobs that it feels kind of hopeless to try to extract general
principles from it, except for obvious stuff like that it works
better if your queues are formal and robust, and that the
messages must contain everything that is required to get
the job done. If you do this, then there is really no reason
to worry about how some other thing is doing it's job.
In fact if you find yourself peeking at the other task's
innards, then it means you have to rethink the dataflow,
because you are on the wrong track - that is what I meant
when I talk of "granularity"
I have find that code re use, between different projects,
has in my case been limited to some parts of:
- Task switching code
- The ticker structure to interface to hardware
- Queues, buffers and memory management.
- Utility functions like some simple math and string handling.
Anyway this is getting a bit far away from the python
way, which does not strictly enforce the 'Pure Path' (Tm)
of:
- have loose objects as threads/processes
- send messages between them using clever queueing
So we are extremely unlikely to agree on the importance
of enforced data hiding.
:-)
- Hendrik
Steven D'Aprano
> On Tue, 03 Feb 2009 02:16:01 -0000, Russ P. <Russ.P...@gmail.com>
> wrote:
>
>> Here we go again. If you have access to the source code (as you nearly
>> always do with Python code), then "breaking the language-enforced data
>> hiding" is a trivial matter of deleting the word "private" (or
>> equivalent).
>
> If it's that trivial to defeat something that its proponents appear to
> want to be close to an iron-clad guarantee, what on earth is the point
> of using "private" in the first place?
Well, that is a good question.
Since it is even more trivial to defeat Python's private-by-convention
data hiding, why even bother? Just make everything public. What on earth
is the point of prefixing an attribute with an underscore?
I think this debate has a lot to do with people's attitudes towards "No
User Serviceable Parts". Some people are comfortable using black-boxes,
and if (enforced) data hiding makes it easier for others to build safe,
efficient black-boxes, then they're willing to give up that a little bit
of flexibility/freedom for the benefit of safe, efficient black-boxes.
Others prefer white-boxes, and are willing to give up some safety and
efficiency, and live with increased risk and lower performance, just in
case some day they might want to open up the white-box and replace the
widget with a gadget.
Some of us consider that a black-box sealed with regular Phillips head
screws is still be an effective black-box. It's not hard to find a screw
driver and open the box, but it's still an effective barrier against
casual and accidental tinkering while allowing deliberate tinkering.
Others take the attitude that anything short of resistance to oxy torches
and diamond-tipped drills might as well be in a paper bag, and therefore
there's no point to black-boxes at all.
I find this extreme position is rather incoherent. If I may paraphrase
the argument as I see it:
"Enforced data hiding is useless, because it is utterly trivial to bypass
it, AND it's wicked, because it makes it unbelievably painful and
difficult to bypass it when you need to."
If it is trivial to bypass, surely it can't be that painful to bypass?
Another extreme position is that enforced data hiding is useless, that
there is *never* any need for it *at all*, and therefore Python doesn't
need it, there's no reason except stupid PHB's belief in cargo-cult
coding why Python couldn't be used for controlling nuclear reactors or
the Space Shuttle. There's been some claims remarkably close to that in
this or the previous thread. I trust that nobody really believes this
extreme position -- it's not that far off claiming that procedures and
functions are pointless and stupid because we have GOTO.
(The restrictions on GOTOs is analogous to enforced data hiding. We give
up the freedom and flexibility to jump into the middle of arbitrary
pieces of code in order to write safer and more maintainable code.)
But as I wrote once before, it is very liberating to program in Python,
and put responsibility for dealing with errors onto the caller. Let them
call your methods with invalid arguments, let them mess with your
internals, if it breaks, it's their responsibility!
Except when it isn't.
And that's when I'd like to be able to lock my classes down and enforce
data hiding. Not all the time, because I do like white-boxes, but
sometimes a black-box is the right choice, or the necessary choice, and
if that makes development harder, then that's a cost I'm willing to pay.
If I'm not willing to pay it, then I'll leave it as a nice, open,
transparent white-box with easily messed-with internals and let the
caller deal with the consequences of messing with the internals.
Whether you agree with that choice or not is irrelevant. *My* code, *my*
choice: it's my decision to write code as a black-box or a white-box,
just like it's my choice to use a BSD license or the GPL or a closed-
source proprietary license, or to make the class mutable or immutable.
If other people don't like my choices, well, you have lots of options:
you can sub-class, you can delegate, you can use somebody else's class,
you can write your own class, you can do without, you can fork the source
code, you can make do with it the way it is, or you can complain to the
Salvation Army[1] about how I'm ruining your programming experience by
being too strict/not strict enough.
I love Python, and I'm greedy and want it all: I want a dynamic, easy-to-
use language *and* a compiler that can protect me from myself and bad
data. I'm envious of Haskell's type-inference. I want the option to have
the compiler warn me when some function is messing with my classes'
internals as soon as I hit Enter, and not to have to remember to run some
third-party tool.
I'm not going to *demand* the choice of white-box or black-box classes. I
don't have the right to demand anything. But I can ask, I can try to make
my case (to those who will listen), and I refuse to be brow-beaten by
those who think Python is Just About Perfect Just The Way It Is into
feeling *ashamed* for wanting that choice.
[1] They give a damn.
--
Steven
Russ P.
<ste...@REMOVE.THIS.cybersource.com.au> wrote:
> Another extreme position is that enforced data hiding is useless, that
> there is *never* any need for it *at all*, and therefore Python doesn't
> need it, there's no reason except stupid PHB's belief in cargo-cult
> coding why Python couldn't be used for controlling nuclear reactors or
> the Space Shuttle. There's been some claims remarkably close to that in
> this or the previous thread.
My recollection is that several people have said exactly that in no
uncertain terms, if not in this thread then in the one a few days ago.
> I trust that nobody really believes this
> extreme position -- it's not that far off claiming that procedures and
> functions are pointless and stupid because we have GOTO.
If nobody believes it, several participants here could have fooled me.
Thorsten Kampe
> On Feb 2, 9:02 am, thmpsn....@gmail.com wrote:
> Several participants here keep repeating that the leading-underscore
> convention is perfectly adequate. Aside from the aesthetic problem of
> littering code with leading underscores, let me try to explain the
> problem with leading underscores.
A leading underscore is not an aesthetic problem - while I would agree
that /multiple/ leading or trailing underscores are.
> Suppose a library developer (or a module developer on a large team)
> uses leading underscores. Now suppose that, for whatever reason
> (pressure from the users, perhaps), the library developer decides to
> change a "private" attribute to public. Now all occurrences of the
> identifier need to be changed. If an assignment to the previously
> "private" attribute is missed, no warning will be issued (because
> Python allows new attributes to be added anywhere, even completely
> outside the class definition itself). And if the library is widely
> used, the probability of such bugs occurring is very high.
>
> If a "private" keyword (or equivalent) were available, then the change
> would need to be made in only one location rather than at every
> occurrence off the identifier. That is much less error prone. Sure,
> you can argue (as I'm sure someone will) that the users of the library
> should be more careful. Yes they should, but why not let the language
> help with such low-level details. That's what high-level languages are
> for.
This scenario is highly "supposing" and doesn't look like a real-world-
case to me. But anyway: the obvious solution in my humble opinion would
be to do something like "public_attribute = _private_attribute". But
that would be too simple, too "unjavaesque", right?!
Thorsten
Thorsten Kampe
> On Feb 2, 2:55 am, Stephen Hansen <apt.shan...@gmail.com> wrote:
> > > This is proven
> > > by your statement above, whereby you are driving a user away,
> > > simply because the language, in one small aspect, does not
> > > give him what he wants, and the tenor of this thread has been
> > > very much: "That's how it is - like it or lump it", and no amount
> > > of careful explanation of why people want the feature has cut
> > > any ice -
> >
> > I'm missing the careful explanation. What I've heard is that the lack
> > of enforced encapsulation is "a danger". What I've heard is that
> > people want it because they've been told they should want it and
> > believe that. Why?
>
> Who has said the latter? Are you just trying to spread FUD?
No, he's not. He's giving his and other people's impression of the pro-
private group's arguments. They construct cases that do not exist in
reality or can more-than-easily be avoided.
> > There have been no "careful explanations" to answer that, in my mind.
> > And thus my response is: the practical possibility of needing access
> > vastly outweights the theoretical situation that might go bad if
> > encapsulation wasn't there. Why? Because in any real situation, IMHO,
> > *forced* encapsulation is pointless.
>
> I think you've gotten too subjective on this matter. You might as well
> say that we don't need no stinkin' OOP, we could all just be
> programming with goto's.
It's even simpler: "don't use other people's underscores". It couldn't
get more simple than that.
> > > It has all the time been countered with statements
> > > about how the proponents of private attributes "don't need it",
> > > (as if they are plain dumb),
> >
> > They don't need it. No one has shown a *real* reason why. The only
> > reasons provided are "its a DANGER" that someone "MIGHT DO BAD".
> > That's not a real reason. If its your project that someone is doing
> > bad in, this is a situation which can be *clearly* specified in a
> > projects policy and coding standards and can be *trivially* tested for
> > with simple static analysis in nearly all cases. The problem is the
> > person and not the code then. There's *countless* other ways that
> > person can do bad if you're allowing them to commit blindly anything
> > into your project.
>
> Aha! I see this attitude quite often among C/C++ people, regarding
> buffer overflows and uninitialized pointer dereferences: someone will
> say "C and C++ are unsafe languages because they allow you to overrun
> buffers", then a C/C++ zealot will respond "Hire some good
> programmers".
>
> SAME ATTITUDE.
Not at all. Buffer overflows cannot be easily avoided in C/C++ like
languages. On the contrary you can easily avoid other people's privates
by simply not using their underscores. It's really that simple. Even I
got that - and I'm a really simple guy.
Thorsten
Marco Mariani
> This scenario is highly "supposing" and doesn't look like a real-world-
> case to me. But anyway: the obvious solution in my humble opinion would
> be to do something like "public_attribute = _private_attribute". But
> that would be too simple, too "unjavaesque", right?!
Yes, the use of @property is.. cheating!! Shame on you! :)
Thorsten Kampe
"Decorators", right? Never used that, but I read about it...
Thorsten
Bruno Desthuilliers
> On Tue, 03 Feb 2009 03:48:58 +0000, Rhodri James wrote:
>
>> On Tue, 03 Feb 2009 02:16:01 -0000, Russ P. <Russ.P...@gmail.com>
>> wrote:
>>
>>> Here we go again. If you have access to the source code (as you nearly
>>> always do with Python code), then "breaking the language-enforced data
>>> hiding" is a trivial matter of deleting the word "private" (or
>>> equivalent).
>> If it's that trivial to defeat something that its proponents appear to
>> want to be close to an iron-clad guarantee, what on earth is the point
>> of using "private" in the first place?
>
> Well, that is a good question.
>
> Since it is even more trivial to defeat Python's private-by-convention
> data hiding, why even bother? Just make everything public. What on earth
> is the point of prefixing an attribute with an underscore?
To make clear it is *not* part of the API. The point is about enforced
access restriction, not encapsulation.
>
> I think this debate has a lot to do with people's attitudes towards "No
> User Serviceable Parts". Some people are comfortable using black-boxes,
> and if (enforced) data hiding makes it easier for others to build safe,
> efficient black-boxes, then they're willing to give up that a little bit
> of flexibility/freedom for the benefit of safe, efficient black-boxes.
>
> Others prefer white-boxes, and are willing to give up some safety and
> efficiency, and live with increased risk and lower performance, just in
> case some day they might want to open up the white-box and replace the
> widget with a gadget.
I don't see how this relates to efficiency.
> Some of us consider that a black-box sealed with regular Phillips head
> screws is still be an effective black-box.
And most of us here go as far as considering that something as simple as
a "warranty broke if unsealed" label is enough.
> It's not hard to find a screw
> driver and open the box, but it's still an effective barrier against
> casual and accidental tinkering while allowing deliberate tinkering.
Idem for a label. You *see* it, don't you ? So you cannot pretend you
"accidentaly" opened the box.
> Others take the attitude that anything short of resistance to oxy torches
> and diamond-tipped drills might as well be in a paper bag, and therefore
> there's no point to black-boxes at all.
straw-man argument once again. No one here says taht there's no point to
black-box - just that there's no point having to resort to any special
screw-driver if and when we want to treat it as a white box.
> I find this extreme position is rather incoherent.
It's *your* oversimplification of the point against *enforced* access
restriction that makes it incoherent.
(snip)
> Another extreme position is that enforced data hiding is useless, that
> there is *never* any need for it *at all*, and therefore Python doesn't
> need it, there's no reason except stupid PHB's belief in cargo-cult
> coding why Python couldn't be used for controlling nuclear reactors or
> the Space Shuttle.
There may be quite a lot of reasons to think (rightly or not) that
Python is not suited for such tasks. Anyway, I personnaly don't care
whether Python would be the right tool for such cases, because - like
probably more than 99.99% of Python users - that's not what I'm using it
for, and I don't see any reason to add such useless arbitrary
restrictions just because 2 or 3 persons claims that it's "how it should
be". FWIW, since anything dynamic would be considered unsafe in the
mentioned use cases, the next point would be to make Python as static as
Java. Yeah, great.
> There's been some claims remarkably close to that in
> this or the previous thread. I trust that nobody really believes this
> extreme position -- it's not that far off claiming that procedures and
> functions are pointless and stupid because we have GOTO.
yet another straw man argument.
> I love Python, and I'm greedy and want it all: I want a dynamic, easy-to-
> use language *and* a compiler that can protect me from myself
That's not what compilers are for.
> and bad
> data.
I definitly fail to see how a compiler could protect you from *runtime*
issues ???
> I'm envious of Haskell's type-inference. I want the option to have
> the compiler warn me when some function is messing with my classes'
> internals as soon as I hit Enter,
May I remind you that "def" and "class" are executable statements ?
>
> I'm not going to *demand* the choice of white-box or black-box classes. I
> don't have the right to demand anything. But I can ask, I can try to make
> my case (to those who will listen), and I refuse to be brow-beaten by
> those who think Python is Just About Perfect Just The Way It Is into
> feeling *ashamed* for wanting that choice.
It's not about Python being "Just About Perfect Just The Way It", it's
about deciding whether enforced access restriction is of any use (at
least for a very large majority of it's users), and if it's worth
imposing design changes so fundamuntal they would just turn Python into
a totally different language just because a couple guys ask for it.
Anyway: the choice is neither yours nor mine, so all this discussion is
more than pointless. If you really want such drastic changes in Python's
design and implementation, submit a PEP.
Scott David Daniels
> "Diez B. Roggisch" <de...@nospam.web.de>
>> ...Sure one could envision a system where each object is running in it's
>> micro-process.
> ... I would have loved a
> language that supported it, as well as an operating system
> (and I do not mean stuff like tiny os and others of that ilk),
> but one that really supported fast task switching to make
> the micro tasks less expensive on cheap little processors
You might enjoy looking at QNX, since I think it is built along the
lines you are describing here. I have an ancient copy of their OS,
but haven't followed for more than couple of decades.
--Scott David Daniels
Scott....@Acm.Org
Дамјан Георгиевски
> without defining a single class.
> By analogy, if data hiding is added to language, I could write a
> whole system without hiding a single item.
I guess the problem is that you would not be able to use some libraries
because their author thought that it would be wise to hide everything (a
behavior fairly popular in the Java world).
Let take some http library as an example, the author would certainly
think that hiding the socket object is the only sane thing to do.
But what if you just *have* to call that special ioctl on the socket
object before it can work in your scenario...
In python you can easily go under the hood if you need to do it.
--
дамјан ( http://softver.org.mk/damjan/ )
"We think it's a great consumer win, and it's a great industry win,
to be able to ensure that with good copy protection,
you can have so much functionality for the user",
Jordi Rivas, Microsoft Director of Technology
thmps...@gmail.com
Your lack of knowledge about it doesn't mean that it has somehow
magically "private" members. The only reason that most of us don't
know what a FILE is is that it's definition is implementation-defined
(i.e., every compiler may define it differently).
That doesn't have anything to do with private members. For example, on
my system, <stdio.h> defines FILE as:
struct _iobuf {
char *_ptr;
int _cnt;
char *_base;
int _flag;
int _file;
int _charbuf;
int _bufsiz;
char *_tmpfname;
};
typedef struct _iobuf FILE;
Given this information, nothing prevents me from writing things like:
FILE* fp = fopen("file.txt", "r");
if (!fp) { /* do something */ }
printf("fp->_cnt = %d\n", fp->cnt);
printf("fp->_flag = %d\n", fp->_flag);
printf("fp->_file = %d\n", fp->_file);
fp->_flag = 0x20; // OOPS!!
> Maybe I still lack experience, but I find neither _ prefixing nor
> private/public/protected a satisfaying way to make clear what is
> public API and what is not. In particular, if I have a python package
> which does not use _ at all, shall I assume everything is public ?
Pretty much, unless maybe the code documents what you're not supposed
to access:
class IOBuf:
def __init__(self):
self.ptr = "" # <- this is private!
self.cnt = 0 # <- this is private!
self.base = "" # <- this is private!
self.flag = 0 # <- this is private!
self.file = 0 # <- this is private!
self.charbuf = 0 # <- this is private!
self.bufsiz = 0 # <- this is private!
self.tmpfname = "" # <- this is private!
Nope, not a good idea either...
David Cournapeau
Hm, I guess it depends on the implementation, but it is at least
possible in C to completely hide the structure, by declaring only a
pointer, and defining the structure outside any public header file.
Then, you cannot accidentally access any member - it would result in a
compiler error.
This method is also used in C++, that's the pimpl pattern. It is used
for various purposes (avoid long compilation times when changing some
private implementation, actual data hiding), but the underlying idea
is that you hide the implementation from the public headers. That's
used for example by QT, and many other C++ libraries.
This shows quite strongly the limitations of the whole private/public
business in C++.
>
> Pretty much, unless maybe the code documents what you're not supposed
> to access:
But that's my point: that's just not true for many packages I have
used - some packages do follow the _ convention, some don't. For
example, to take an example I am somewhat familiar with: distutils
does not follow this at all. There is no documentation, and it is
almost impossible to know what's the API from implementation details,
the interface is leaking everywhere. Now, distutils is an "old"
package, but my experience at least showed me that this is relatively
common.
There are some relatively well known packages which use a different
mechanism to clearly separate the intended API, without using the _
convention, or more exactly in supplement of it.
David
thmps...@gmail.com
I've done that to implement ADTs (abstract data types, also known as
opaque types), but it's far from optimal, mainly because:
- The compiler doesn't know the size of the class/struct (since it
hasn't seen its definition), so you have to provide some sort of
"constructor" function that's defined in the same file in which the
class/struct is defined. This function will allocate memory for the
object using malloc()/new and return a pointer to it. Of course, since
memory allocated using malloc()/new has to be released using free()/
delete, you also have to provide a "destructor" function that does
this, and the user *always* has to call both the constructor function
and the destructor function *explicitly*, which is VERY cumbersome (as
opposed to C++ constructors/destructors, which are called
automatically at object creation/deletion, and which you don't always
need to provide unless you have to do some initialization/cleanup).
- Memory allocated with malloc()/new is allocated on the heap (as
opposed to variables that you simply declare locally, which are
allocated on the stack), and heap memory allocation is slower than
stack memory allocation (not that you have to worry about this
overhead except in really high-performance applications).
In short, you pay too high a price for using an object whose size
isn't known at compile time.
> This method is also used in C++, that's the pimpl pattern. It is used
> for various purposes (avoid long compilation times when changing some
> private implementation, actual data hiding), but the underlying idea
> is that you hide the implementation from the public headers. That's
> used for example by QT, and many other C++ libraries.
>
> This shows quite strongly the limitations of the whole private/public
> business in C++.
What limitations? The only limitations I see are the ones associated
with opaque types (what you mentioned above).
rdmu...@bitdance.com
> On Wed, Feb 4, 2009 at 2:36 AM, <thmps...@gmail.com> wrote:
> >
> > Pretty much, unless maybe the code documents what you're not supposed
> > to access:
>
> used - some packages do follow the _ convention, some don't. For
> example, to take an example I am somewhat familiar with: distutils
> does not follow this at all. There is no documentation, and it is
> almost impossible to know what's the API from implementation details,
> the interface is leaking everywhere. Now, distutils is an "old"
> package, but my experience at least showed me that this is relatively
> common.
>
> There are some relatively well known packages which use a different
> mechanism to clearly separate the intended API, without using the _
> convention, or more exactly in supplement of it.
This whole issue gets more complicated, I think, when you consider that
what is "public" versus "private" in an API depends on the consumer.
That is, you might have a group of modules that use a package-internal
interface, while what the "outside world" is supposed to use is a more
restricted API. The package-internal interface isn't _private_ in the
sense of hiding things from anybody outside the class or its subclasses,
but neither is it public.
I won't be surprised to hear that languages with data hiding have some
provision for this, but to my mind this is a "one, two, many" situation.
That is, if you have one case, things are trivially simple. If you have
two cases, you can differentiate them. But once you have three cases,
you almost certainly have _more_ than three cases...in other words a
problem in generalization.
In my code I generally use _ for stuff that is class-private, and document
the "outside" or "stable" API, and everything else is...whatever it needs
to be. Perhaps the packages you are thinking of do something similar?
--RDM
Gabriel Genellina
escribió:
> Suppose a library developer (or a module developer on a large team)
> uses leading underscores. Now suppose that, for whatever reason
> (pressure from the users, perhaps), the library developer decides to
> change a "private" attribute to public. Now all occurrences of the
> identifier need to be changed. If an assignment to the previously
> "private" attribute is missed, no warning will be issued (because
> Python allows new attributes to be added anywhere, even completely
> outside the class definition itself). And if the library is widely
> used, the probability of such bugs occurring is very high.
So _foo becomes foo. Then:
class X(object):
def get_foo(self): return self._foo
def set_foo(self, value): self._foo = value
foo = property(get_foo, set_foo)
You have the public name "foo", for new usage outside the library, and the
private name "_foo", for internal use only. And we're all happy. If it
weren't for your "historical" reasons, using those trivial get/set
functions is rather silly.
--
Gabriel Genellina
Rhodri James
> On Feb 2, 7:48 pm, "Rhodri James" <rho...@wildebst.demon.co.uk> wrote:
>> On Tue, 03 Feb 2009 02:16:01 -0000, Russ P. <Russ.Paie...@gmail.com>
>> wrote:
>> > Here we go again. If you have access to the source code (as you nearly
>> > always do with Python code), then "breaking the language-enforced data
>> > hiding" is a trivial matter of deleting the word "private" (or
>> > equivalent).
>>
>> If it's that trivial to defeat something that its proponents appear to
>> want to be close to an iron-clad guarantee, what on earth is the point
>> of using "private" in the first place?
>
> If a library developer releases the source code of a library, any user
> can trivially "defeat" the access restrictions. But if a team of
> developers is checking in code for a project, the leader(s) of the
> project can insist that the access restrictions be respected to
> simplify the management of interfaces. The larger the team, the more
> useful that can be. That's why Java, C++, Ada, Scala, and other
> languages have a "private" keyword.
Indeed he can. He can even do that in Python; it just requires a little
self-discipline from the team, or a validation script on the code
repository if he really doesn't trust them. Not only can this be done
without forcing the rest of the world to play, it makes things a little
less daunting when those nice clean interfaces turn out to be
incomplete/too slow/not what you thought.