Re: About classes and OOP in Python
Ben C wrote:
On 2006-04-11, Michele Simionato [EMAIL PROTECTED] wrote:
Roy Smith wrote:
snip
That being said, you can indeed have private data in Python. Just prefix
your variable names with two underscores (i.e. __foo), and they effectively
become private. Yes, you can bypass this if you really want to, but then
again, you can bypass private in C++ too.
Wrong, _foo is a *private* name (in the sense don't touch me!), __foo
on the contrary is a *protected* name (touch me, touch me, don't worry
I am protected against inheritance!).
This is a common misconception, I made the error myself in the past.
Please explain! I didn't think _foo meant anything special,
It doesn't mean anything special in the language itself - it's a
convention between programmers. Just like ALL_CAPS names is a convention
for (pseudo) symbolic constants. Python relies a lot on conventions.
__foo
expands to _classname__foo for some sort of name-hiding.
s/hiding/mangling/
What am I
missing?
the __name_mangling mechanism is meant to protect some attributes to be
*accidentaly* overridden. It's useful for classes meant to be subclassed
(ie in a framework). It has nothing to do with access restriction - you
still can access such an attribute.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
Casey Hawthorne wrote:
I think it's important not to wrongly confuse 'OOP' with ''data hiding'
or any other aspect you may be familiar with from Java or C++. The
primary concept behind OOP is not buzzwords such as abstraction,
encapsulation, polymorphism, etc etc, but the fact that your program
consists of objects maintaining their own state, working together to
produce the required results, as opposed to the procedural method where
the program consists of functions that operate on a separate data set.
Isn't inheritance an important buzzword for OOP?
Which kind of inheritance ? subtyping or implementation inheritance ?-)
FWIW, subtyping is implicit in dynamically typed languages, so they
don't need support for such a mechanism. And implementation inheritance
is not much more than a special case of composition/delegation, so it's
almost useless in a language that have a good support for delegation
(which we have in Python, thanks to __getattr__/__setattr__).
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
Michele Simionato wrote: Roy Smith wrote: snip That being said, you can indeed have private data in Python. Just prefix your variable names with two underscores (i.e. __foo), and they effectively become private. Yes, you can bypass this if you really want to, but then again, you can bypass private in C++ too. Wrong, _foo is a *private* name (in the sense don't touch me!), __foo on the contrary is a *protected* name (touch me, touch me, don't worry I am protected against inheritance!). This is a common misconception, I made the error myself in the past. While your wording makes sense, it's probably confusing for anyone with a C++ background, where private roughly means only accessible within the actual class and protected roughly means only accessible within the class and other classes derived from it. -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
Gregor Horvath wrote:
Steven D'Aprano schrieb:
I don't know of many other OO languages that didn't/don't have
inheritance,
VB4 - VB6
VB6 has a kind of inheritance via interface/delegation. The interface
part is for subtyping, the delegation part (which has to be done
manually - yuck) is for implementation inheritance. Needless to say it's
a king-size PITA...
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
fyhuang wrote: It seems to me that it is difficult to use OOP to a wide extent in Python code because these features of the language introduce many inadvertant bugs. For example, if the programmer typos a variable name in an assignment, the assignment will probably not do what the programmer intended. You'll find that if you assign to a wrongly-typed variable name, then later attempts to access the variable you wrongly believed you typed will raise an exception. If you assign from a wrongly-typed variable, again an exception will be raised. I think it's important not to wrongly confuse 'OOP' with ''data hiding' or any other aspect you may be familiar with from Java or C++. The primary concept behind OOP is not buzzwords such as abstraction, encapsulation, polymorphism, etc etc, but the fact that your program consists of objects maintaining their own state, working together to produce the required results, as opposed to the procedural method where the program consists of functions that operate on a separate data set. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
Ben Sizer wrote: I think it's important not to wrongly confuse 'OOP' with ''data hiding' or any other aspect you may be familiar with from Java or C++. The primary concept behind OOP is not buzzwords such as abstraction, encapsulation, polymorphism, etc etc, but the fact that your program consists of objects maintaining their own state, working together to produce the required results, as opposed to the procedural method where the program consists of functions that operate on a separate data set. +1 QOTW /F -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
Roy Smith wrote: snip That being said, you can indeed have private data in Python. Just prefix your variable names with two underscores (i.e. __foo), and they effectively become private. Yes, you can bypass this if you really want to, but then again, you can bypass private in C++ too. Wrong, _foo is a *private* name (in the sense don't touch me!), __foo on the contrary is a *protected* name (touch me, touch me, don't worry I am protected against inheritance!). This is a common misconception, I made the error myself in the past. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
fyhuang wrote:
Hello all,
I've been wondering a lot about why Python handles classes and OOP the
way it does. From what I understand, there is no concept of class
encapsulation in Python, i.e. no such thing as a private variable.
Seems you're confusing encapsulation with data hiding.
Any
part of the code is allowed access to any variable in any class,
This is also true for Java and C++ - it just a requires a little bit
more language-specific knowledge.
Python relies a lot on conventions. One of these conventions is that any
attribute whose name begins with an underscore is implementation detail
and *should* not be accessed from client code.
and
even non-existant variables can be accessed:
Nope. You can dynamically *add* new attributes - either to an instance
or a class - but trying to *read* a non-existant attribute will raise an
AttributeError.
they are simply created.
I'm wondering what the philosophy behind this is,
Dynamism.
and if this
behaviour is going to change in any future release of Python.
Certainly not.
It seems to me that it is difficult to use OOP to a wide extent in
Python code because these features of the language introduce many
inadvertant bugs.
Don't assume, verify. My own experience is that it's *much more* easy to
do OOP with a dynamic language.
For example, if the programmer typos a variable name
in an assignment, the assignment will probably not do what the
programmer intended.
That's true for any language. I never had any serious problem with this
in 5+ years - not that I'm never making typos, but it never took me more
than a pair of minutes to spot and correct this kind of errors. OTOH,
Python's dynamism let me solved in a quick and clean way problems that
would have been a royal PITA in some less agile languages.
Ruby does something with this that I think would be excellent as an
inclusion in Python (with some syntax changes, of course). If private
variables require a setter/getter pair, we can shortcut that in some
way, i.e. (pseudocode):
class PythonClass:
private foo = bar
private var = 42
allow_readwrite( [ foo, var ] )
A first point: in Ruby (which closely follows Smalltalk's model),
there's a definitive distinction between callable and non-callable
attributes, and this last category is *always* private.
A second point is that Python also provides you getter/setter for
attributes. The default is read/write, but you can easily make any
attribute read-only (or write-only FWIW) and add any computation.
Or allow_read to only allow read-only access. Also there might be a
way to implement custom getters and setters for those times you want
to modify input or something:
class PythonClass:
def get foo():
return bar
def set var( value ):
var = value
What you want is named property.
Anyways, these are just some speculatory suggestions.
Don't waste time with speculations. Read the Fine Manual instead, and
actually *use* Python.
My main question
is that of why Python chooses to use this type of OOP model and if it
is planned to change.
I'm not the BDFL, but my bet is that this will *not* change.
--
bruno desthuilliers
python -c print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])
--
http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
I think it's important not to wrongly confuse 'OOP' with ''data hiding' or any other aspect you may be familiar with from Java or C++. The primary concept behind OOP is not buzzwords such as abstraction, encapsulation, polymorphism, etc etc, but the fact that your program consists of objects maintaining their own state, working together to produce the required results, as opposed to the procedural method where the program consists of functions that operate on a separate data set. Isn't inheritance an important buzzword for OOP? -- Regards, Casey -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
On 2006-04-11, Michele Simionato [EMAIL PROTECTED] wrote: Roy Smith wrote: snip That being said, you can indeed have private data in Python. Just prefix your variable names with two underscores (i.e. __foo), and they effectively become private. Yes, you can bypass this if you really want to, but then again, you can bypass private in C++ too. Wrong, _foo is a *private* name (in the sense don't touch me!), __foo on the contrary is a *protected* name (touch me, touch me, don't worry I am protected against inheritance!). This is a common misconception, I made the error myself in the past. Please explain! I didn't think _foo meant anything special, __foo expands to _classname__foo for some sort of name-hiding. What am I missing? -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
On Tue, 11 Apr 2006 18:20:13 +, Casey Hawthorne wrote: I think it's important not to wrongly confuse 'OOP' with ''data hiding' or any other aspect you may be familiar with from Java or C++. The primary concept behind OOP is not buzzwords such as abstraction, encapsulation, polymorphism, etc etc, but the fact that your program consists of objects maintaining their own state, working together to produce the required results, as opposed to the procedural method where the program consists of functions that operate on a separate data set. Isn't inheritance an important buzzword for OOP? Of course inheritance is an important and desirable feature of OOP, but it isn't a necessary feature. Python built-in objects like int, list etc. were still objects even before you could inherit from them. I don't know of many other OO languages that didn't/don't have inheritance, but there was at least one: Apple's Hypertalk, back in the late 80s early 90s. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
Michele Simionato wrote: Roy Smith wrote: snip That being said, you can indeed have private data in Python. Just prefix your variable names with two underscores (i.e. __foo), and they effectively become private. Yes, you can bypass this if you really want to, but then again, you can bypass private in C++ too. Wrong, _foo is a *private* name (in the sense don't touch me!), __foo on the contrary is a *protected* name (touch me, touch me, don't worry I am protected against inheritance!). This is a common misconception, I made the error myself in the past. Sure, if you only consider private and protected as they're defined in a dictionary. But then you'd be ignoring the meanings of the public/private/protected keywords in virtually every language that has them. http://www.google.com/search?q=public+private+protected Python doesn't have these keywords, but most Python programmers are at least somewhat familiar with a language that does use them. For the sake of clarity: __foo ~= private = used internally by base class only _foo ~= protected = used internally by base and derived classes The Python docs use the above definitions. --Ben -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
Steven D'Aprano schrieb: I don't know of many other OO languages that didn't/don't have inheritance, VB4 - VB6 -- Mit freundlichen Grüßen, Ing. Gregor Horvath, Industrieberatung Softwareentwicklung http://www.gregor-horvath.com -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
You can do this in Python as well. Check out the property built-in function. One can declare a property with a get, set, and delete method. Here's a small example of a read-only property. class Test(object): def getProperty(self): return 0; prop = property(fget = getProperty) t = Test() print t.prop t.prop = 100 # this will fail -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
fyhuang [EMAIL PROTECTED] wrote: I've been wondering a lot about why Python handles classes and OOP the way it does. From what I understand, there is no concept of class encapsulation in Python, i.e. no such thing as a private variable. Any part of the code is allowed access to any variable in any class, and even non-existant variables can be accessed: they are simply created. I'm wondering what the philosophy behind this is, and if this behaviour is going to change in any future release of Python. There are advantages and disadvantages to C++/Java style encapsulation using private data. The advantages you (apparently) already know. The disadvantage is added complexity. There's a saying, You can't have a bug in a line of code you never write. By having to write all those getter and setter methods, you just add bulk and complexity. That being said, you can indeed have private data in Python. Just prefix your variable names with two underscores (i.e. __foo), and they effectively become private. Yes, you can bypass this if you really want to, but then again, you can bypass private in C++ too. You can also intercept any attempt to access Python attributes by writing __getattr__() and __setattr__() methods for your class. It seems to me that it is difficult to use OOP to a wide extent in Python code because these features of the language introduce many inadvertant bugs. For example, if the programmer typos a variable name in an assignment, the assignment will probably not do what the programmer intended. Yes, that is is a risk. Most people deal with that risk by doing a lot of testing (which you should be doing anyway). If you really want to, you can use the __slots__ technique to prevent this particular bug from happening (although the purists will tell you that this is not what __slots__ was designed for). My main question is that of why Python chooses to use this type of OOP model and if it is planned to change. It sounds like you are used to things like C++ and Java, which are very static languages. Everything is declared at compile time, and there are many safeguards in the language to keep you from shooting yourself in the foot. They problem is, they often prevent you from getting any useful work done either; you spend most of your time programming the language, not the problem you are trying to solve. In the past week, I've had two conversations with people about the nuances of C++ assignment operators. None of our customers give two figs about assignment operators. Getting them right is just a detour we need to take to keep our software from crashing. With Python, I write a = b and trust that it does the right thing. That lets me concentrate on adding value that our customer will see. -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
Em Seg, 2006-04-10 às 07:19 -0700, fyhuang escreveu: class PythonClass: private foo = bar private var = 42 allow_readwrite( [ foo, var ] ) You are aware that foo and var would become class-variables, not instance-variables, right? But you can always do: class PythonClass(object): def __init__(self): self.__foo = bar foo = property(lambda self: self.__foo) And then: a = PythonClass() a.foo 'bar' a.foo = 'baz' Traceback (most recent call last): File stdin, line 1, in ? AttributeError: can't set attribute But you can also bypass this security: a._PythonClass__foo = 'baz' a.foo 'baz' But this was not a mistake, nobody mistakenly writes _PythonClass__. Or allow_read to only allow read-only access. Also there might be a way to implement custom getters and setters for those times you want to modify input or something: class PythonClass: def get foo(): return bar def set var( value ): var = value There's a PEP somewhere that proposes things like (same example I gave earlier): class PythonClass(object): def __init__(self): self.__foo = bar create property foo: def get(self): return self.__foo -- Felipe. -- http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
fyhuang [EMAIL PROTECTED] wrote:
[ ... ] no such thing as a private variable. Any
part of the code is allowed access to any variable in any class, and
even non-existant variables can be accessed: they are simply created.
You're confusing two issues: encapsulation and dynamic name binding.
You might also want to check out the difference between read and
write access to non-existant variables.
I'm wondering what the philosophy behind this is,
We are all consenting adults. And probably experience of data
encapsulation being more of a hinderence than a benefit.
and if this
behaviour is going to change in any future release of Python.
I damn well hope not.
And if you want to control those writes, try this for a base class:
class restrict_set:
def __init__(self, allowed_names):
self._allowed_names = set(allowed_names)
def __setattr__(self, name, value):
if not name.startswith('_') and name not in self._allowed_names:
getattr(self, name)
self.__dict__[name] = value
(Someone else can do the new style class and the metaclass versions.)
--
\S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/
___ | Frankly I have no feelings towards penguins one way or the other
\X/ |-- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump
--
http://mail.python.org/mailman/listinfo/python-list
Re: About classes and OOP in Python
Hi, fyhuang schrieb: I've been wondering a lot about why Python handles classes and OOP the way it does. From what I understand, there is no concept of class encapsulation in Python, i.e. no such thing as a private variable. Any the answer is here: http://tinyurl.com/obgho -- Mit freundlichen Grüßen, Ing. Gregor Horvath, Industrieberatung Softwareentwicklung http://www.gregor-horvath.com -- http://mail.python.org/mailman/listinfo/python-list
